All Articles

Tất tần tật về Apache Cassandra

Nói về cơ sở dữ liệu thì chắc ai cũng nghĩ ngay đến hệ quản trị cơ sở dữ liệu quan hệ như Mysql, PostgreSQL, hay NoSQL như MongoDB, DynamoDB, Cassandra…

Và theo mình nghĩ đa số anh em ở đây cũng đang sử dụng chủ yếu là MySQL. Mình cũng vậy, từ lúc đi làm đến giờ toàn phang MySQL, chưa có cơ hội làm việc với NoSQL (tự tìm hiểu thì có còn dùng trong dự án thật thì chưa)

Kể cả các công ty to như Pinterest hay Instagram cũng vậy, họ vẫn đang dùng MySQL.

Còn NoSQL thì hiện nay thấy rất nhiều công ty đã dùng vào hệ thống chính của họ. Ví dụ như Netflix, Discord, Spotify …

Nên hôm nay quyết định viết bài này để tìm hiểu xem thật sự thằng Cassandra này nó có ưu điểm, nhược điểm gì, dễ scale hay không …

Khái quát qua về Cassandra

Cassandra là NoSQL, được phát triển bởi Facebook vào năm 2007. Sau đó nó được tặng cho quỹ Apache vào 2/2010 và nâng cấp lên thành dự án hàng đầu của Apache.

Cassandra là hệ cơ sở dữ liệu phân tán, kết hợp những gì tinh tuý nhất của Google Bigtable và Amazon DynamoDB. Ngôn ngữ phát triển Cassandra là Java.

Cassandra được thiết kế có thể chạy trong phần cứng giá rẻ, và cung cấp write throughput khá là cao (latency tầm 0.5ms), trong khi read throughput thì thấp hơn (latency tầm 2.5ms).

Nếu nói đến NoSQL thì chắc ai cũng đều có chút liên tưởng nó hoạt động thế nào rồi. Cassandra cũng vậy, dữ liệu được lưu vào table, sau đó dùng 1 ngôn ngữ query như SQL để thực hiện thao tác với dữ liệu.

Cassandra là hệ cơ sở dữ liệu phân tán, dữ liệu được lưu trữ trên nhiều node của nhiều máy khác nhau, theo cơ chế P2P. Hiệu năng xử lý của hệ thống cũng tăng theo số node (nếu càng nhiều node thì càng xử lý được nhiều request).

Điều đó sẽ giúp cho Cassandra dễ dàng scale theo chiều ngang.

Về hiệu năng thì Netflix cũng đã thực hiện đo benchmark, kết quả ngoài mong đợi. Với 288 nodes, Casandra đã đạt được throughput lên đến 1 triệu write/s. Khá kinh khủng.

Kết quả thực hiện đo benchmark ở đây: https://medium.com/netflix-techblog/benchmarking-cassandra-scalability-on-aws-over-a-million-writes-per-second-39f45f066c9e

Use Cases của Cassandra

Cassandra là 1 hệ cơ sở dữ liệu không quan hệ, và thường được sử dụng trong nhiều loại ứng dụng khác nhau. Dưới đây là 1 số use cases mà Cassandra thường hay được sử dụng.

Messaging

Cassandra rất thích hợp trong những ứng dụng hay service làm về chat. Hiện nay có 1 số công ty đang dùng như Facebook, Discord.

Internet of things

Cassandra cũng rất thích hợp cho những dòng ứng dụng mà có tốc độ dữ liệu gửi đến cực khủng từ nhiều thiết bị khác.

Social Media Analytics and recommendation engine

Cassandra cũng rất thích hợp cho những chức năng về recommendation hay 1 vài chức năng liên quan đến analytics.

Điểm mạnh của Cassandra

Hệ thống phân tán

Do Cassandra được kế thừa từ Amazon DynamoDB nên tính mở rộng của nó là khá lớn. Khi tốc độ xử lý của hệ thống không đủ thì ta chỉ cần thêm node mới vào là được.

Partitioning

Là kiến trúc phân phối dữ liệu trên nhiều node bên trong cluster.

Dựa theo thuật toán Consistent Hashing thì mỗi node sẽ được cấp phát 1 token, và dựa vào token này sẽ phân phối dữ liệu đến từng node.

Dữ liệu được tạo ra nhờ replication sẽ tự động phân chia đến từng node.

cassandra architecture

Gossip Protocol

Là giao thức truyền thông giữa các node trong cluster. Cơ bản là truyền thông P2P.

Cơ chế lưu dữ liệu

Cassandra thực hiện việc lưu dữ liệu thông qua 2 chỗ:

  • Không gian bộ nhớ (được gọi là memtable)
  • Không gian đĩa (được gọi là SSTable)

