Một trong những lựa chọn cơ bản cần thực hiện khi phát triển một ứng dụng là sử dụng cơ sở dữ liệu (CSDL) SQL hay NoSQL để lưu trữ dữ liệu. Cơ sở dữ liệu quan hệ (RDBMS – Relational Database Management System) SQL đã được phát triển từ rất lâu, được kiểm nghiệm qua thời gian và sử dụng rất nhiều. Chúng được thiết kế cho các giao dịch đáng tin cậy và các truy vấn đặc biệt trong các ứng dụng. Tuy nhiên, CSDL SQL không phải là không có hạn chế và và không phải lúc nào cũng phù hợp với tất cà các nhu cầu lưu trữ và truy xuất dữ liệu.
Và cơ sở dữ liệu NoSQL đã ra đời để đáp ứng những hạn chế đó. Hệ thống CSDL NoSQL lưu trữ và quản lý dữ liệu theo cách cho phép tốc độ hoạt động cao và tính linh hoạt cao. Nhiều hệ thống CSDL NoSQL được phát triển bởi các công ty như Google, Amazon, Yahoo và Facebook nhằm tìm kiếm những cách tốt hơn để lưu trữ nội dung hoặc xử lý dữ liệu cho các trang web lớn. Không giống như cơ sở dữ liệu SQL, nhiều cơ sở dữ liệu NoSQL có thể được mở rộng theo chiều ngang trên hàng trăm hoặc hàng nghìn máy chủ.
Vậy chính xác Cơ sở dữ liệu NoSQL là gì? Nó được sử dụng trong trường hợp nào? CSDL SQL và NoSQL khác nhau thế nào? NoSQL có hạn chế gì? cùng nhiều vấn đề thú vị khác sẽ có trong bài viết này
Mục lục
1. Cơ sở dữ liệu NoSQL là gì?
Cơ sở dữ liệu NoSQL là một Hệ thống quản lý dữ liệu không quan hệ (non-relational Data Management System) có lược đồ (schema) linh hoạt. Nó dễ mở rộng. Mục đích chính của việc sử dụng cơ sở dữ liệu NoSQL là dành cho các kho dữ liệu phân tán với nhu cầu lưu trữ dữ liệu lớn. NoSQL được sử dụng cho Dữ liệu lớn và ứng dụng web thời gian thực. Chẳng hạn các công ty như Twitter, Facebook và Google thu thập hàng terabyte dữ liệu người dùng mỗi ngày.
Cơ sở dữ liệu NoSQL là viết tắt của “Not Only SQL” hoặc “Not SQL”. Với cơ sở dữ liệu quan hệ RDBMS ta sử dụng cú pháp SQL để lưu trữ và truy xuất dữ liệu. Đối với hệ thống cơ sở dữ liệu NoSQL, nó bao gồm một loạt các công nghệ cơ sở dữ liệu có thể lưu trữ dữ liệu có cấu trúc, bán cấu trúc, phi cấu trúc và đa hình. Sơ đồ sau cho thấy CSDL NoSQL khác so với CSDL SQL
2. Khác nhau giữa Cơ sở dữ liệu SQL và NoSQL
Bảng dưới đây tóm tắt sự khác nhau giữa SQL và NoSQL database:
| SQL Databases | NoSQL Databases | |
| Mô hình dữ liệu | Mô hình quan hệ chuẩn hóa dữ liệu vào bảng được hình thành từ hàng và cột. Sơ đồ quy định rõ ràng bảng, hàng, cột, chỉ mục, mối quan hệ giữa các bảng và các thành tố cơ sở dữ liệu khác. Cơ sở dữ liệu sẽ thực thi tính toàn vẹn tham chiếu trong mối quan hệ giữa các bảng. | Kiểu Document: JSON documentsKiểu Key-value: key-value pairsKiểu column: bảng với hàng và cột thay đổi (dynamic)Graph: nodes và cạnh |
| Lịch sử phát triển | Phát triển từ những năm 1970, tập trung vào việc giảm thiểu sự trùng lắp dữ liệu. | Phát triển sau năm 2000, mục đích chính phục vụ việc mở rộng nhanh (scale) và phát triển các ứng dụng theo phương pháp Agile và DevOps. |
| Các CSDL tiêu biểu | Oracle, MySQL, Microsoft SQL ServerPostgreSQL | NoSQL Document: MongoDB, CouchDBKey-value: Redis, DynamoDBColumn: Cassandra, HBaseGraph: Neo4j, Amazon Neptune |
| Mục đích sử dụng | Nhiều mục đích | NoSQL Document DB: nhiều mục địchKey-value: dữ liệu lớn với các truy xuất đơn giảnColumn: dữ liệu lớn với các mẫu truy xuất dữ liệu có thể dự đoán được (predictable query patterns)Graph: phân tích và duyệt các mối quan hệ giữa các dữ liệu được kết nối |
| Schemas | Cố định (Rigid) | Uyển chuyển |
| Mở rộng | Theo chiều dọc. Cơ sở dữ liệu quan hệ thường tăng quy mô bằng cách tăng năng lực điện toán của phần cứng hoặc tăng quy mô bằng cách thêm bản sao của khối lượng công việc chỉ đọc. | Cho phép thay đổi quy mô theo chiều ngang (scale-out bằng cách phân tán trên nhiều server) |
| Thuộc tính ACID | Hỗ trợ. Cơ sở dữ liệu quan hệ có các thuộc tính mang tính nguyên tố, nhất quán, tách biệt và bền vững (ACID) | Cơ sở dữ liệu NoSQL tuân theo định lý Brewers CAP (Consistency, Availability, Partition tolerance). (Xem thêm bên dưới về CAP) |
| Joins | Thường được yêu cầu | Thường không yêu cầu |
| Data to Object Mapping | Yêu cầu ORM (object-relational mapping) | Nhiều NoSQL database không yêu cầu ORMs. |
| Hiệu năng | Hiệu năng thường phụ thuộc vào hệ thống con của ổ đĩa. Thông thường, việc tối ưu hóa các truy vấn, chỉ mục và cấu trúc bảng bắt buộc phải được thực hiện để đạt mức hiệu năng tối đa. | Hiệu năng thường được xem là chức năng của kích cỡ cụm phần cứng ngầm, độ trễ mạng và ứng dụng đưa ra lệnh gọi. |
| API | Yêu cầu lưu trữ và truy xuất dữ liệu được truyền đạt bằng cách sử dụng các truy vấn nhất quán với ngôn ngữ truy vấn có cấu trúc (SQL). Các truy vấn này được phân tích và thực thi bởi cơ sở dữ liệu quan hệ. | API trên cơ sở đối tượng cho phép các nhà phát triển ứng dụng dễ dàng lưu trữ và truy xuất cấu trúc dữ liệu trong bộ nhớ. Khóa phân mảnh tìm kiếm các cặp khóa-giá trị, tập hợp cột hoặc văn bản có cấu trúc chưa hoàn chỉnh có chứa đối tượng và thuộc tính của ứng dụng được xếp theo chuỗi. |
3. Khi nào sử dụng Cơ sở dữ liệu NoSQL?
Như trên đã đề cập, khái niệm cơ sở dữ liệu NoSQL trở nên phổ biến khi những công ty như Google, Facebook, Amazon, v.v., phải xử lý khối lượng dữ liệu cực lớn. Thời gian phản hồi của hệ thống trở nên chậm khi sử dụng RDBMS cho khối lượng lớn dữ liệu. Để giải quyết vấn đề này có thể dùng giải pháp “mở rộng quy mô” hệ thống của mình bằng cách nâng cấp phần cứng hiện có. Tuy vậy, quá trình này là rất tốn kém. Giải pháp thay thế cho vấn đề này là phân phối tải cơ sở dữ liệu trên nhiều máy chủ bất cứ khi nào tải tăng lên. Phương pháp này được gọi là “scaling out” và NoSQL đáp ứng được nhu cầu này.
Ngoài ra, những yếu tố sau có thể xem xét sử dụng NoSQL DB thay vì SQL DB:
3.1 Tốc độ phát triển với cơ sở dữ liệu NoSQL có thể nhanh hơn nhiều so với cơ sở dữ liệu SQL.
Cơ sở dữ liệu NoSQL cho phép các developer kiểm soát cấu trúc của dữ liệu nên rất phù hợp với các phương pháp phát triển Agile hiện đại dựa trên việc phát triển nhanh, lặp lại nhanh và cập nhật code thường xuyên. Đối với CSDL quan hệ SQL, khi developer yêu cầu người quản trị cơ sở dữ liệu SQL thay đổi cấu trúc của cơ sở dữ liệu thì tải lại dữ liệu, chỉnh sửa code… có thể làm chậm quá trình phát triển.
3.2 Cấu trúc của nhiều dạng dữ liệu khác nhau được xử lý và phát triển dễ dàng hơn với cơ sở dữ liệu SQL.
Cơ sở dữ liệu NoSQL phù hợp để lưu trữ và mô hình hóa dữ liệu có cấu trúc, bán cấu trúc và phi cấu trúc trong một cơ sở dữ liệu. Cơ sở dữ liệu NoSQL lưu trữ dữ liệu ở dạng tương tự như các đối tượng được sử dụng trong các ứng dụng, giảm nhu cầu dịch từ dạng dữ liệu được lưu trữ sang dạng dữ liệu lấy trong code.
3.3 Khi cơ sở dữ liệu SQL không đáp ứng được nhu cầu lưu trữ dữ liệu lớn
Cơ sở dữ liệu NoSQL được tạo ra để xử lý dữ liệu lớn như một phần của kiến trúc cơ bản của chúng. Cơ sở dữ liệu NoSQL thường dựa trên chiến lược mở rộng quy mô (scale-out strategy), giúp cho việc mở rộng quy mô đến khối lượng dữ liệu lớn rẻ hơn nhiều so với khi sử dụng phương pháp mở rộng quy mô mà cơ sở dữ liệu SQL thực hiện.
3.4 Khi hệ thống có lượng truy cập cao và không cho phép downtime.
Chiến lược mở rộng quy mô (scale-out) được sử dụng bởi hầu hết các cơ sở dữ liệu NoSQL cho phép chúng ta hoạch định được kế hoạch rõ ràng về việc mở rộng lưu lượng truy cập. Các kiến trúc mở rộng quy mô cũng mang các lợi ích như có thể nâng cấp cơ sở dữ liệu hoặc thay đổi cấu trúc của nó mà không cần thời gian downtime.
3.5 Các mô hình ứng dụng mới có thể được hỗ trợ dễ dàng hơn.
Khả năng mở rộng của cơ sở dữ liệu NoSQL cho phép một cơ sở dữ liệu phục vụ cả tác vụ nghiệp vụ (transactional) và phân tích từ cùng một cơ sở dữ liệu. Trong cơ sở dữ liệu SQL, thông thường, một data warehouse riêng biệt được sử dụng để hỗ trợ phân tích.
Cơ sở dữ liệu NoSQL được tạo trong kỷ nguyên đám mây và đã nhanh chóng thích nghi với quá trình tự động hóa là một phần của đám mây. Việc triển khai cơ sở dữ liệu trên quy mô lớn theo cách hỗ trợ microservices thường dễ dàng hơn với cơ sở dữ liệu NoSQL. Cơ sở dữ liệu NoSQL thường có khả năng tích hợp vượt trội với các công nghệ phát trực tuyến thời gian thực (real-time streaming).
Cơ sở dữ liệu NoSQL hỗ trợ polyglot persistence, tức nhiều kiểu lưu trữ cho phép lưu trữ nhiều loại cơ sở dữ liệu NoSQL khác nhau tùy thuộc vào nhu cầu của các ứng dụng cụ thể. Ví dụ: một số ứng dụng lưu trữ hầu hết dữ liệu của chúng trong document database (object sẽ được lưu trữ trong database dưới dạng một document), nhưng bổ sung bằng graph database (dữ liệu được lưu dưới dạng các node) để nắm bắt các kết nối vốn có giữa mọi người hoặc sản phẩm.
4. Các kiểu cơ sở dữ liệu NoSQL
Cơ sở dữ liệu NoSQL được phân loại thành bốn loại: Key-value pair, Column-oriented, Graph-based và Document-oriented. Mỗi loại đều có những thuộc tính và hạn chế riêng. Không có cơ sở dữ liệu nào được cho là tốt hơn để giải quyết tất cả các vấn đề. Người sử dụng nên chọn cơ sở dữ liệu dựa trên nhu cầu ứng dụng của mình.
4.1 Key Value Pair Based NoSQL database
Với Key Value Pair Based, Dữ liệu được lưu trữ trong các cặp khóa / giá trị (Key/Value Pair). Nó được thiết kế theo cách để xử lý nhiều dữ liệu và tải nặng. Cơ sở dữ liệu lưu trữ cặp khóa-giá trị lưu trữ dữ liệu dưới dạng bảng băm trong đó mỗi khóa là duy nhất và giá trị có thể là JSON, BLOB (Binary Large Objects), chuỗi, v.v. Ví dụ: một cặp khóa-giá trị có thể chứa một khóa như “Trang web” được liên kết với một giá trị như “Itguru”.
Đây là một trong những ví dụ cơ sở dữ liệu NoSQL cơ bản nhất. Loại cơ sở dữ liệu NoSQL này được sử dụng như một bộ sưu tập, từ điển, mảng kết hợp, v.v. Key value stores giúp developer lưu trữ dữ liệu không có schema.
Giới hạn của Key Value noSQL database:
- Không có mối quan hệ giữa Multiple-Data.
- Multi-operation Transactions: Nếu bạn đang lưu trữ nhiều khóa và không thể lưu một trong các khóa, bạn không thể quay lại phần còn lại của các thao tác.
- Query Data by ‘value’: Tìm kiếm ‘khóa’ dựa trên một số thông tin được tìm thấy trong phần ‘giá trị’ của các cặp khóa-giá trị.
- Operation by groups: Vì các hoạt động được giới hạn trong một khóa tại một thời điểm, không có cách nào để chạy nhiều khóa đồng thời.
Key Value NoSQL database tiêu biểu:
4.2 Column-based NoSQL database
Với Column based database, dữ liệu được lưu trữ trong database dưới dạng các cột. Mỗi cột được xử lý riêng biệt. Giá trị của cơ sở dữ liệu cột đơn được lưu trữ liền kề.
Chúng mang lại hiệu suất cao cho các truy vấn tổng hợp như SUM, COUNT, AVG, MIN, v.v. vì dữ liệu có sẵn trong một cột. Cơ sở dữ liệu NoSQL dựa trên cột được sử dụng rộng rãi để quản lý data warehouses, business intelligence, CRM, Library card catalogs…
Giới hạn của Column based NoSQL database:
- Load dữ liệu theo kiểu incremental: Cần nhiều thời gian cho tác vụ ghi hơn tác vụ đọc. Phương thức Online Transaction Processing (OLTP) tức Xử lý giao dịch trực tuyến được sử dụng.
- Cần nhiều thời gian để đọc dữ liệu
CSDL Column Based NoSQL tiêu biểu:
- Hbase
- Cassandra
- Hbase
- Hypertable
4.3 Document-Oriented NoSQL
NoSQL Document Database lưu trữ và truy xuất dữ liệu dưới dạng một cặp giá trị khóa (key value pair )nhưng phần giá trị được lưu trữ dưới dạng tài liệu. Tài liệu được lưu trữ ở định dạng JSON hoặc XML. Giá trị được hiểu bởi Online Transaction Processing DB và có thể được truy vấn
Trong sơ đồ bên trái bạn có thể thấy các hàng và cột, và ở bên phải, có một cơ sở dữ liệu tài liệu có cấu trúc tương tự như JSON. Đối với cơ sở dữ liệu quan hệ, bạn phải biết bạn có những cột nào, v.v. Tuy nhiên, đối với NoSQL document database, bạn có kho dữ liệu như đối tượng JSON. Bạn không cần phải xác định cái nào làm cho nó linh hoạt. Loại document này chủ yếu được sử dụng cho các hệ thống CMS, nền tảng blog, phân tích thời gian thực và các ứng dụng thương mại điện tử. Document database không nên sử dụng cho các giao dịch phức tạp yêu cầu nhiều hoạt động hoặc truy vấn dựa trên các cấu trúc tổng hợp khác nhau.
Giới hạn của NoSQL document database:
- Thông tin cơ sở trùng lặp trên nhiều tài liệu
- Thiết kế phức tạp dẫn đến không nhất quán.
Các hệ thống DBMS Document database NoSQL tiêu biểu:
- Amazon SimpleDB
- CouchDB
- MongoDB
- Riak
- Lotus Notes
4.4 Graph-Based NoSQL database
Cơ sở dữ liệu kiểu đồ thị (Graph Based) lưu trữ các thực thể cũng như các mối quan hệ giữa các thực thể đó. Thực thể được lưu trữ dưới dạng một node với mối quan hệ là các cạnh. Một cạnh cho biết mối quan hệ giữa các node. Mỗi node và cạnh có một mã định danh duy nhất.
So với cơ sở dữ liệu quan hệ trong đó các bảng được kết nối với nhau một cách lỏng lẻo, cơ sở dữ liệu Đồ thị có bản chất là đa quan hệ. Mối quan hệ truyền tải nhanh chóng vì chúng đã được ghi lại vào DB và không cần phải tính toán chúng. Cơ sở dữ liệu đồ thị chủ yếu được sử dụng cho mạng xã hội, hậu cần, dữ liệu không gian.
Giới hạn của NoSQL Graph database:
- Thiếu tính đồng thời hiệu suất cao (high performance concurrency): Trong nhiều trường hợp, graph database cung cấp các kiểu đọc và kiểu ghi đơn, điều này cản trở sự đồng thời và hiệu suất, do đó phần nào hạn chế tính song song phân luồng (threaded parallelism).
- Thiếu ngôn ngữ chuẩn: Việc thiếu sự thiết lập và một ngôn ngữ khai báo chuẩn là một vấn của NoSQL graph database.
- Thiếu tính song song (parallelism): việc phân vùng một biểu đồ là một vấn đề. Hầu hết các graph database không cung cấp các truy vấn song song trên các biểu đồ lớn.
Các graph-based databases tiêu biểu:
5. Những hạn chế của CSDL NoSQL
Nếu NoSQL cung cấp rất nhiều sự tự do và linh hoạt, tại sao không từ bỏ CSDL SQL hoàn toàn? Câu trả lời đơn giản: nhiều ứng dụng vẫn yêu cầu các loại ràng buộc, tính nhất quán và biện pháp bảo vệ mà cơ sở dữ liệu SQL cung cấp. Trong những trường hợp đó, một số ưu điểm của NoSQL có thể chuyển thành nhược điểm. Các hạn chế khác xuất phát từ thực tế là các hệ thống NoSQL tương đối mới. Hãy xem xét một số hạn chế của NoSQL DBMS
5.1 No Schema
Ngay cả khi bạn đang sử dụng dữ liệu dạng tự do, bạn hầu như luôn cần áp đặt các ràng buộc đối với dữ liệu đó để làm cho dữ liệu đó trở nên hữu ích. Với NoSQL, việc áp đặt các ràng buộc liên quan đến việc chuyển trách nhiệm từ cơ sở dữ liệu sang developers. Ví dụ: developer có thể áp đặt cấu trúc thông qua hệ thống ánh xạ quan hệ đối tượng. Nhưng nếu bạn muốn có schema của dữ liệu, thì NoSQL thường không làm điều đó. Một số giải pháp NoSQL cung cấp các tùy chọn về cơ chế nhập dữ liệu và xác nhận dữ liệu (data typing and validation mechanisms). Ví dụ, Apache Cassandra có một loạt các native data type gợi nhớ đến những kiểu dữ liệu có trong CSDL SQL thông thường.
5.2 Sự nhất quán
CSDL NoSQL đánh đổi tính nhất quán mạnh mẽ hoặc tức thì để có tính khả dụng và hiệu suất tốt hơn. Cơ sở dữ liệu thông thường đảm bảo rằng các hoạt động có:
- Tính nguyên tố hay atomicity: tất cả các phần của giao dịch thành công hoặc không có giao dịch nào xảy ra
- Tính nhất quán hay Consistency: tất cả người dùng có cùng một chế độ xem dữ liệu
- Tính biệt lập hay Isolation: các giao dịch không cạnh tranh:
- Tính bền vững hay Durability: khả năng phục hồi từ tình trạng hư hỏng hệ thống về trạng thái đã biết cuối cùng.
Bốn thuộc tính này, được gọi chung là ACID (Atomicity, Consistency, Isolation, Durability), được xử lý khác nhau trong hầu hết các hệ thống NoSQL. Cơ sở dữ liệu NoSQL thường phải đánh đổi bằng cách nới lỏng một số thuộc tính ACID này của cơ sở dữ liệu quan hệ để có mô hình dữ liệu linh hoạt hơn có khả năng thay đổi quy mô theo chiều ngang.
Một số cơ sở dữ liệu NoSQL có một phần cơ chế để giải quyết vấn đề này. Ví dụ: MongoDB có đảm bảo nhất quán cho các hoạt động riêng lẻ, nhưng không đảm bảo cho toàn bộ cơ sở dữ liệu. Microsoft Azure CosmosDB cho phép bạn chọn mức độ nhất quán cho mỗi yêu cầu, vì vậy bạn có thể chọn hành vi phù hợp với trường hợp sử dụng của mình.
5.3 Sự phụ thuộc
Hầu hết các hệ thống CSDL NoSQL đều giống nhau về mặt khái niệm, nhưng được triển khai rất khác nhau. Mỗi loại có xu hướng có các cơ chế riêng về cách quản lý và truy vấn dữ liệu. Một ảnh hưởng của điều đó là khả năng kết hợp giữa logic ứng dụng và cơ sở dữ liệu. Điều này không quá tệ nếu bạn chọn một hệ thống NoSQL và gắn bó với nó, nhưng nó có thể trở thành một trở ngại nếu bạn thay đổi hệ thống. Nếu bạn di chuyển từ MongoDB sang CouchDB (hoặc ngược lại), bạn phải làm nhiều việc hơn là chỉ di chuyển dữ liệu. Bạn cũng phải điều hướng sự khác biệt trong quyền truy cập dữ liệu hay nói cách khác, bạn phải viết lại các phần của ứng dụng truy cập cơ sở dữ liệu.
5.4 Thiếu người có kỹ năng về NoSQL
Một vấn đề khác của NoSQL là thiếu những người có chuyên môn, kinh nghiệm về hệ thống CSDL này. Khi mà thị trường lao động cho SQL vẫn còn khá lớn, thì thị trường cho các những người có kỹ năng NoSQL vẫn còn kém xa. Nhu cầu về chuyên môn NoSQL đang tăng lên, nhưng nó vẫn chỉ là một phần nhỏ của thị trường đối với SQL thông thường.
6. Định lý CAP (CAP Theorem)
Trong phần so sánh bên trên chúng ta có đề cập đến định lý CAP (CAP theorem). Vậy CAP là gì?
Điều rất quan trọng là phải hiểu những hạn chế của cơ sở dữ liệu NoSQL. NoSQL không thể cung cấp tính nhất quán và tính sẵn sàng cao cùng nhau. Điều này được Eric Brewer thể hiện lần đầu tiên trong Định lý CAP.
Định lý CAP hoặc định lý Eric Brewers nói rằng chúng ta chỉ có thể đạt được nhiều nhất hai trong ba điều kiện đảm bảo cho một cơ sở dữ liệu: Tính nhất quán, Tính khả dụng và Dung sai phân vùng (Consistency, Availability and Partition Tolerance – CAP):
- Tính nhất quán: Mọi lần đọc đều nhận được lần ghi gần đây nhất hoặc lỗi.
- Tính khả dụng: Mọi yêu cầu đều nhận được phản hồi (không lỗi) – mà không cần đảm bảo rằng nó có chứa lần viết gần đây nhất.
- Dung sai phân vùng: Ngay cả khi có sự cố mất mạng trong trung tâm dữ liệu và một số máy tính không thể truy cập được, hệ thống vẫn tiếp tục hoạt động.
Không có hệ thống nào có thể đảm bảo nhiều hơn 2 thuộc tính. Trong trường hợp của một hệ thống phân tán, việc phân vùng mạng là điều bắt buộc, vì vậy sự cân bằng luôn là giữa tính nhất quán và tính khả dụng.
7. Các nguồn tài liệu tham khảo và học về NoSQL
Có rất nhiều nguồn tài liệu trên Internet về CSDL NoSQL. Trong bài viết này chúng tôi đưa ra một số để bạn có thể tham khảo:
- Tài liệu về MongoDB: mặc dù đây là các tài liệu về MongoDB nhưng bạn có thể tìm hiểu rất nhiều khái niệm về CSDL NoSQL từ đây
- Khác nhau giữa các NoSQL databases: so sánh hơn 10 loại NoSQL DB khác nhau
- Các khóa học về NoSQL DB trên Udemy: rất nhiều khóa miễn phí
- Tìm hiểu về CAP
8. Kết luận
Cơ sở dữ liệu noSQL được tạo ra để giải quyết các hạn chế của CSDL quan hệ SQL. Tuy nhiên đây không phải là sự thay thế mà tùy vào mục đích mà các nhà phát triển quyết định lựa chọn CSDL SQL hay NoSQL cho phù hợp.