Bài viết được sự cho phép của tác giả Edward Thiên Hoàng
Trong thế giới của CSDL hiện tại ta có hai loại giải pháp chính đó là: SQL và NoSQL (cơ sở dữ liệu quan hệ và cơ sở dữ liệu phi quan hệ). Cả hai đều rất khác nhau về cách chúng được xây dựng, loại dữ liệu nó chúng lưu trữ và cả cách thức lưu trữ dữ liệu của chúng.
Cơ sở dữ liệu quan hệ lưu trữ những dữ liệu có cấu trúc rõ ràng ví dụ như danh bạ điện thoại thì sẽ chắc chắn sẽ chứa tên người và số điện thoại của người đó.
Còn cơ sở dữ liệu phi quan hệ lưu trữ giữ liệu không có cấu trúc, cấu trúc của nó rất động và phân tán, ví dụ như chứa một tệp tài liệu (document) về người dùng như số điện thoại, địa chỉ, hay những activity của họ trên Facebook hay các trang mua sắm trực tuyến. Dữ liệu của nó thường dưới dạng key-value dạng JSON, và những document có thể được tạo mà không cần phải xác định trước cấu trúc.
SQL
CSDLQH chứa dữ liệu theo dạng dòng (rows) và cột(columns). Mỗi dòng sẽ chứa những thông tin của dữ liệu và mỗi cột sẽ chứa những đặc điểm của dữ liệu, giữa các bảng có thể có liên kết với nhau qua khóa ngoại (foreign key). Một số CSDLQH phổ biến là MySQL, Oracle, MS SQL Server, SQLite, Postgres, MariaDB và IMB D2.
Tham khảo ngay các SQL Developer Jobs tại đây
NOSQL
NoSQL được phân thành 4 loại chính sau:
Key-Value Stores:
Dữ liệu sẽ được lưu dưới dạng cặp key-value, với ‘key’ là thuộc tính duy nhất để liên kết với giá trị (value) của nó. Các Key-Value stores nổi tiếng bao gồm Redis hay Amazon DynamoDB.
Document Databases:
Là DB chứa dữ liệu dạng theo kiểu các tệp tài liệu (document) để thay thế cho kiểu dòng và cột trong table và nhiều document gộp lại sẽ thành một Collection. Khác với kiểu table là mỗi document sẽ chưa các dạng cấu trúc khác nhau. Ví dụ trong MongoDB thì mỗi document sẽ chứa dữ liệu kiểu JSON, tức là mỗi document là một JSON. Document DB tiêu biểu hiện tại có MongoDB và CouchDB.
Wide-Column Databases:
Wide-Column hay còn gọi là Big-Table là mô hình dữ liệu để lưu trữ dữ liệu với khả năng mỗi rows chứa rất nhiều column(cột) mỗi cột lại là một cặp key-value, và ở đây số lượng cột là tùy biến (dynamic) cho mỗi rows, có nghĩa là số cột ở mỗi rows là khác nhau. Có thể thấy nó giống như kiểu key-value hai chiều với mỗi key lại chứa nhiều cặp key-value bên trong. Các Wide-Column DB tiêu biểu bao gồm Cassandra hay HBase.
Graph Databases
DB dạng này sẽ lưu dữ liệu dạng cấu trúc dữ liệu kiểu đồ thị (graph) để biểu thị mối quan hệ giữa các dữ liệu với nhau. Dữ liệu được lưu vào các nodes (entities) và thuộc tính của node, liên kết giữa các nodes sẽ qua các lines. Graph DB phổ biến có Neo4J và InfiniteGraph.
Mô tả quan hệ trên Facebook của người dùng sử dụng Graph DB
SỰ KHÁC NHAU GIỮA SQL VÀ NOSQL
Lưu trữ — Storage:
– SQL lưu trữ dữ liệu trong các bảng (tables) trong đó mỗi row đại diện cho một thực thể dữ liệu (entity), và mỗi column sẽ chứa các thuộc tính của entity; ví dụ nếu ta chứa dữ liệu của thực thể xe hơi (car entity) ta sẽ lưu trữ vào một bảng dữ liệu có nhiều column đại diện cho đặc điểm của chiếc xe đó như “màu” “nhãn hiệu” “hãng sản xuất” …
– NoSQL lưu trữ dữ liệu trên rất nhiều loại cấu trúc dữ liệu khác nhau như đã bàn bên trên như dạng key-value, document hay graph.
Lược đồ dữ liệu của thực thể — Schema:
– Trong SQL thì mỗi bản ghi có schema là cố định, tức là mỗi column trong table phải được định nghĩa từ trước khi tạo bảng, và mỗi khi dữ liệu được thêm vào một row thì các column của nó phải có giá trị (chấp nhận giá trị NULL). Các schema có thể được thay đổi sau đó (alter table), nhưng sự thay đổi này phải nằm ở phía Database và khi DB thực hiện thay đổi này nó sẽ offline tạm thời.
– Trong NoSQL, schema là động (dynamic) có nghĩa là ta không cần phải định nghĩa một schema nào trước mà schema sẽ được dựa vào cấu trúc của records được đưa vào.
Truy vấn — Querying:
– SQL truy vấn thông qua một ngôn ngữ truy vấn mang tính cấu trúc được gọi là Structured Query Language (SQL) thao tác với dữ liệu. SQL là một ngôn ngữ rất mạnh mẽ và lâu đời là đại diện duy nhất cho toàn bộ các RDBMS khác nhau.
– NoSQL truy vấn của nó thường được gọi là UnSQL (Unstructured Query Language) mỗi dạng NoSQL khác nhau sẽ có cấu trúc cú pháp (syntax) khác nhau để có thể lấy ra các dạng dữ liệu khác nhau (collection, key-value, node …)
Khả năng mở rộng — Scalability:
– Trong hầu hết các RDBMS thì khả năng mở rộng là theo chiều ngang (vertically scalable) ví dụ như tăng sức mạnh phần cứng của máy chủ hiện tại (tăng CPU, Ram…), tất nhiên rằng cách làm này rất đắt đỏ cũng như tốn thời gian mà đặc biệt là nó luôn có giới hạn nào đó.
– Còn với NoSQL DB thì hỗ trợ rất tốt cho mở rộng theo chiều dọc (horizontally scalable), có nghĩa là đơn giản chỉ thêm server vào các nodes hiện có, cách làm này đơn giản cũng như rẻ tiền hơn. Phần lớn các NoSQL DB công việc này đã được hỗ trợ sẵn và được làm tự động, có nghĩa là rất dễ để triển khai.
Độ tin cậy — Reliability:
– Hầu hết các RDBMS đều tuân thủ theo các thuộc tính của ACID(atomicity, consistency, isolation, và durability) vì vậy nó rất đảm bảo độ tin cậy và bảo toàn dữ liệu.
– Còn với NoSQL thì đa phần sẽ hy sinh tính chất ACID để đánh đổi với performance (hiệu năng) và khả năng mở rộng (scalability).
KHI NÀO THÌ CHÚNG TA SỬ DỤNG SQL HAY NOSQL
SQL hay NoSQL đều có những tính chất khác nhau phục vụ cho những nhu cầu đặc biệt khác nhau, do vậy không có DB nào thực sự là hoàn hảo phù hợp cho mọi nhu cầu tùy vào mục đích của hệ thống sở tại. Ngay cả khi hiện tại NoSQL đang trở nên phổ biến rộng rãi về tốc độ và khả năng mở rộng, nhưng vẫn có tình huống mà một SQL DB sẽ hoạt động tốt hơn (ví dụ hệ thống về giao dịch tiền tệ cần đảm bảo về tính ACID)
Lý do sử dụng SQL DB
1. Ứng dụng yêu cầu sử lý dữ liệu theo các transaction để tuân thủ tính ACID để bảo toàn tính nhất quán và toàn vẹn của dữ liệu bằng cách quy định các thuộc tính ACID bắt buộc khi thực hiện một transaction, ví dụ như các hệ thống về tài chính hay thương mại điện tử.
2. Nếu ứng dụng của hệ thống được xác định trước cấu trúc dữ liệu, và nghiệp vụ không đòi hỏi sự mở rộng trong tương lai và đòi hỏi sự nhất quán (consistent) trong dữ liệu.
Lý do sử dụng NoSQL DB
1. Hệ thống đòi hỏi cần lưu một số lượng cực lớn dữ liệu không có cấu trúc rõ ràng ngay từ đầu và tăng dần theo thời gian. Lúc này NoSQL là sự lựa chọn tốt nhất vì tính không rằng buộc trong kiểu dữ liệu (data type) bằng cách lưu trữ dữ liệu dạng document và tính chất mở rộng theo chiều ngang (horizontally scalable).
2. Các hệ thống cần phát triển nhanh (rapid development). NoSQL rất phù hợp với rapid development bởi vì nó không cần mất thời gian chuẩn bị (cấu trúc DB, cấu trúc bảng cột…). Nếu chúng ta cần làm việc với hệ thống nghiệp vụ chưa thực sự rõ ràng ngay từ đầu và đòi hỏi sự linh hoạt thay đổi “data type” giữa các sprint mà không ảnh hưởng cũng như đòi hỏi sự thay đổi hay độ trễ (downtime) tới hệ thống giữa các version, lúc này cơ sở dữ liệu quan hệ (RDBMS) sẽ làm chậm chúng ta lại.
3. Hệ thống được xây dựng và lưu trữ dữ liệu trên Cloud Computing. Lưu trữ dữ liệu trên Cloud là một giải pháp tiết kiệm chi phí tuyệt vời nhưng đòi hỏi dữ liệu phải lưu trữ đồng thời trên nhiều máy chủ để mở rộng quy mô (scale up). NoSQL như Cassandra được thiết kế tối ưu cho việc này mà không cần ta phải động tay động chân quá nhiều.
(*) Bonus: Bên trên tôi nhắc khá nhiều về transaction và ACID, vậy hãy đi qua một chút thế nào là một transaction và ACID?
Một transaction là một quá trình xử lý từ khi bắt đầu tới khi kết thúc thỏa mãn bốn tính chất ACID. Bốn chữ đó viết tắt của bốn tính chất quan trọng sau:
Atomicity: tính “nguyên tử” của giao dịch. Nghĩa là mọi giao dịch chỉ thành công khi tất cả các phần thành công All or Nothings.
Consistency: tính nhất quán. Nghĩa là mọi dữ liệu được thao tác đều nhất quán với tất cả các quy tắc (rules), các ràng buộc (constraint)… trong toàn bộ quá trình xử lý từ khi bắt đầu tới khi kết thúc.
Isolation: tính cô lập. Nó đảm bảo việc thực thi đồng thời của các giao dịch chỉ có thể có kết quả khi các giao dịch được thực hiện tuần tự. Ví dụ: hai giao dịch cùng sửa một table, thì các giao dịch đó phải được thực hiện tuần tự, giao dịch này xong mới tới giao dịch kia.
Durability: tính bền. Nghĩa là mọi giao dịch khi commit thì kết quả nó phải được đảm bảo, cho dù ứng dụng bị tắt, mất điện server.
Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com
Có thể bạn quan tâm:
- Vì sao SQL tốt hơn NoSQL? (Phần 1)
- Full stack developer là gì? Bí kiếp để trở thành 1 fullstack developer
- Vì sao SQL tốt hơn NoSQL? (Phần 2)
Xem thêm Việc làm It Jobs for Developer hấp dẫn trên TopDev
