Các loại NoSQL và quy trình mô hình hóa dữ liệu

1. Tổng quan

A. Định nghĩa

Nhóm công nghệ lưu trữ dữ liệu thoát khỏi các tiền đề của RDBMS là lược đồ quan hệ·SQL·tính nhất quán mạnh, được tối ưu cho yêu cầu dung lượng lớn·phi cấu trúc·phân tán·khả năng mở rộng cao. Như cái tên “Not Only SQL” cho thấy, nó không loại bỏ SQL mà là giải pháp thay thế bổ sung cho những vùng khó xử lý chỉ bằng mô hình quan hệ.

B. Bối cảnh ra đời và sự cần thiết

RDBMS mạnh với dữ liệu có cấu trúc đề cao tính nhất quán, nhưng để tăng hiệu năng lại phụ thuộc vào mở rộng theo chiều dọc (Scale-up) — nâng cấu hình máy chủ — nên vấp phải giới hạn vật lý·chi phí. Tuy nhiên, từ những năm 2000, các dịch vụ web quy mô lớn cần mở rộng theo chiều ngang (Scale-out) — chia lưu lượng bùng nổ và dữ liệu phi cấu trúc·bán cấu trúc như log·JSON·quan hệ xã hội ra nhiều máy chủ giá rẻ. Thêm vào đó, trong môi trường khó chốt lược đồ từ đầu và yêu cầu thay đổi liên tục, lược đồ cố định khóa toàn bộ bảng chỉ để thêm một cột trở thành trở ngại. NoSQL ra đời với mục tiêu ưu tiên lược đồ linh hoạt, mở rộng ngang, tính sẵn sàng cao như vậy.

C. So sánh đặc điểm với RDBMS

Điều quan trọng là NoSQL phải từ bỏ gì để đổi lấy các đặc tính này. Tiêu biểu là chọn tính nhất quán cuối cùng (BASE) thay cho tính nhất quán mạnh (ACID). Khi nhân bản·phân tán dữ liệu trên nhiều nút, việc luôn giữ mọi nút ở cùng trạng thái trở nên đắt đỏ, nên nó được nới lỏng để cho phép bất nhất tạm thời nhưng cuối cùng sẽ hội tụ.

2. Các loại NoSQL

flowchart LR
  N[NoSQL] --> KV[Key-Value]
  N --> DOC[Document]
  N --> COL[Column-Family]
  N --> GRP[Graph]

NoSQL được chia thành bốn loại tùy theo mô hình chứa dữ liệu, và mỗi loại phù hợp với mẫu truy cập khác nhau.

Key-Value là dạng đơn giản nhất, đưa vào và lấy ra giá trị bằng khóa. Cấu trúc đơn giản nên truy vấn rất nhanh, phù hợp để lưu cache·phiên (Redis). Document chứa tài liệu phân cấp như JSON/BSON ở vị trí giá trị, có thể lưu·truy vấn nguyên khối dữ liệu liên quan đến một thực thể, nên mạnh với dữ liệu bán cấu trúc (MongoDB). Column-Family lưu theo đơn vị cột chứ không phải hàng, có lợi cho phân tích đọc khối lượng lớn chỉ một số cột và ghi dữ liệu chuỗi thời gian (Cassandra, HBase). Graph biểu diễn dữ liệu bằng nút và cạnh (quan hệ), thực hiện nhanh việc duyệt quan hệ nối nhiều bước (bạn của bạn, gợi ý) mà không cần join (Neo4j).

3. Định lý CAP và lựa chọn tính nhất quán

Lý thuyết cốt lõi của thiết kế NoSQL là CAP. Hệ thống phân tán không thể đồng thời thỏa mãn cả ba: tính nhất quán (Consistency)·tính sẵn sàng (Availability)·khả năng chịu phân vùng (Partition tolerance), và vì phân vùng mạng (P) là không thể tránh trong thực tế, tại thời điểm xảy ra phân vùng phải từ bỏ một trong C và A. Khi liên lạc giữa các nút bị ngắt, nếu vẫn trả lời dù là giá trị cũ (chọn A) thì mất nhất quán, còn nếu chặn phản hồi để đảm bảo giá trị mới nhất (chọn C) thì tính sẵn sàng giảm.

