Posted inDatabase

Vượt qua giới hạn mở rộng: Tại sao tôi chuyển sang ScyllaDB cho dữ liệu tốc độ cao

Database tutorial - IT technology blog
Database tutorial - IT technology blog

Giới hạn khả năng mở rộng và cơn ác mộng độ trễ P99

Tôi đã dành nhiều năm chuyển đổi giữa MySQL cho dữ liệu có cấu trúc và MongoDB để lưu trữ tài liệu linh hoạt. Cả hai đều tuyệt vời cho đến khi bạn chạm phải một giới hạn nhất định. Khi xây dựng hệ thống đấu thầu thời gian thực xử lý 2,5 triệu yêu cầu mỗi giây, nhóm của tôi đã gặp phải một cơn ác mộng: các đợt tăng vọt độ trễ không thể dự đoán. Chúng tôi cần thời gian phản hồi dưới một mili giây, nhưng hệ thống NoSQL truyền thống liên tục gặp tình trạng giật lag.

Nếu bạn từng làm việc với các hệ thống phân tán, bạn sẽ biết Apache Cassandra là “người khổng lồ” trong ngành về khả năng mở rộng quy mô theo chiều ngang. Vấn đề là gì? Nó chạy trên Java Virtual Machine (JVM). Khi lưu lượng truy cập tăng vọt, cơ chế Garbage Collection (GC) của JVM sẽ kích hoạt các lần tạm dừng “stop-the-world”.

Những lần tạm dừng này tạo ra độ trễ P99 cao. Trong khi 99% người dùng thấy trang web nhanh, thì 1% không may mắn có thể phải đợi 200 mili giây hoặc hơn cho một truy vấn đơn giản. Trong giao dịch tần suất cao hoặc đấu thầu thời gian thực, độ trễ 1% đó đồng nghĩa với việc mất doanh thu. Đó là lý do tại sao tôi tìm đến ScyllaDB.

Cách ScyllaDB loại bỏ gánh nặng của Cassandra

ScyllaDB là một giải pháp thay thế trực tiếp cho Cassandra, nhưng nó thay thế nhân Java bằng kiến trúc C++ đột phá. Đây không chỉ là việc thay đổi ngôn ngữ; đó là một sự thay đổi cơ bản trong cách cơ sở dữ liệu giao tiếp với phần cứng của bạn.

Lợi thế của kiến trúc Shard-Per-Core

Các cơ sở dữ liệu tiêu chuẩn coi các lõi (core) CPU của bạn giống như một căn bếp đông đúc, nơi mọi đầu bếp đều tranh giành cùng một con dao. Điều này được gọi là tranh chấp khóa CPU (CPU lock contention). ScyllaDB sử dụng cách tiếp cận “shared-nothing” thông qua framework Seastar. Nó gán một phân đoạn dữ liệu (shard) cụ thể cho mỗi lõi CPU. Mỗi lõi quản lý bộ nhớ và ngăn xếp mạng riêng một cách độc lập. Không còn các khóa (lock) tốn kém. Nếu bạn tăng gấp đôi số lõi, bạn gần như tăng gấp đôi thông lượng (throughput) theo đường thẳng.

Loại bỏ Garbage Collector

Bằng cách viết bằng C++, ScyllaDB tự quản lý bộ nhớ thủ công. Không có tiến trình chạy ngầm nào đột ngột quét RAM và tạm dừng các luồng ứng dụng của bạn. Điều này chuyển hóa thành độ trễ ở mức micro giây ổn định ngay cả khi chịu tải cực lớn. Vì nó hỗ trợ Cassandra Query Language (CQL), bạn có thể giữ nguyên các driver và logic hiện tại trong khi xóa bỏ các tập lệnh tinh chỉnh JVM.

Khởi tạo một node trong 60 giây

Tôi luôn sử dụng Docker để thử nghiệm cục bộ nhằm giữ cho môi trường sạch sẽ. Bạn có thể có một hệ thống sẵn sàng cho môi trường production trước khi bạn pha xong một tách cà phê.

# Tải image chính thức
docker pull scylladb/scylla

# Khởi chạy container
docker run --name my-scylla -d scylladb/scylla

Khi nó đã chạy, hãy kiểm tra sức khỏe của node bằng `nodetool`. Tiện ích này là máy đo nhịp tim cho cụm (cluster) của bạn.

docker exec -it my-scylla nodetool status

Tìm trạng thái `UN` (Up/Normal). Nếu bạn thấy `UJ` (Up/Joining), node vẫn đang cân bằng dữ liệu. Hãy đợi khoảng 15 giây để nó ổn định.

