NoSQL

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 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). 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. 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. Đố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." 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.

Lịch sử
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ệ.

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. 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.

Phân loại và các ví dụ về các cơ sở dữ liệu NoSQL
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:

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ị
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.

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.

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.

Lưu trữ dữ 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 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.

Đồ thị
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.

Cơ sở dữ liệu đối tượng
db4o
GemStone/S
InterSystems Caché
JADE
NeoDatis ODB
ObjectDatabase++
ObjectDB
Objectivity/DB
ObjectStore
ODABA
Perst
OpenLink Virtuoso
Versant Object Database
ZODB

Dạng bảng
Apache Accumulo
BigTable
Apache Hbase
Hypertable
Mnesia
OpenLink Virtuoso

Tuple store
Apache River
GigaSpaces
Tarantool
TIBCO ActiveSpaces
OpenLink Virtuoso

Triple/quad store (RDF) database
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

Hosted
Amazon DynamoDB
Amazon SimpleDB
Datastore on Google Appengine
Clusterpoint database
Cloudant Data Layer (CouchDB)
Freebase
Microsoft Azure Tables
Microsoft Azure DocumentDB
OpenLink Virtuoso

Cơ sở dữ liệu đa giá trị
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

Cơ sở dữ liệu đa mô hình
OrientDB
FoundationDB
ArangoDB
MarkLogic

Hiệu suất
Ben Scofield sắp xếp các loại cơ sở dữ liệu NoSQL theo bảng sau:

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

Xử lý dữ liệu quan hệ
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.)

Đa truy vấn
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.

Dữ liệu bộ nhớ đệm/sao chép/không-chuẩn hoá
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.

Nesting data
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ở 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á.

Xem thêm
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

Tham khảo

Đọc thêm





}}


Liên kết ngoài
Strauch, Christoph. "NoSQL whitepaper" (PDF). Stuttgart: Hochschule der Medien.&nbsp;
Edlich, Stefan. "NoSQL database List" .&nbsp;
Neubauer, Peter (2010). "Graph Databases, NOSQL and Neo4j".&nbsp;
Bushik, Sergey (2012). "A vendor-independent comparison of NoSQL databases: Cassandra, HBase, MongoDB, Riak" . NetworkWorld.&nbsp;
Zicari, Roberto V. (2014). "NoSQL Data Stores – Articles, Papers, Presentations". odbms.org.&nbsp;