NoSQL

Cơ sở dữ liệu NoSQL (tên gốc là "Non SQL" (phi SQL) hoặc "non relational" (phi quan hệ))^[1] cung cấp một cơ chế để lưu trữ và truy xuất dữ liệu được mô hình hóa khác với các quan hệ bảng được sử dụng trong các cơ sở dữ liệu kiểu quan hệ. Các cơ sở dữ liệu như vậy đã tồn tại kể từ cuối những năm 1960, nhưng không được gọi là "NoSQL" cho đến khi nổi tiếng đột ngột đầu thế kỷ XXI tạo nên bởi sự cần thiết cho các công ty Web 2.0 như Facebook, Google và Amazon.com.^[2][3][4] Các cơ sở dữ liệu NoSQL đang được sử dụng ngày càng nhiều trong các ứng dụng dữ liệu lớn và ứng dụng nền web thời gian thực. Các hệ thống NoSQL cũng đôi khi được gọi là "Not only SQL" (không chỉ là SQL) để nhấn mạnh rằng chúng có thể hỗ trợ các ngôn ngữ truy vấn dạng như SQL.^[5][6] Nguyên nhân cho hướng tiếp cận này bao gồm: tính đơn giản trong thiết kế, mở rộng theo "chiều ngang" cho các cụm máy đơn giản hơn (là bài toán cho các cơ sở dữ liệu kiểu quan hệ),^[7] và kiểm soát tính khả dụng tốt hơn. Cấu trúc dữ liệu được thiết kế cho các cơ sở dữ liệu NoSQL (ví dụ: khóa-giá trị (key-value), wide column, biểu đồ hoặc tài liệu) khác với cấu trúc dữ liệu được sử dụng mặc định trong các cơ sở dữ liệu quan hệ, khiến cho nó thao tác nhanh hơn trong NoSQL. Cơ sở dữ liệu NoSQL thích hợp với từng trường hợp cụ thể cho vấn đề mà nó phải giải quyết. Đôi khi cấu trúc dữ liệu thiết kế dưới dạng NoSQL được xem là "linh hoạt" hơn các bảng cơ sở dữ liệu kiểu quan hệ.^[8] Nhiều kho lưu trữ NoSQL hy sinh tính nhất quán (trong ý nghĩa của định lý CAP) để ưu tiên cho tính sẵn có, dung lượng của phân vùng, và tốc độ. Rào cản đối với việc áp dụng nhiều hơn các kho lưu trữ NoSQL bao gồm việc sử dụng các ngôn ngữ truy vấn mức thấp (thay vì SQL, ví dụ như thiếu khả năng thực hiện các bảng JOIN đặc biệt), thiếu giao diện chuẩn hóa, và các khoản đầu tư rất lớn trong các cơ sở dữ liệu kiểu quan hệ hiện có.^[9] Hầu hết các kho lưu trữ NoSQL thiếu các giao dịch ACID đúng nghĩa, mặc dù một vài cơ sở dữ liệu, chẳng hạn như MarkLogic, Aerospike, FairCom c-treeACE, Google Spanner (mặc dù về mặt kỹ thuật là cơ sở dữ liệu dạng NewSQL), Symas LMDB và OrientDB đã đặt điều này làm trung tâm trong thiết kế của họ. (Xem Hỗ trợ ACID và JOIN.)

Thay vào đó, hầu hết các cơ sở dữ liệu NoSQL đưa ra một khái niệm "thống nhất cuối cùng" trong đó các thay đổi cơ sở dữ liệu được truyền đến tất cả các nút "cuối cùng" (thường là trong mili giây) để các truy vấn dữ liệu có thể không trả lại được dữ liệu cập nhật ngay lập tức hoặc có thể dẫn đến việc đọc dữ liệu không chính xác, một vấn đề được gọi đọc lâu (stale read).^[10] Ngoài ra, một số hệ thống NoSQL có thể biểu hiện bị mất các bản ghi và các hình thức mất dữ liệu khác.^[11] May mắn thay, một số hệ thống NoSQL cung cấp các khái niệm như bản ghi ghi-trước (write-ahead logging) để tránh bị mất dữ liệu.^[12] Đối với xử lý giao dịch phân tán trên nhiều cơ sở dữ liệu, tính thống nhất của dữ liệu là một thử thách lớn hơn, đó là khó khăn cho cả cơ sở dữ liệu kiểu NoSQL và cả cơ sở dữ liệu kiểu quan hệ. Ngay cả cơ sở dữ liệu kiểu quan hệ hiện tại "không cho phép các ràng buộc toàn vẹn tham chiếu để nối (span) các cơ sở dữ liệu."^[13] Có vài hệ thống duy trì cả giao dịch ACID và cả các tiêu chuẩn X/Open XA cho xử lý giao dịch phân tán.

