Cơ sở dữ liệu NoSQL (tên gốc là “Non SQL” (phi SQL) hoặc “non relational” (phi quan hệ)) 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. 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. 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ệ), 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ệ. 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ó. 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 những cơ sở tài liệu NoSQL đưa ra một khái niệm ” thống nhất ở đầu cuối ” trong đó những đổi khác cơ sở tài liệu được truyền đến tổng thể những nút ” ở đầu cuối ” ( thường là trong mili giây ) để những truy vấn tài liệu hoàn toàn có thể không trả lại được tài liệu update ngay lập tức hoặc hoàn toàn có thể dẫn đến việc đọc tài liệu không đúng chuẩn, một yếu tố được gọi đọc lâu ( stale read ). Ngoài ra, một số ít mạng lưới hệ thống NoSQL hoàn toàn có thể bộc lộ bị mất những bản ghi và những hình thức mất tài liệu khác. May mắn thay, 1 số ít mạng lưới hệ thống NoSQL cung ứng những khái niệm như bản ghi ghi-trước ( write-ahead logging ) để tránh bị mất tài liệu. Đối với giải quyết và xử lý thanh toán giao dịch phân tán trên nhiều cơ sở tài liệu, tính thống nhất của tài liệu là một thử thách lớn hơn, đó là khó khăn vất vả cho cả cơ sở tài liệu kiểu NoSQL và cả cơ sở tài liệu kiểu quan hệ. Ngay cả cơ sở tài liệu kiểu quan hệ hiện tại ” không được cho phép những ràng buộc toàn vẹn tham chiếu để nối ( span ) những cơ sở tài liệu. ” Có vài mạng lưới hệ thống duy trì cả thanh toán giao dịch ACID và cả những tiêu chuẩn X / Open XA cho giải quyết và xử lý thanh toán 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ệ. 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`”, á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ở”. 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ệ.
Bạn đang đọc: NoSQL – Wikipedia tiếng Việt
NoSQL – Wikipedia tiếng Việt
Dựa trên lệch giá năm năm trước, những hãng đứng vị trí số 1 thị trường NoSQL là MarkLogic, MongoDB, và Datastax. [ 18 ] Dựa trên những bảng xếp hạng phổ cập năm năm ngoái, Các cơ sở tài liệu NoSQL thông dụng nhất là MongoDB, Apache Cassandra, và Redis. [ 19 ]
Phân loại và những ví dụ về những cơ sở tài liệu NoSQL
Có nhiều cách phân loại những cơ sở tài liệu NoSQL khác nhau, mỗi loại với những loại và loại con khác nhau, một số ít trong số đó hoàn toàn có thể chồng chéo lên nhau. Một phân loại cơ bản dựa trên quy mô tài liệu, với những ví dụ :
Column: Accumulo, Cassandra, Druid, HBase, VerticaDocument: Apache CouchDB, Clusterpoint, Couchbase, DocumentDB, HyperDex, Lotus Notes, MarkLogic, MongoDB, OrientDB, Qizx, RethinkDBKey-value: Aerospike, CouchDB, Dynamo, FairCom c-treeACE, FoundationDB, HyperDex, MemcacheDB, MUMPS, Oracle NoSQL Database, OrientDB, Redis, Riak, Berkeley DBGraph: AllegroGraph, InfiniteGraph, MarkLogic, Neo4J, OrientDB, Virtuoso, StardogMulti-model: Alchemy Database, ArangoDB, CortexDB, FoundationDB, MarkLogic, OrientDB
Một phân loại chi tiết cụ thể 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ở tài liệu đối sánh tương quan là quy mô độc lập, và thay vì là kho tàng trữ theo hàng hoặc theo cột, nó lại tàng trữ dựa trên giá trị .
Kho tàng trữ khóa-giá trị
Kho tàng trữ khóa-giá trị ( Key-value : KV ) sử dụng mảng tích hợp ( còn được gọi là map hoặc từ điển ) như là quy mô tài liệu cơ bản của chúng. Trong quy mô này, tài liệu được trình diễn như một những cặp khóa-giá trị, như vậy mỗi khoá hoàn toàn có thể Open chỉ một lần trong . [ 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 tàng trữ khóa-giá trị hoàn toàn có thể sử dụng những quy mô thống nhất gồm có từ thống nhất ở đầu cuối cho đến serializability. Một số cơ sở tài liệu tương hỗ đặt lệnh của những khóa. Có nhiều tiến hành phần cứng khác nhau, và một số ít người dùng duy trì tài 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ụ gồm có cơ sở tài liệu Oracle NoSQL, Redis, và dbm .
Lưu trữ tài liệu
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 tiến hành khác nhau phân phối nhiều cách khác nhau để tổ chức triển khai và / hoặc nhóm những tài liệu :
Các Thẻ đánh dấu (tag)Siêu dữ liệu không nhìn thấy đượcPhân cấp thư mục
So với cơ sở tài liệu quan hệ, ví dụ, những hoàn toàn có thể được coi là tương tự như như những bảng biểu và những tài liệu tương tự như như những 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 những miền, trong khi những tài liệu trong hoàn toàn có thể có những miền trọn vẹn khác nhau . Loại cơ sở tài liệu này được phong cách thiết kế cho tài liệu có quan hệ cũng được màn biểu diễn như một đồ thị gồm có những yếu tố liên kết qua lại với một số ít hữu hạn những quan hệ giữa chúng. Loại tài liệu này hoàn toàn có thể là những mối quan hệ xã hội, link giao thông vận tải công cộng, map đường đi bộ hoặc những topo mạng .
Cơ sở tài liệu đối tượng người tiêu dùng
db4oGemStone/SInterSystems CachéJADENeoDatis ODBObjectDatabase++ObjectDBObjectivity/DBObjectStoreODABAPerstOpenLink VirtuosoVersant Object DatabaseZODB
Apache AccumuloBigTableApache HbaseHypertableMnesiaOpenLink Virtuoso
Apache RiverGigaSpacesTarantoolTIBCO ActiveSpacesOpenLink Virtuoso
AllegroGraphApache JENA (Nó là một nền tảng, không phải là một cơ sở dữ liệu)MarkLogicOntotext-OWLIMOracle NoSQL databaseSparkleDBVirtuoso Universal ServerStardog
Cơ sở tài liệu đa giá trị
D3 Pick databaseĐộng cơ lưu trữ mở rộng (ESE/NT)InfinityDBInterSystems CachéjBASE Pick databaseNorthgate Information Solutions Reality, the original Pick/MV DatabaseOpenQMRevelation Software’s OpenInsightRocket U2
Cơ sở tài liệu đa quy mô
OrientDBFoundationDBArangoDBMarkLogic
Ben Scofield sắp xếp những loại cơ sở tài 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 .
Xử lý tài liệu quan hệ
Do hầu hết những cơ sở tài liệu NoSQL thiếu năng lực liên kết trong những truy vấn, lược đồ cơ sở tài liệu nói chung cần phải được phong cách thiết kế khác nhau. Có ba kỹ thuật chính để giải quyết và xử lý tài liệu quan hệ trong một cơ sở tài liệu NoSQL. ( Xem bảng tương hỗ Join và ACID cho cơ sở tài liệu NoSQL có tương hỗ những join. )
Đa truy vấn
Thay vì lấy toàn bộ những tài liệu với một truy vấn, ta thường thực thi nhiều truy vấn khác nhau để có được những tài liệu mong ước. Các truy vấn NoSQL thường nhanh hơn so với truy vấn SQL truyền thống cuội nguồn thế cho nên ngân sách của việc phải thực thi những truy vấn bổ trợ hoàn toàn có thể gật đầu được. Nếu số lượng truy vấn quá nhiều là thiết yếu, một trong hai chiêu thức khác sẽ thích hợp hơn .
Dữ liệu bộ nhớ đệm / sao chép / không-chuẩn hoá
Thay vì chỉ lưu giữ những từ khóa ngoại lai, ta thường tàng trữ những giá trị thực tiễn ngoại lai cùng với tài liệu của quy mô. Ví dụ, mỗi phản hồi blog hoàn toàn có thể gồm có tên người dùng, thêm vào đó là một id người dùng, do đó ta thuận tiện truy vấn đế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 đổi khác tuy nhiên, điều này giờ đây sẽ cần phải được đổi khác ở nhiều nơi trong cơ sở tài liệu. Vì vậy chiêu thức này hoạt động giải trí tốt hơn khi việc đọc là thông dụng 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.
Hỗ trợ ACID và JOIN
Nếu một cơ sở tài liệu được lưu lại là tương hỗ ACID hoặc join, thì tài liệu cho cơ sở tài liệu này làm sẽ thực thi công bố đó. Mức độ mà năng lực được tương hỗ vừa đủ trong phương pháp tựa như so với hầu hết cơ sở tài liệu SQL hoặc mức độ mà nó phân phối những nhu yếu của một ứng dụng đơn cử được để cho người đọc nhìn nhận .
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ó
^HyperDex hiện tại đã tương hỗ ACID trải qua phần hỗ trợ ( extension ) Warp, một add-on thương mại .^[28]Joins không nhất thiết phải ứng dụng vào tài liệu cơ sở tài liệu, nhưng MarkLogic hoàn toàn có thể thực thi joins bằng Semantics .
CAP theoremComparison of object database management systemsComparison of structured storage softwareCorrelation databaseDistributed cacheFaceted searchMultiValue databaseMulti-model databaseTriplestore