Vì vậy, các sản phẩm NoSQL phân hóa khuynh hướng theo mục đích. Loại AP luôn ưu tiên phản hồi như Cassandra·DynamoDB được dùng cho các dịch vụ chấp nhận bất nhất tạm thời như news feed mạng xã hội, còn loại CP ưu tiên độ chính xác như HBase·MongoDB (tùy cấu hình) được dùng cho các vùng mà trả lời sai là chí mạng như tồn kho·số dư. Tức là lựa chọn CAP không phải sở thích kỹ thuật mà là trade-off do yêu cầu kinh doanh quyết định.

4. Quy trình mô hình hóa dữ liệu

flowchart LR
  A[Phân tích yêu cầu·truy vấn] --> B[Định nghĩa mẫu truy cập]
  B --> C[Thiết kế tổng hợp·phi chuẩn hóa]
  C --> D[Thiết kế khóa·chỉ mục]
  D --> E[Kiểm chứng·tinh chỉnh]

Đặc điểm lớn nhất của mô hình hóa NoSQL là hướng đi ngược hẳn với RDB. RDB chuẩn hóa cấu trúc dữ liệu (thực thể·quan hệ) trước rồi mới viết truy vấn cần thiết, còn NoSQL xác định trước sẽ truy vấn thế nào (query) rồi tạo cấu trúc dữ liệu cho phù hợp.

Ví dụ, trong thương mại điện tử, nếu “màn hình đơn hàng hiển thị cùng tên hội viên·tên sản phẩm”, thay vì join các bảng hội viên·sản phẩm·đơn hàng như RDB, ta sao chép trước và nhúng tên hội viên·tên sản phẩm vào trong tài liệu đơn hàng. Chỉ một lần truy vấn là hoàn thành màn hình nên nhanh, nhưng khi hội viên đổi tên thì phát sinh gánh nặng phải cập nhật mọi giá trị đã sao chép. Như vậy, mô hình hóa NoSQL là thiết kế chấp nhận độ phức tạp khi ghi và trùng lặp để đổi lấy hiệu năng đọc. Nếu chọn sai khóa phân vùng khiến yêu cầu dồn vào một nút (điểm nóng) thì khả năng mở rộng sụp đổ, nên thiết kế khóa là then chốt của hiệu năng.

5. Những điểm cần cân nhắc và hàm ý

• Lựa chọn tường minh giữa nhất quán và sẵn sàng: Phải quyết định một cách có ý thức trade-off CAP phù hợp với đặc tính dịch vụ, và các vùng bắt buộc chính xác như tài chính phải tránh áp dụng AP một cách tùy tiện.
• Gánh nặng thiết kế lại: Khi mẫu truy cập thay đổi thì phải thiết kế lại chính cấu trúc dữ liệu, nên độ chính xác của phân tích truy vấn ban đầu quyết định chi phí vận hành dài hạn.
• Lưu trữ đa ngôn ngữ (Polyglot Persistence): Hệ thống thực tế đang đi theo hướng kết hợp kho lưu trữ tối ưu theo mục đích như giao dịch có cấu trúc dùng RDB, phiên dùng Key-Value, gợi ý dùng Graph thay vì thống nhất vào một, và NewSQL đang tiến hóa như một sự dung hòa nhằm nắm được cả khả năng mở rộng của NoSQL lẫn ACID của RDB.

Tóm tắt một câu: NoSQL là nhóm công nghệ lưu trữ tối ưu cho dữ liệu dung lượng lớn·phi cấu trúc·phân tán gồm các loại Key-Value·Document·Column·Graph, lựa chọn nhất quán·sẵn sàng như một trade-off theo định lý CAP, và tuân theo mô hình hóa ưu tiên truy vấn — định nghĩa trước mẫu truy vấn rồi tránh join bằng phi chuẩn hóa·nhúng.