Thuật ngữ NoSQL được sử dụng bởi Carlo Strozzi vào năm 1998 để đặt tên cho cơ sở dữ liệu quan hệ mã nguồn mở Strozzi NoSQL nhỏ gọn của mình, mà không tiết lộ giao diện SQL tiêu chuẩn, nhưng là vẫn còn là kiểu quan hệ.^[14] RDBMS của ông khác với khái niệm chung về cơ sở dữ liệu NoSQL được định nghĩa trong năm 2009. Strozzi gợi ý rằng, vì phong trào NoSQL hiện thời "đi mất từ mô hình kiểu quan hệ cùng với nhau; vì thế nên được gọi cho phù hợp hơn đó là 'NoREL'",^[15] ám chỉ tới ''No Relational'.

Johan Oskarsson của Last.fm giới thiệu lại thuật ngữ NoSQL vào đầu năm 2009 khi tổ chức một sự kiện thảo luận về "các cơ sở dữ liệu phân tán, không quan hệ nguồn mở".^[16] Tên gọi này cố gắng để đánh dấu sự xuất hiện ngày càng nhiều các kho lưu trữ dữ liệu phân tán, không quan hệ, bao gồm các nhân bản mã nguồn mở BigTable/MapReduce của Google và Dynamo của Amazon. Hầu hết các hệ thống NoSQL đầu tiên đã không cố gắng cung cấp các bảo đảm tính nguyên tố, nhất quán, tách biệt và bền vững, trái với ưu thế thực tế trong các hệ thống cơ sở dữ liệu kiểu quan hệ.^[17]

Dựa trên doanh thu năm 2014, các hãng dẫn đầu thị trường NoSQL là MarkLogic, MongoDB, và Datastax.^[18] Dựa trên các bảng xếp hạng phổ biến năm 2015, Các cơ sở dữ liệu NoSQL phổ biến nhất là MongoDB, Apache Cassandra, và Redis.^[19]

Có nhiều cách phân loại các cơ sở dữ liệu NoSQL khác nhau, mỗi loại với các loại và loại con khác nhau, một số trong số đó có thể chồng chéo lên nhau. Một phân loại cơ bản dựa trên mô hình dữ liệu, với các ví dụ:

• Column: Accumulo, Cassandra, Druid, HBase, Vertica
• Document: Apache CouchDB, Clusterpoint, Couchbase, DocumentDB, HyperDex, Lotus Notes, MarkLogic, MongoDB, OrientDB, Qizx, RethinkDB
• Key-value: Aerospike, CouchDB, Dynamo, FairCom c-treeACE, FoundationDB, HyperDex, MemcacheDB, MUMPS, Oracle NoSQL Database, OrientDB, Redis, Riak, Berkeley DB
• Graph: AllegroGraph, InfiniteGraph, MarkLogic, Neo4J, OrientDB, Virtuoso, Stardog
• Multi-model: Alchemy Database, ArangoDB, CortexDB, FoundationDB, MarkLogic, OrientDB

Một phân loại chi tiết hơn như sau, dựa trên cách phân loại của Stephen Yen:^[20]

