Cơ sở dữ liệu quan hệ, được xây dựng trên mô hình của Dr. Edgar F. Codd, đã chứng minh là rất thành công trong suốt nhiều thập kỷ. Chúng đã trở thành xương sống của nhiều tổ chức từ nhỏ đến lớn.

Tuy nhiên, chúng ta cần hiểu rằng đây chỉ là một mô hình. Nó không phải là giải pháp duy nhất hay tối ưu cho mọi bài toán dữ liệu, bạn có thể hiểu đơn giản là không thể có giải pháp toàn diện phù hợp với mọi vấn đề (one size fits all).

Facebook bày tỏ quan điểm rằng việc gặp lỗi là điều không thể tránh khỏi khi họ đang phải vận hành hàng chục nghìn máy chủ trên toàn thế giới nên họ mong muốn thiết kế ra giải pháp lưu trữ "xem lỗi là điều bình thường" và họ đã tạo ra Cassandra vào năm 2007.

Mình chưa tìm được nguồn uy tín nào nói chi tiết về những vấn đề mà họ gặp phải với những giải pháp lưu trữ tin nhắn phục vụ cho chức năng Inbox Search trước đây, ngay cả trong bài báo khoa học của chính họ cũng không đề cập đến vấn đề này, ví dụ như: tin nhắn vừa gửi đi nhưng vào inbox thì lại không thấy, hoặc search bị timeout (này mình đoán thôi) , nên chúng ta tạm thời bỏ qua nhé.

1. Cassandra là gì?

Apache Cassandra là một cơ sở dữ liệu mã nguồn mở, phân tán (distributed), phi tập trung (decentralized), có khả năng mở rộng linh hoạt, tính sẵn sàng cao (highly available), chịu lỗi tốt, điều chỉnh được mức độ nhất quán, và column-oriented. Khá nhiều các bạn nhỉ 😵‍💫.

Kiến trúc phân tán của Cassandra dựa trên Dynamo của Amazon, trong khi mô hình dữ liệu của nó lấy cảm hứng từ Bigtable của Google. Cassandra được tạo ra tại Facebook và hiện nay được sử dụng tại một số trang web phổ biến nhất trên Internet (Facebook, Netflix, Apple, Uber ...).

2. Kiến trúc của Cassandra

• Kiến trúc phân tán (Distributed Architecture):
  • Dữ liệu được chia thành các partition bằng cách sử dụng hàm băm (Murmur3). Mỗi partition key sẽ xác định nơi lưu trữ dữ liệu trên các node trong cluster. Mỗi phần dữ liệu được sao chép (replica) đến một số node tùy theo Replication Factor.
  • Trong RDBMS: Một cơ sở dữ liệu chứa bảng orders được lưu trữ trên một máy chủ. Nếu máy chủ gặp sự cố, toàn bộ hệ thống bị ảnh hưởng.
  • Trong Cassandra: Bảng orders được chia nhỏ thành các partition và phân phối trên nhiều node. Nếu một node hỏng, các bản sao (replica) đảm bảo dữ liệu vẫn truy cập được.
• Phi tập trung (Decentralized):
  • Cassandra không có master hoặc slave. Tất cả các node đều ngang hàng (peer-to-peer). Node giao tiếp thông qua giao thức gossip, đảm bảo mỗi node biết trạng thái của các node khác
  • Trong RDBMS: Nếu master hỏng, cần failover sang slave, dẫn đến thời gian chết.
  • Trong Cassandra: Yêu cầu được chuyển sang các node khác mà không cần downtime.
• Khả năng mở rộng linh hoạt (Linear Scalability):
  • Mở rộng theo chiều ngang: Chỉ cần thêm node vào cluster.
• Tính sẵn sàng cao (Highly Available) và Chịu lỗi tốt (Fault Tolerant):
  • Replication: Dữ liệu được sao chép trên nhiều node. Nếu một node hỏng, dữ liệu vẫn có sẵn từ các replica.
  • Hinted Handoff: Khi một node không khả dụng, node khác giữ bản ghi tạm thời cho đến khi node gốc khôi phục.
  • Read Repair: Khi dữ liệu được đọc, Cassandra sửa chữa các bản sao bị lỗi hoặc không đồng bộ.