Khi write dữ liệu thì đầu tiên sẽ lưu trên memtable. Sau khi dữ liệu trên memtable full thì khi đó sẽ thực hiện ghi toàn bộ dữ liệu trên memtable xuống SSTable.

Khi read dữ liệu thì đầu tiên sẽ tìm trong memtable trước. Nếu không có thì lại tìm xuống SSTable để lấy.

→ Chính vì dữ liệu được lưu trên memory nên việc việc lấy dữ liệu trên Cassandra trở lên khá là nhanh.

Khi xoá dữ liệu thì thực tế dữ liệu không được xoá, mà nó được gán 1 cái cờ gọi là tombstone. Sau 1 khoảng thời gian nào đó sẽ có 1 con batch chạy đi scan và thực hiện xoá.

Tính nhất quán dữ liệu trong cluster

Khi nhận được request đọc ghi đến DB của Cassandra, khi đó cái node nhận được request này sẽ đảm nhiệm 1 chức vụ được gọi là coordinator, và tiến hành xử lí request đọc ghi đến những node liên quan.

Dựa vào cấp độ của tính nhất quán (Consistency Level) mà việc kết nối đến từng node sẽ khác nhau.

Cấp độ của tính nhất quán sẽ được set trên mỗi câu truy vấn đọc ghi. Do đó giúp nhà phát triển ứng dụng sẽ dễ dàng điều chỉnh Consistency Level cho phù hợp với yêu cầu của họ: muốn kết quả trả về nhanh hay muốn dữ liệu trả về chính xác.

  • Nếu Consistency Level được set là 1 thì khi đó coordinator chỉ cần kết nối trực tiếp đến 1 node -> kết quả trả về nhanh
  • Nếu Consistency Level đươc set là ALL thì khi đó coordinator phải kết nối đến toàn bộ node và thực hiện xử lý dữ liệu. -> dữ liệu trả về chính xác

Tính dư thừa

Các node trong cluster có vai trò như nhau, không có node nào làm node chính cả. Hơn nữa dữ liệu không chỉ được lưu trên 1 node mà nó được lưu trên toàn bộ các node, do đó độ chịu lỗi của nó là khá cao.

Cho dù có 1 node bị lỗi đi chăng nữa thì khi truy vấn kết quả, nó sẽ được điều hướng sang các node khác để lấy.

Trong trường hợp mà chúng ta phục hồi dữ liệu từ 1 node bị lỗi thì nó sẽ xử lý như thế nào?

Giả sử như trong khi đang phục hồi thì có dữ liệu mới đến, khi đó dựa vào cơ chế Hinted Handoff thì cái node nhận được dữ liệu mới này sẽ thực hiện việc lưu tạm thời dữ liệu lại. Và cái node bị lỗi sau khi phục hồi dữ liệu xong thì sẽ tiến hành update dữ liệu dựa vào cái thông tin đã lưu lúc trước.

Ngoài ra dựa vào cơ chế Read Repair, khi chúng ta query dữ liệu. Chẳng may cái dữ liệu nhận được nó cũ hơn dữ liệu đang có ở các node khác. Khi đó nó sẽ tự động tiến hành update dữ liệu.

Cấu trúc dữ liệu

Dữ liệu được lưu trữ trong DB của Cassandra thuộc dạng Key value store (KVS).

Có thể tạo được nhiều table trong database nhưng mà giữa các table sẽ không có mỗi quan hệ nào. Nhiều table được tổng hợp lại thành keyspace.

Thông thường database trong NoSQL thì không cần thiết phải tạo schema ngay lúc đầu. Thế nhưng Cassandra thì lại khác. Trước khi insert dữ liệu thì cần phải tạo keyspace và schema của table.

Có thể thực hiện được 1 số câu query như select, update, insert, delete, drop.

Tổng kết

Mình tổng hợp lại 1 số đặc tính của Cassandra như sau:

  • Là NoSQL
  • Dữ liệu được phân tán trên nhiều node khác nhau.
  • Node càng nhiều thì throughput của nó càng tăng.
  • Write throughput luôn luôn cao hơn read throughput.
  • Tính chịu lỗi khá cao, cho dù node bị chết đi chăng nữa thì khi truy vấn sẽ được chuyển hướng đến node khác.
  • Backup, restore dữ liệu 1 cách đơn giản.
  • Tốc độ truy vấn cao

Đọc đến đây chắc hẳn các bạn cũng biết Cassandra nó làm việc thế nào rồi phải không.

Bài sau mình sẽ đi đào sâu vào 1 số hệ thống lớn xem họ đang áp dụng nó thế nào.

==============

Để nhận thông báo khi có bài viết mới nhất thì các bạn có thể like fanpage của mình ở bên dưới nhé:

→→→ Nghệ thuật Coding Fanpage Facebook

Chúc các bạn 1 tuần thật vui vẻ.

Nguồn