Loại	Ví dụ
Key-Value Cache	Coherence, eXtreme Scale, GigaSpaces, GemFire, Hazelcast, Infinispan, JBoss Cache, Memcached, Repcached, Terracotta, Velocity
Key-Value Store	Flare, Keyspace, RAMCloud, SchemaFree, Hyperdex, Aerospike
Key-Value Store (Eventually-Consistent)	DovetailDB, Oracle NoSQL Database, Dynamo, Riak, Dynomite, MotionDb, Voldemort, SubRecord
Key-Value Store (Ordered)	Actord, FoundationDB, Lightcloud, LMDB, Luxio, MemcacheDB, NMDB, Scalaris, TokyoTyrant
Máy chủ Cấu trúc dữ liệu	Redis
Tuple Store	Apache River, Coord, GigaSpaces
Cơ sở dữ liệu đối tượng	DB4O, Objectivity/DB, Perst, Shoal, ZopeDB
Document Store	Clusterpoint, Couchbase, CouchDB, DocumentDB, Lotus Notes, MarkLogic, MongoDB, Qizx, RethinkDB, XML-databases
Wide Column Store	BigTable, Cassandra, Druid, HBase, Hypertable, KAI, KDI, OpenNeptune, Qbase

Các cơ sở dữ liệu tương quan là mô hình độc lập, và thay vì là kho lưu trữ theo hàng hoặc theo cột, nó lại lưu trữ dựa trên giá trị.

Kho lưu trữ khóa-giá trị (Key-value: KV) sử dụng mảng kết hợp (còn được gọi là bản đồ hoặc từ điển) như là mô hình dữ liệu cơ bản của chúng. Trong mô hình này, dữ liệu được biểu diễn như một bộ sưu tập các cặp khóa-giá trị, như vậy mỗi khoá có thể xuất hiện chỉ một lần trong bộ sưu tập.^[21][22]

Mô hình khóa-giá trị là một trong những mô hình dữ liệu không tầm thường đơn giản nhất, và các mô hình dữ liệu phong phú hơn thường được thực hiện như một phần mở rộng của nó. Mô hình khóa-giá trị có thể được mở rộng tới một mô hình ra lệnh rời rạc, duy trì các khóa trong lệnh từ điển.Phần mở rộng này có khả năng tính toán mạnh mẽ, trong đó nó có thể truy hồi hiệu quả các dãy khóa chọn lọc.^[23]

Các kho lưu trữ khóa-giá trị có thể sử dụng các mô hình thống nhất bao gồm từ thống nhất cuối cùng cho đến serializability. Một số cơ sở dữ liệu hỗ trợ đặt lệnh của các khóa. Có nhiều triển khai phần cứng khác nhau, và một số người dùng duy trì dữ liệu trong bộ nhớ (RAM), trong khi những người khác sử dụng ổ SSD hoặc đĩa cứng.

Các ví dụ bao gồm cơ sở dữ liệu Oracle NoSQL, Redis, và dbm.

Khái niệm trung tâm của một kho lưu trữ tài liệu là khái niệm về "tài liệu". Trong khi mỗi cơ sở dữ liệu hướng tài liệu thực hiện khác nhau về chi tiết của định nghĩa này, nói chung, tất cả chúng đều giả định rằng các tài liệu đóng gói và mã hóa dữ liệu (hoặc thông tin) trong một số định dạng hoặc mã hóa tiêu chuẩn. Mã hóa được sử dụng bao gồm XML, YAML, và JSON cũng như các dạng nhị phân như BSON. Các tài liệu được định địa chỉ trong cơ sở dữ liệu thông qua một từ khóa duy nhất đại diện cho tài liệu đó. Một trong những đặc điểm định nghĩa khác của một cơ sở dữ liệu hướng tài liệu là ngoài việc tra cứu từ khóa được thực hiện bởi một kho lưu trữ khóa-giá trị, cơ sở dữ liệu đó còn cung cấp một API hoặc ngôn ngữ truy vấn để lấy tài liệu dựa trên nội dung của chúng

Những triển khai khác nhau cung cấp nhiều cách khác nhau để tổ chức và/hoặc nhóm các tài liệu:

• Các bộ sưu tập
• Thẻ đánh dấu (tag)
• Siêu dữ liệu không nhìn thấy được
• Phân cấp thư mục

So với cơ sở dữ liệu quan hệ, ví dụ, các bộ sưu tập có thể được coi là tương tự như các bảng biểu và các tài liệu tương tự như các hồ sơ/bản ghi. Nhưng chúng là khác nhau: mỗi bản ghi trong một bảng có cùng một trình tự của các miền, trong khi các tài liệu trong bộ sưu tập có thể có các miền hoàn toàn khác nhau.

