SingleStore 10 — Vận hành & use case ngân hàng HTAP

Chín bài trước đã dựng đủ nền: tổng quan HTAP, kiến trúc aggregator/leaf, Universal Storage, sharding & phân tán, thực thi biên dịch truy vấn, index & tối ưu, Pipelines nạp dữ liệu, giao dịch, HA & DR và vector & hybrid search. Bài cuối này trả lời câu hỏi thực chiến: vận hành một cụm SingleStore trong sản xuất như thế nào, và HTAP đáng giá gì với một ngân hàng khi nó cho phép gộp hai hệ thống — OLTP và data warehouse — thành một.

Mô hình tinh thần cần giữ: một cụm SingleStore là tài nguyên dùng chung cho nhiều loại tải rất khác nhau — vài nghìn giao dịch ghi/giây (OLTP) chạy cạnh những truy vấn quét hàng trăm triệu dòng (OLAP). Cái làm cho HTAP không sụp đổ chính là quản trị tài nguyên: đảm bảo một báo cáo nặng không "bỏ đói" luồng authorization đang cần độ trễ mili-giây. Phần lớn công việc vận hành SingleStore xoay quanh đúng ranh giới đó.

Resource pools & workload management: tách OLTP khỏi OLAP

Đây là công cụ vận hành quan trọng nhất khi chạy HTAP thật. Resource pool là một nhóm hạn ngạch tài nguyên (bộ nhớ, CPU, số truy vấn đồng thời) mà bạn gán cho một nhóm kết nối hoặc người dùng. Bạn tạo pool riêng cho tải giao dịch và pool riêng cho tải phân tích, rồi ép mỗi loại chạy trong "làn đường" của nó.

Cấp phát bằng SQL (cú pháp tương thích MySQL):

-- Pool cho tải giao dịch: nhiều truy vấn ngắn, timeout thấp
CREATE RESOURCE POOL pool_oltp WITH
    MEMORY_PERCENTAGE = 30,
    QUERY_TIMEOUT = 5,
    MAX_CONCURRENCY = 512;

-- Pool cho tải phân tích: ít truy vấn nhưng nặng, giới hạn CPU để không lấn OLTP
CREATE RESOURCE POOL pool_olap WITH
    MEMORY_PERCENTAGE = 50,
    SOFT_CPU_LIMIT_PERCENTAGE = 60,
    MAX_CONCURRENCY = 16,
    QUERY_TIMEOUT = 300;

-- Gán pool mặc định cho từng user
GRANT SELECT ON bank.* TO 'analytics'@'%';
ALTER USER 'analytics'@'%' SET RESOURCE POOL = 'pool_olap';
ALTER USER 'txn_app'@'%'   SET RESOURCE POOL = 'pool_oltp';

-- Hoặc chuyển pool ngay trong phiên trước một truy vấn nặng
SET resource_pool = pool_olap;

Ý nghĩa các tham số chính: MEMORY_PERCENTAGE chặn trần bộ nhớ pool được dùng (tổng các pool có thể vượt 100% vì không phải lúc nào cũng dùng hết cùng lúc); MAX_CONCURRENCY giới hạn số truy vấn chạy song song, phần dư xếp hàng đợi; SOFT_CPU_LIMIT_PERCENTAGE ghì CPU của pool phân tích để nó không "nuốt" hết lõi; QUERY_TIMEOUT giết truy vấn chạy quá lâu. Bên cạnh resource pool, SingleStore còn có workload management tự động: engine ước lượng chi phí bộ nhớ/kết nối của mỗi truy vấn phân tán và xếp hàng truy vấn khi cụm sắp quá tải, thay vì để cả cụm sụp vì hết bộ nhớ. Hai cơ chế này bổ trợ nhau — pool định ranh giới, workload management điều tiết dòng chảy trong ranh giới đó.

Giới hạn bộ nhớ: maximum_memory

Vì rowstore nằm hoàn toàn trong RAM và các truy vấn phân tích cũng ngốn RAM (hash join, group by, sort), kiểm soát bộ nhớ là sống còn. Biến engine maximum_memory đặt trần bộ nhớ (MB) mà một node SingleStore được phép dùng; chạm trần, các thao tác cấp phát mới bị từ chối với lỗi hết bộ nhớ thay vì để OS OOM-kill cả tiến trình. Liên quan còn có maximum_table_memory (trần riêng cho dữ liệu bảng rowstore, để dữ liệu không chiếm sạch chỗ của truy vấn).

-- Xem cấu hình hiện tại
SHOW VARIABLES LIKE 'maximum_memory';
SHOW VARIABLES LIKE 'maximum_table_memory';

-- Đặt trần (áp cho toàn cụm)
SET GLOBAL maximum_memory = 120000;        -- MB

Quy tắc vận hành: chừa đủ RAM cho hệ điều hành và cho blob cache của columnstore; đặt maximum_memory thấp hơn tổng RAM vật lý. Khi rowstore đầy (chạm maximum_table_memory), lệnh INSERT/UPDATE bắt đầu lỗi — dấu hiệu cần thêm leaf hoặc chuyển bảng sang columnstore (xem Universal Storage).

Giám sát bằng management views: information_schema.MV_*

SingleStore phơi bày trạng thái thời gian thực của cụm qua họ management views tiền tố MV_ trong information_schema (MV = "management view", không phải materialized view). Đây là công cụ chẩn đoán chính, đặc biệt là các view tổng hợp trên toàn cụm:

Ví dụ tìm các truy vấn đang ngốn bộ nhớ nhất ngay lúc này:

SELECT activity_name, database_name, memory_bs, cpu_time_ms
FROM information_schema.MV_ACTIVITIES
ORDER BY memory_bs DESC
LIMIT 10;

Ghép MV_ACTIVITIES với MV_QUERIES cho phép phân biệt "truy vấn nào nặng theo bản chất" với "truy vấn nào đang chạy nhiều lần" — dữ liệu đầu vào để chỉnh resource pool hoặc thêm index. Trên Helios, cùng dữ liệu này còn hiện qua dashboard giám sát tích hợp.

Backup & restore

SingleStore backup ở mức database, ghi ra thư mục cục bộ hoặc thẳng lên object store (S3, Azure Blob, GCS). Có full backup và differential backup (chỉ phần thay đổi từ full gần nhất) để giảm khối lượng và thời gian.

-- Full backup lên S3
BACKUP DATABASE bank TO S3 'my-bucket/backups/bank'
    CONFIG '{"region":"ap-southeast-1"}'
    CREDENTIALS '{"aws_access_key_id":"...","aws_secret_access_key":"..."}';

-- Differential backup (chỉ delta kể từ full gần nhất)
BACKUP DATABASE bank WITH DIFFERENTIAL TO S3 'my-bucket/backups/bank';

-- Khôi phục thành database mới
RESTORE DATABASE bank_restored FROM S3 'my-bucket/backups/bank';

Backup là nhất quán về mặt giao dịch tại thời điểm chạy. Đây là lớp phục hồi bổ sung cho HA/DR đã bàn ở bài 8: replica trong cụm chống mất leaf tức thời, còn backup chống mất dữ liệu logic (xoá nhầm, hỏng ứng dụng) và phục vụ tạo môi trường staging. Với ngân hàng, lịch chạy điển hình là full hằng tuần + differential hằng ngày, đẩy lên object store ở vùng khác để chống thảm hoạ.

Helios (managed) hay self-managed?

SingleStore có hai hình thái triển khai, cùng một engine:

Với nhiều ngân hàng, yêu cầu dữ liệu nằm trong biên giới/on-prem và kiểm soát bảo mật khiến self-managed vẫn phổ biến; nhưng Helios hấp dẫn cho môi trường phân tích ít nhạy cảm hoặc khi muốn giảm gánh vận hành. Điều quan trọng: kiến trúc và cú pháp giống nhau, nên thiết kế bảng/shard key/pipeline chuyển giữa hai hình thái gần như không đổi.