Làm chủ mô hình hóa hướng truy vấn

Tương tác với ScyllaDB mang lại cảm giác giống như sử dụng shell SQL tiêu chuẩn, nhưng mô hình tư duy thì khác. Bạn không thiết kế cho các mối quan hệ dữ liệu; bạn thiết kế cho các truy vấn của mình.

# Mở CQL shell
docker exec -it my-scylla cqlsh

Đầu tiên, hãy tạo một **Keyspace**. Đây là vùng chứa dữ liệu nơi bạn xác định replication factor — số lượng bản sao vật lý của dữ liệu tồn tại trong cụm.

CREATE KEYSPACE itfromzero 
WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};

Tiếp theo, hãy xây dựng một bảng để theo dõi hoạt động của người dùng. Trong ScyllaDB, Primary Key là quyết định quan trọng nhất mà bạn sẽ thực hiện.

USE itfromzero;

CREATE TABLE user_logs (
    user_id UUID,
    activity_time timestamp,
    action text,
    metadata text,
    PRIMARY KEY (user_id, activity_time)
) WITH CLUSTERING ORDER BY (activity_time DESC);

Trong schema này, `user_id` là **Partition Key**. Nó quyết định node vật lý nào sẽ lưu trữ dữ liệu. `activity_time` là **Clustering Key**, giúp sắp xếp dữ liệu trên đĩa một cách vật lý. Điều này cho phép bạn lấy 50 hành động cuối cùng của người dùng bằng một lần đọc tuần tự cực nhanh.

Chèn một bản ghi log mẫu:

INSERT INTO user_logs (user_id, activity_time, action, metadata) 
VALUES (uuid(), toTimestamp(now()), 'login', '{"ip": "10.0.0.5"}');

Tránh những “sát thủ” hiệu năng trong Production

Đến từ MySQL, nhiều nhà phát triển cố gắng sử dụng `ALLOW FILTERING` để tìm dữ liệu. Đừng làm vậy. Trong cơ sở dữ liệu quan hệ, việc tìm kiếm không đánh index là chậm. Trong ScyllaDB, nó có thể buộc cơ sở dữ liệu phải quét mọi node trong một cụm 100 node cùng lúc. Nó sẽ giết chết hiệu năng của bạn ngay lập tức.

If bạn cần truy vấn theo một cột không phải khóa chính, bạn có các lựa chọn tốt hơn:

  • Materialized Views: ScyllaDB tạo một bảng phụ và tự động xử lý logic đồng bộ hóa cho bạn.
  • Local Secondary Indexes: Tuyệt vời để lọc dữ liệu trong một phân đoạn (partition) duy nhất.

Nguyên tắc vàng của tôi: Nếu bạn có một kiểu truy vấn mới, hãy tạo một bảng mới. Lưu trữ thì rẻ, nhưng mất 20ms độ trễ thì rất đắt.

Kết nối với Python

Vì ScyllaDB tương thích về giao thức với Cassandra, driver `cassandra-driver` tiêu chuẩn hoạt động hoàn hảo. Nó tự động xử lý cân bằng tải và connection pooling.

from cassandra.cluster import Cluster

# Kết nối tới node cục bộ
cluster = Cluster(['127.0.0.1'])
session = cluster.connect('itfromzero')

# Lấy dữ liệu rất đơn giản
query = "SELECT user_id, action FROM user_logs LIMIT 5"
rows = session.execute(query)

for row in rows:
    print(f"Người dùng {row.user_id} đã thực hiện: {row.action}")

cluster.shutdown()

Kết luận

Chuyển sang ScyllaDB đòi hỏi một sự thay đổi trong tư duy. Bạn mất đi sự tiện lợi của các phép JOIN phức tạp, nhưng bù lại bạn có một hệ thống có thể xử lý 10TB dữ liệu với độ trễ P99 chỉ 5ms. Tôi nhận thấy rằng một khi đã nắm bắt được kiến trúc shard-per-core, những cơn đau đầu về khả năng mở rộng sẽ biến mất.

Nếu bạn đang xây dựng một nền tảng IoT, một công cụ phân tích thời gian thực hoặc một ứng dụng nhắn tin với hàng triệu người dùng, ScyllaDB chính là động cơ bạn cần. Nó cung cấp khả năng mở rộng quy mô khổng lồ của Cassandra mà không đi kèm cơn ác mộng tinh chỉnh JVM. Hãy bắt đầu với một node Docker duy nhất ngay hôm nay, và bạn sẽ sẵn sàng khi lưu lượng truy cập tăng vọt.

Share:
Tags: