1. NoSQL là gì?
Cái tên nói lên tất cả, No trong NoSQL có thể hiểu theo 2 cách sau:
- Không sử dụng SQL.
- No relation.
Như vậy NoSQL nói đến những loại non-relational database lưu trữ data KHÔNG theo dạng table - column - row, data KHÔNG thể hiện quan hệ với nhau, và cũng KHÔNG sử dụng SQL để tương tác với data.
Vậy nếu muốn tương tác với data trong non-relational database thì làm cách nào? Mỗi database khác nhau sẽ có những cách thức khác nhau để làm điều này. Ví dụ với Elasticsearch là các REST APIs, Redis là các command line...
Trong thế giới NoSQL - non-relational database, tính đến thời điểm hiện tại có 4 mô hình lưu trữ data là:
- Document database: MongoDB, CouchDB...
- Key - value store: Redis, LevelDB, RocksDB...
- Wide column: Cassandra, Bigtable, HBase...
- Graph database: JanusGraph, Neo4j, TigerGraph...
Nếu đi sâu vào từng model thì dài quá, mình sẽ đề cập trong bài viết khác. Về cơ bản cả 4 loại đều có những phần chung về cơ chế lưu trữ và tổ chức data để phân biệt với relation database, do vậy mình sẽ chọn một loại phổ biến và tiêu biểu nhất là MongoDB để lấy ví dụ về NoSQL.
2. MongoDB tổ chức data thế nào?
Với SQL, ta có database Shop bao gồm các table User, Product, Order với mỗi table bao gồm các row (record) có nhiều column đại diện cho thông tin của một loại data.
Sang đến NoSQL sẽ không còn khái niệm table, column, record nữa mà thay vào đó cụ thể với MongoDB là collection, document, key, value. Trông nó sẽ như này:
Dễ dàng nhận thấy collection tương đương với table, document tương đương với record (row), JSON key tương đương với column trong mối tương quan giữa SQL và NoSQL.
Ngoài ra một điều đặc biệt khác là document tổ chức data dưới dạng JSON và KHÔNG cần tuân theo một schema cố định. Điều đó nghĩa là có thể có nhiều documents khác schema, khác structure, khác field trong cùng một collection.
Như vậy có thể hiểu rằng trong cùng collection User hoàn toàn có thể có document của Order. Nhưng không ai làm như thế cả! Việc các document khác schema là trong trường hợp có các extra field như ví dụ trên với SQL thì việc tổ chức data sẽ gọn nhẹ hơn nhiều. Trông nó như này:
Mặc dù nó giúp tiết kiệm không gian và làm cho data structure linh động hơn, không cần phải sửa schema khi bỗng dưng có một document đặc biệt có vài extra field (vì làm gì có schema mà sửa), nhưng chính nó cũng là nhược điểm, vì không có schema nên khó khăn trong việc dự đoán format của data.
Nhưng nếu chọn NoSQL ngay từ đầu thì không cần quan tâm lắm đến vấn đề này vì nó đã có ưu điểm quá to là super flexible data structure.
Ví dụ khi build software sử dụng SQL chạy rất ổn định, mượt mà. Nhưng đến một lúc nào đó muốn hiển thị nhiều thông tin hơn, hay cụ thể là muốn lưu trữ và query nhiều data hơn cho một vài user trong User table, nếu sử dụng SQL thì chỉ có nước thêm column, sửa entity. Như vậy toàn bộ user trong User table đều được thêm column. Nhưng nếu sử dụng NoSQL thì... tuyệt vời rồi. User nào cần specific field nào thì cứ thêm thôi, những user khác không bị ảnh hưởng.
3. Relation
Chúng ta thường nghe và hiểu NoSQL hay no-relational database nghĩa là nói về việc các collections (Document database) không có mối quan hệ nào với nhau (phi quan hệ), ngược lại với SQL. Vậy nếu mối quan hệ User - Order - Product như ví dụ trên với SQL thì thể hiện trong NoSQL như thế nào vì trong thực tế cả 3 vẫn có mối liên quan đến nhau?
Trên lí thuyết, ta vẫn có thể setup relation giữa các document giống như SQL bằng cách thêm foreign key. Nhưng vấn đề là không thể sử dụng SQL để join và query data được nên việc tạo FK như vậy làm sai lệch đi bản chất của NoSQL là no-relation.
Idea để giải quyết vấn đề này của NoSQL là gom nhóm các data có liên quan với nhau vào cùng một chỗ và chấp nhận việc duplicate.
Ví dụ muốn hiển thị order cùng với một vài thông tin cơ bản của user và product, lúc này collection Order không chỉ chứa thông tin về order mà còn chứa thêm các thông tin cần thiết của user (id, name, email) và product (id, price). Trông như này:
Như vậy vẫn collection User, Product với các thông tin chi tiết, nhưng chúng ta không cần query relation đó vì nó đã được duplicate những field cần thiết sang collection Order. Và đây chính là idea của NoSQL, càng ít các quan hệ thì tốc độ và hiệu quả query càng nhanh (không cần join).
No silver bullet, chẳng có gì là hoàn hảo, và cũng chính ưu điểm trên là nhược điểm của NoSQL, phải chấp nhận data bị duplicate ở nhiều nơi. Update product data ở Product cũng kéo theo việc update product ở Order.
Nhưng nếu việc update hiếm khi xảy ra, và là read heavy (read nhiều hơn write) thì nó vẫn là một điều tuyệt vời ông mặt zời.
Một lưu ý nữa không phải là hoàn toàn không có relation, sẽ có những trường hợp vẫn cần relation nhưng cần hạn chế nhất có thể (no relation or less relation as possible).
Để tìm hiểu SQL là gì và câu chuyện giữa SQL và NoSQL như thế nào, hãy đón đọc bài viết tiếp theo nhé!
Sưu tầm
Japan IT Works