Loại cơ sở dữ liệu này được thiết kế cho dữ liệu có quan hệ cũng được biểu diễn như một đồ thị bao gồm các yếu tố kết nối qua lại với một số hữu hạn các quan hệ giữa chúng. Loại dữ liệu này có thể là các mối quan hệ xã hội, liên kết giao thông công cộng, bản đồ đường bộ hoặc các topo mạng.

Tên	Ngôn ngữ	Ghi chú
AllegroGraph	SPARQL	RDF triple store
DEX/Sparksee	C++, Java, .NET, Python	Graph database
FlockDB	Scala	Graph database
IBM DB2	SPARQL	RDF triple store added in DB2 10
InfiniteGraph	Java	Graph database
MarkLogic	Java, JavaScript, SPARQL, XQuery	Multi-model document database and RDF triple store
Neo4j	Cypher	Graph database
OWLIM	Java, SPARQL 1.1	RDF triple store
Oracle	SPARQL 1.1	RDF triple store added in 11g
OrientDB	Java	Multi-model document and graph database
Sqrrl Enterprise	Java	Graph database
OpenLink Virtuoso	C++, C#, Java, SPARQL	Middleware and database engine hybrid
Stardog	Java, SPARQL	Graph database

• db4o
• GemStone/S
• InterSystems Caché
• JADE
• NeoDatis ODB
• ObjectDatabase++
• ObjectDB
• Objectivity/DB
• ObjectStore
• ODABA
• Perst
• OpenLink Virtuoso
• Versant Object Database
• ZODB

• Apache Accumulo
• BigTable
• Apache Hbase
• Hypertable
• Mnesia
• OpenLink Virtuoso

• Apache River
• GigaSpaces
• Tarantool
• TIBCO ActiveSpaces
• OpenLink Virtuoso

• AllegroGraph
• Apache JENA (Nó là một nền tảng, không phải là một cơ sở dữ liệu)
• MarkLogic
• Ontotext-OWLIM
• Oracle NoSQL database
• SparkleDB
• Virtuoso Universal Server
• Stardog

• Amazon DynamoDB
• Amazon SimpleDB
• Datastore on Google Appengine
• Clusterpoint database
• Cloudant Data Layer (CouchDB)
• Freebase
• Microsoft Azure Tables ^[24]
• Microsoft Azure DocumentDB ^[25]
• OpenLink Virtuoso

• D3 Pick database
• Động cơ lưu trữ mở rộng (ESE/NT)
• InfinityDB
• InterSystems Caché
• jBASE Pick database
• Northgate Information Solutions Reality, the original Pick/MV Database
• OpenQM
• Revelation Software's OpenInsight
• Rocket U2

• OrientDB
• FoundationDB
• ArangoDB
• MarkLogic

Ben Scofield sắp xếp các loại cơ sở dữ liệu NoSQL theo bảng sau:^[26]

Mô hình dữ liệu	Hiệu suất	Khả năng nâng cấp (mở rộng)	Tính linh hoạt	Độ phức tạp	Chức năng
Key–Value Store	cao	cao	cao	none	bất định (none)
Column-Oriented Store	cao	high	moderate	thấp	minimal
Document-Oriented Store	cao	bất định (high)	cao	thấp	bất định (low)
Graph Database	bất định	bất định	high	cao	graph theory
Relational Database	bất định	bất định	low	moderate	relational algebra

Performance and scalability comparisons are sometimes done with the YCSB benchmark.

Do hầu hết các cơ sở dữ liệu NoSQL thiếu khả năng kết nối trong các truy vấn, lược đồ cơ sở dữ liệu nói chung cần phải được thiết kế khác nhau. Có ba kỹ thuật chính để xử lý dữ liệu quan hệ trong một cơ sở dữ liệu NoSQL. (Xem bảng hỗ trợ Join và ACID cho cơ sở dữ liệu NoSQL có hỗ trợ các join.)