Scale: thêm leaf & rebalance partitions

SingleStore scale ngang bằng cách thêm leaf node rồi cân bằng lại partitions để trải dữ liệu đều lên node mới — làm online, không cần dừng cụm.

-- Thêm một leaf mới vào cụm
ADD LEAF 'leaf-07.internal':3306;

-- Trải lại partitions của database lên toàn bộ leaf (gồm leaf vừa thêm)
REBALANCE PARTITIONS ON bank;

-- Kiểm tra phân bố partition trước/sau
SELECT * FROM information_schema.MV_NODES;

REBALANCE PARTITIONS di chuyển bản master/replica của partition sao cho tải phân bố đều và vẫn giữ redundancy (mỗi partition có bản dự phòng trên leaf khác). Vì sharding cố định số partition khi tạo database, scale là chuyện di chuyển partition sang node mới chứ không băm lại dữ liệu — nên chọn số partition đủ lớn ngay từ đầu là quyết định thiết kế quan trọng. Muốn scale tầng điều phối/kết nối thì thêm Child Aggregator (ADD AGGREGATOR) thay vì leaf.

Bức tranh HTAP ngân hàng: một hệ thay hai

Đây là lý do tồn tại của SingleStore trong ngân hàng. Kiến trúc truyền thống tách đôi: một CSDL OLTP (ví dụ Postgres/Oracle) ghi giao dịch, rồi ETL/CDC bê dữ liệu qua một data warehouse (ví dụ Snowflake) để phân tích. Hệ quả: dữ liệu phân tích trễ hàng giờ, phải bảo trì đường ống ETL, và không thể chấm điểm gian lận real-time trên dữ liệu vừa mới nhất. HTAP xoá ranh giới đó — ghi và phân tích trên cùng một bản dữ liệu sống.

Ba khả năng làm cho việc gộp này khả thi, đều đã bàn trong series:

• Universal Storage cho phép point lookup + update kiểu OLTP ngay trên columnstore — nên cùng một bảng vừa phục vụ ghi/tra cứu từng dòng vừa phục vụ quét phân tích, không cần hai bản sao dữ liệu.
• Pipelines nạp giao dịch từ Kafka exactly-once, song song vào các partition — thay cho đường ống ETL riêng.
• Vector & hybrid search chạy ngay trong CSDL, cho phép so khớp mẫu giao dịch bất thường bằng vector cạnh các luật SQL, không cần bê dữ liệu sang hệ AI riêng.

Use case thực tế

Bối cảnh (số liệu minh hoạ). Một ngân hàng xử lý ~3.000 giao dịch thẻ/giây giờ cao điểm (~200 triệu giao dịch/ngày). Kiến trúc cũ: Oracle OLTP ghi giao dịch → CDC sang Snowflake mỗi 2 giờ để làm dashboard rủi ro. Hệ quả: đội chống gian lận nhìn dữ liệu trễ 2 giờ, và mô hình chấm điểm gian lận phải gọi ra một hệ riêng vì OLTP không kham nổi truy vấn tổng hợp.

Chuyển sang SingleStore HTAP. Giao dịch chảy từ Kafka vào SingleStore qua Pipeline (exactly-once); bảng transactions để KEY USING CLUSTERED COLUMNSTORE + secondary hash index cho point lookup (Universal Storage). Trên cùng cụm:

1. Luồng authorization tra cứu lịch sử tài khoản 30 ngày bằng point lookup (rowstore reference table + hash index) — độ trễ mili-giây, chạy trong pool_oltp.
2. Truy vấn chấm điểm gian lận tổng hợp tần suất/địa điểm/số tiền theo cửa sổ trượt trên dữ liệu vừa ghi giây trước, kết hợp vector similarity với mẫu gian lận đã biết.
3. Dashboard rủi ro và báo cáo đọc cùng bảng đó qua pool_olap, SOFT_CPU_LIMIT_PERCENTAGE giữ cho báo cáo nặng không lấn luồng authorization.