• Điều chỉnh được mức độ nhất quán (Tunable Consistency):
  • Cassandra cho phép điều chỉnh độ nhất quán theo nhu cầu của ứng dụng, Strong Consistency: Đảm bảo tất cả các replica được cập nhật trước khi phản hồi (consistency level = ALL). Eventual Consistency: Cho phép truy cập dữ liệu trước khi tất cả replica được đồng bộ (consistency level = ONE, QUORUM).
• Column-Oriented:
  • Cassandra tổ chức dữ liệu dưới dạng column family, tối ưu hóa cho truy vấn theo column. Thay vì phải đọc tất cả các cột trước đó của một hàng để lấy được cột cần như trong RDBMS, chúng ta chỉ cần đọc mỗi cột cần thiết mà thôi.

3. Cassandra và bài toán Inbox Search

Điểm gì đặc biệt trong kiến trúc của Cassandra khiến cho nó đáp ứng được nhu cầu của Inbox Search tại thời điểm đó?

Yêu cầu đặt ra là:

• Hiệu suất ghi cao: Mỗi tin nhắn mới phải được lưu trữ ngay lập tức để đảm bảo tính sẵn sàng của dữ liệu. Điều này đòi hỏi hệ thống có khả năng xử lý một lượng lớn các hoạt động ghi đồng thời mà không làm giảm hiệu suất (bị khoá hàng, khoá bảng, tranh chấp tài nguyên ...)
• Tìm kiếm nhanh: Người dùng mong đợi kết quả tìm kiếm nhanh chóng và chính xác trong hộp thư đến của họ, ngay cả khi số lượng tin nhắn rất lớn. Điều này yêu cầu hệ thống có khả năng truy vấn và truy xuất dữ liệu một cách hiệu quả.

Bạn thấy đấy vấn đề của họ không nhấn mạnh vào độ nhất quán ở mức độ cao, nó không giống với việc chuyển khoản 100k sau đó có chuyển khoản tiếp 100k được không, mà vì nó là tin nhắn nên nó cần phải ghi liền ngay lập tức, sau đó có thể search lại được, bạn bè của họ cũng nhận được notification ngay lập tức, vào đọc cũng phải thấy được tin nhắn.

Trong Cassandra ai cũng ngang hàng peer-to-peer, nên ghi vào node nào gần nhất cũng được cả, nó không cần phải tìm node master để tranh giành nhau ghi vào node master đó, nên bài toán ghi nhanh được giải quyết, ghi nhanh thì search cũng sẽ nhanh (kết hợp với partition và column-oriented).

Vậy làm sao để tin nhắn gửi từ Mỹ mà chúng ta ở Việt Nam vẫn có thể đọc được ngay? Rõ ràng đây lại là giao tiếp giữa hai khu vực khác nhau.

• Khi người dùng ở Mỹ gửi tin nhắn, Cassandra ghi bản sao vào các replica trong trung tâm dữ liệu cục bộ trước (DC tại Mỹ). Consistency Level (ví dụ: LOCAL_QUORUM) chỉ yêu cầu phần lớn các replica trong cùng vùng đó ghi thành công trước khi xác nhận với người dùng.
• Việc sao chép dữ liệu từ trung tâm dữ liệu Mỹ sang trung tâm dữ liệu Việt Nam được thực hiện không đồng bộ qua cơ chế asynchronous replication.
• Khi người nhận tại Việt Nam yêu cầu tin nhắn, Cassandra sẽ tìm kiếm từ trung tâm dữ liệu gần nhất (DC tại Việt Nam). Nếu replica chưa được đồng bộ, hệ thống sử dụng cơ chế hinted handoff hoặc read repair để đảm bảo dữ liệu được cập nhật từ DC Mỹ.

4. Kết luận

Cassandra là một giải pháp mà mình nghĩ các bạn nên thử khi làm việc với những bài toán yêu cầu write-heavy, bản thân mình cũng gặp khó khăn rất nhiều trong lúc tìm tài liệu về những vấn đề của Facebook nhưng họ chỉ nói những điều được phép nói, cũng không có một buổi chia sẻ nào như Q&A giữa Facebook và Developer nên thông tin về nó khá ít.

Các bài viết liên quan:

• Cách Discord Lưu Trữ Hàng Nghìn Tỷ Tin Nhắn Với ScyllaDB
• So sánh hiệu suất Query của PostgreSQL và MySQL
• Làm sao để liệt kê và revoke access token JWT
• Hướng dẫn sử dụng công cụ đánh giá CV miễn phí