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ượngcủ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.

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.

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.