Minh hoạ hình dạng truy vấn tổng hợp mà dashboard cần (câu dưới chạy được trên sandbox Postgres của app; trên SingleStore cú pháp gần như y hệt nhưng chạy phân tán trên leaf):

-- ▶ Chạy được
SELECT
    kind,
    COUNT(*)                       AS so_giao_dich,
    ROUND(AVG(amount)::numeric, 2) AS trung_binh,
    SUM(amount)                    AS tong_tien
FROM transactions
GROUP BY kind
ORDER BY tong_tien DESC;

Kết quả (minh hoạ theo cấu hình tham chiếu). Độ trễ dữ liệu cho đội gian lận tụt từ 2 giờ xuống dưới 1 giây; bỏ được đường ống CDC → Snowflake cho tải này (giảm một hệ thống phải vận hành); chấm điểm gian lận chạy trực tiếp trên dữ liệu giao dịch tươi thay vì bản sao trễ; resource pool đảm bảo báo cáo cuối ngày không làm chậm authorization. Đánh đổi: cần chọn số partition và maximum_memory cẩn thận, và giám sát MV_ACTIVITIES để bắt sớm truy vấn phân tích lệch làn.

Ghi nhớ

• Resource pools + workload management là công cụ vận hành cốt lõi của HTAP: tách pool_oltp (nhiều truy vấn ngắn, timeout thấp) khỏi pool_olap (ít truy vấn nặng, giới hạn CPU) để báo cáo không bỏ đói giao dịch.
• maximum_memory (và maximum_table_memory) đặt trần RAM per-node; chạm trần thì lỗi có kiểm soát thay vì OS OOM-kill — chừa RAM cho OS và blob cache.
• Giám sát bằng họ information_schema.MV_*: MV_NODES, MV_PROCESSLIST, MV_ACTIVITIES, MV_QUERIES, MV_TASKS, MV_BACKUP_HISTORY (MV = management view, không phải materialized view).
• Backup ở mức database, có full + differential, đẩy lên S3/Azure/GCS; là lớp phục hồi logic bổ sung cho HA/DR nội cụm.
• Helios (managed) và self-managed dùng chung engine/cú pháp; ngân hàng thường chọn self-managed vì ràng buộc dữ liệu tại chỗ, nhưng thiết kế chuyển qua lại gần như không đổi.
• Scale ngang bằng ADD LEAF + REBALANCE PARTITIONS (online); số partition cố định khi tạo DB nên chọn đủ lớn từ đầu. Scale kết nối bằng ADD AGGREGATOR.
• Giá trị HTAP: một cụm thay cặp OLTP + data warehouse, xoá độ trễ ETL, cho phép fraud real-time + dashboard trên cùng dữ liệu giao dịch sống — nhờ Universal Storage, Pipelines và vector search hội tụ trong một engine.

Nguồn tham khảo

• SingleStore Documentation — Resource Governance / Workload Management — resource pool, MEMORY_PERCENTAGE, MAX_CONCURRENCY, SOFT_CPU_LIMIT_PERCENTAGE, hàng đợi truy vấn.
• SingleStore Documentation — Memory Management — biến maximum_memory, maximum_table_memory và hành vi khi chạm trần.
• SingleStore Documentation — Management Views (information_schema) — họ view MV_* để giám sát cụm.
• SingleStore Documentation — Backup and Restore — BACKUP DATABASE, full vs differential, backup lên object store, RESTORE DATABASE.
• SingleStore Documentation — Cluster Management (Scaling) — ADD LEAF, REBALANCE PARTITIONS, ADD AGGREGATOR.
• SingleStore Helios — Managed Service — dịch vụ managed cloud so với triển khai self-managed.
• Tài liệu MySQL (dev.mysql.com) — tham chiếu cú pháp SHOW VARIABLES, GRANT, ALTER USER cho phần tương thích giao thức MySQL.