Thay vì lấy tất cả các dữ liệu với một truy vấn, ta thường thực hiện nhiều truy vấn khác nhau để có được các dữ liệu mong muốn. Các truy vấn NoSQL thường nhanh hơn so với truy vấn SQL truyền thống vì vậy chi phí của việc phải thực hiện các truy vấn bổ sung có thể chấp nhận được. Nếu số lượng truy vấn quá nhiều là cần thiết, một trong hai phương pháp khác sẽ thích hợp hơn.

Thay vì chỉ lưu giữ các từ khóa ngoại lai, ta thường lưu trữ các giá trị thực tế ngoại lai cùng với dữ liệu của mô hình. Ví dụ, mỗi bình luận blog có thể bao gồm tên người dùng, thêm vào đó là một id người dùng, do đó ta dễ dàng truy cập đến tên người dùng mà không cần phải có bất kỳ tra cứu nào khác. Khi một tên người dùng thay đổi tuy nhiên, điều này giờ đây sẽ cần phải được thay đổi ở nhiều nơi trong cơ sở dữ liệu. Vì vậy phương pháp này hoạt động tốt hơn khi việc đọc là phổ biến hơn nhiều so với việc ghi.^[27]

With document databases like MongoDB it's common to put more data in a smaller number of collections. For example, in a blogging application, one might choose to store comments within the blog post document so that with a single retrieval one gets all the comments. Thus in this approach a single document contains all the data you need for a specific task.

Nếu một cơ sở dữ liệu được đánh dấu là hỗ trợ ACID hoặc join, thì tài liệu cho cơ sở dữ liệu này làm sẽ thực hiện tuyên bố đó. Mức độ mà khả năng được hỗ trợ đầy đủ trong cách thức tương tự đối với hầu hết cơ sở dữ liệu SQL hoặc mức độ mà nó đáp ứng các nhu cầu của một ứng dụng cụ thể được để cho người đọc đánh giá.

Cơ sở dữ liệu	ACID	Joins
Aerospike	Có	Không
ArangoDB	Có	Có
CouchDB	Có	Có
c-treeACE	Có	Có
HyperDex	Có[nb 1]	Có
InfinityDB	Có	Không
LMDB	Có	Không
MarkLogic	Có	Có[nb 2]
OrientDB	Có	Có

• CAP theorem
• Comparison of object database management systems
• Comparison of structured storage software
• Correlation database
• Distributed cache
• Faceted search
• MultiValue database
• Multi-model database
• Triplestore

• Sadalage, Pramod; Fowler, Martin (2012). NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. Addison-Wesley. ISBN 0-321-82662-0.
• McCreary, Dan; Kelly, Ann (2013). Making Sense of NoSQL: A guide for managers and the rest of us. ISBN 9781617291074.
• Wiese, Lena (2015). Advanced Data Management for SQL, NoSQL, Cloud and Distributed Databases. DeGruyter/Oldenbourg. ISBN 978-3-11-044140-6.
• Strauch, Christof (2012). “NoSQL Databases” (PDF).
• Moniruzzaman, A. B.; Hossain, S. A. (2013). “NoSQL Database: New Era of Databases for Big data Analytics - Classification, Characteristics and Comparison”. arXiv:1307.0191. Chú thích journal cần |journal= (trợ giúp)
• Orend, Kai (2013). “Analysis and Classification of NoSQL Databases and Evaluation of their Ability to Replace an Object-relational Persistence Layer”. CiteSeer^x: 10.1.1.184.483. Chú thích journal cần |journal= (trợ giúp)
• Krishnan, Ganesh; Kulkarni, Sarang; Dadbhawala, Dharmesh Kirit. “Method and system for versioned sharing, consolidating and reporting information”.

• Strauch, Christoph. "NoSQL whitepaper" (PDF). Stuttgart: Hochschule der Medien. 
• Edlich, Stefan. "NoSQL database List" Lưu trữ 2018-12-26 tại Wayback Machine. 
• Neubauer, Peter (2010). "Graph Databases, NOSQL and Neo4j". 
• Bushik, Sergey (2012). "A vendor-independent comparison of NoSQL databases: Cassandra, HBase, MongoDB, Riak" Lưu trữ 2014-05-28 tại Wayback Machine. NetworkWorld. 
• Zicari, Roberto V. (2014). "NoSQL Data Stores – Articles, Papers, Presentations". odbms.org.