SingleStore 1 — Tổng quan & định vị HTAP

Hình dung một ngân hàng có hai hệ thống dữ liệu song song. Một bên là core banking chạy trên database OLTP (PostgreSQL/Oracle): ghi từng giao dịch, cập nhật số dư, ACID nghiêm ngặt. Bên kia là data warehouse (BigQuery/ClickHouse): nhận bản sao dữ liệu qua đường ETL đêm, phục vụ báo cáo và dashboard. Kiến trúc này chạy được, nhưng nó có hai vết thương kinh niên: độ trễ (dashboard nhìn thấy dữ liệu của hôm qua vì ETL chạy ban đêm) và độ phức tạp (phải nuôi hai hệ thống, một đường ống ETL, và luôn lo dữ liệu hai bên lệch nhau). SingleStore sinh ra để hỏi một câu khiêu khích: nếu một database duy nhất vừa chịu được tải giao dịch vừa trả lời truy vấn phân tích tức thời thì sao? Đó chính là lời hứa của HTAP.

Bài này là nền móng của cả series. Mục tiêu không phải dạy bạn viết truy vấn nhanh ngay, mà dựng một mô hình tinh thần đúng: SingleStore là loại database nào, nó giải bài toán gì, và quan trọng không kém — nó không giải bài toán gì. Có mô hình đó rồi, các bài sau về kiến trúc, lưu trữ, sharding, thực thi truy vấn... sẽ ăn khớp thay vì rời rạc.

Lưu ý về sandbox: SQL sandbox của Knowledge Base chạy trên PostgreSQL, KHÔNG phải SingleStore. SingleStore tương thích giao thức MySQL và có cú pháp riêng (SHARD KEY, SORT KEY, USING CLUSTERED COLUMNSTORE, CREATE PIPELINE...), nên nhiều khối code trong series này không chạy được ở đây — chúng mang tính minh hoạ và được ghi rõ "(minh hoạ — SingleStore)".

SingleStore là gì

SingleStore là một hệ quản trị cơ sở dữ liệu quan hệ, phân tán, HTAP, tương thích giao thức MySQL. Bóc từng tính từ ra sẽ hiểu bản chất:

• Quan hệ (relational): bảng, dòng, cột, khoá, JOIN, SQL đầy đủ — không phải NoSQL. Bạn tư duy schema như với PostgreSQL/MySQL.
• Phân tán (distributed): dữ liệu chia (shard) và trải trên nhiều node theo kiến trúc shared-nothing. Thêm node là thêm dung lượng và sức tính toán, mở rộng theo chiều ngang (scale-out) chứ không chỉ mua máy to hơn.
• HTAP (Hybrid Transactional/Analytical Processing): đây là linh hồn. Một hệ thống duy nhất phục vụ cả transaction (OLTP: ghi/sửa từng dòng, độ trễ mili-giây) lẫn analytics (OLAP: quét và tổng hợp hàng tỷ dòng).
• Tương thích giao thức MySQL: bạn kết nối bằng client/driver MySQL sẵn có, phần lớn cú pháp là MySQL. Nhưng bên dưới là một engine hoàn toàn khác (biên dịch truy vấn ra mã máy, lưu trữ columnstore, MPP) — nó không dùng lại engine InnoDB của MySQL. Hãy coi "tương thích MySQL" là ở tầng giao tiếp và cú pháp, không phải ở tầng thực thi.

Một chi tiết lịch sử quan trọng: SingleStore tiền thân là MemSQL, ra mắt khoảng 2013 như một database in-memory tốc độ cao. Công ty đổi tên sản phẩm và công ty thành SingleStore năm 2020, phản ánh việc nó đã vượt xa gốc "mem" (in-memory) để trở thành nền tảng lưu trữ kép row + column. Khi đọc tài liệu cũ, "MemSQL" và "SingleStore" là cùng một sản phẩm.

Vấn đề HTAP giải quyết: xoá bỏ khoảng cách OLTP–OLAP

Để hiểu SingleStore, phải hiểu thế giới database "cổ điển" bị chia đôi thế nào.

Hầu hết database kinh điển tối ưu cho một trong hai loại workload:

• OLTP (Online Transaction Processing): rất nhiều truy vấn nhỏ, mỗi cái chạm ít dòng (đọc/ghi một tài khoản), cần ACID, đọc theo khoá chính. PostgreSQL, MySQL, Oracle giỏi việc này, thường lưu theo dòng (row-store).
• OLAP (Online Analytical Processing): ít truy vấn hơn nhưng mỗi cái quét hàng triệu tới tỷ dòng rồi tổng hợp, ghi chủ yếu dạng append. ClickHouse, BigQuery, Snowflake giỏi việc này, lưu theo cột (column-store).

Vì không database nào giỏi cả hai, kiến trúc dữ liệu phổ biến là tách đôi và nối bằng ETL/CDC:

Kiến trúc tách đôi này trả giá bằng ba thứ:

1. Độ trễ dữ liệu (data freshness): ETL chạy theo lô (thường ban đêm) nghĩa là warehouse luôn nhìn thấy dữ liệu cũ. Không thể ra quyết định "ngay bây giờ" trên dữ liệu của hôm qua — ví dụ chặn gian lận theo thời gian thực.
2. Độ phức tạp vận hành: hai database, một đường ống ETL/CDC, hai bộ kỹ năng, hai điểm hỏng. Dữ liệu hai bên có thể lệch (drift) và việc đối soát tốn công.
3. Chi phí trùng lặp: cùng một khối dữ liệu lưu (và trả tiền lưu) ở hai nơi.

HTAP giải quyết bằng cách gộp hai workload vào một hệ thống duy nhất, trên cùng một bản dữ liệu. SingleStore làm được điều này nhờ lưu trữ kép: dữ liệu OLTP "nóng" có thể nằm ở rowstore in-memory (điểm truy cập độ trễ thấp), còn dữ liệu lớn phục vụ phân tích nằm ở columnstore trên đĩa (nén cao, quét nhanh). Bản columnstore hiện đại — gọi là Universal Storage — còn được tăng cường để cho phép point lookup và update kiểu OLTP ngay trên columnstore, làm nhoè ranh giới giữa hai thế giới. (Chi tiết ở các bài sau về Universal Storage.)

Kết quả: bạn ghi giao dịch và chạy dashboard phân tích trên cùng một bảng, cùng một thời điểm, không cần đường ETL ở giữa. Đó là toàn bộ giá trị cốt lõi.

Định vị: SingleStore đứng ở đâu

Cách hiểu hay nhất là đặt HTAP vào giữa quang phổ OLTP ↔ OLAP:

Đối chiếu trực diện với bốn hệ thống hay bị đem so:

Vài điểm định vị cần khắc:

• So với PostgreSQL/MySQL (OLTP thuần): SingleStore mạnh hơn hẳn ở phân tích quét lớn và scale-out ngang nhờ MPP + columnstore, nhưng Postgres vẫn vượt trội về hệ sinh thái, extension, ràng buộc quan hệ phong phú, và chi phí vận hành đơn giản cho ứng dụng vừa và nhỏ. Đừng thay Postgres bằng SingleStore chỉ vì "nghe nhanh hơn".
• So với ClickHouse/BigQuery (OLAP thuần): với truy vấn phân tích thuần tuý, batch, quét petabyte, một OLAP chuyên dụng thường vẫn nhanh/rẻ hơn và ít phải vận hành hơn (đặc biệt BigQuery serverless). SingleStore thắng khi bạn cần transaction ghi đồng thời với phân tích trên cùng dữ liệu tươi — thứ mà OLAP thuần không làm được. Xem tổng quan ClickHouse và tổng quan BigQuery để so sánh phía OLAP.
• So với TiDB / CockroachDB (distributed SQL): đây là họ hàng gần nhất. Cả ba đều là SQL phân tán, scale-out, có ACID. Khác biệt: CockroachDB đặt trọng tâm vào tính nhất quán mạnh + phân tán địa lý (geo-distributed) cho OLTP, dùng giao thức PostgreSQL; TiDB cũng theo hướng HTAP (kết hợp TiKV row-store + TiFlash column-store), tương thích MySQL; còn SingleStore nhấn vào hiệu năng analytics thô nhờ biên dịch truy vấn ra mã máy và Universal Storage. Nói ngắn: CockroachDB nghiêng OLTP-phân-tán, SingleStore và TiDB nghiêng HTAP, nhưng cách hiện thực khác nhau.

Khi nào NÊN và KHÔNG NÊN dùng SingleStore

NÊN dùng khi:

• Bạn cần phân tích trên dữ liệu tươi thời gian thực — dashboard, phát hiện gian lận, cá nhân hoá — mà không chấp nhận độ trễ ETL.
• Ứng dụng vừa có tải ghi giao dịch vừa có truy vấn phân tích nặng trên cùng dữ liệu, và bạn muốn bỏ bớt một hệ thống + đường ETL để giảm phức tạp.
• Cần mở rộng ngang khi dữ liệu/tải vượt sức một node đơn, nhưng vẫn muốn giữ SQL quan hệ và ACID.
• Team đã quen hệ sinh thái MySQL (driver, công cụ) và muốn tận dụng lại.

KHÔNG NÊN dùng khi:

• Workload thuần OLTP nhỏ gọn, một node Postgres/MySQL là dư sức → thêm SingleStore chỉ tăng chi phí và độ phức tạp vô ích.
• Workload thuần OLAP batch, quét petabyte, không cần ghi giao dịch → một OLAP chuyên dụng (ClickHouse/BigQuery) thường rẻ và tối ưu hơn.
• Bạn phụ thuộc nặng vào tính năng đặc thù của PostgreSQL (kiểu dữ liệu phong phú, extension như PostGIS, kiểm tra ràng buộc phức tạp) — SingleStore tương thích MySQL, không phải Postgres.
• Team quá nhỏ, không đủ nguồn lực vận hành một cụm phân tán (dù SingleStore Helios managed cloud giảm nhẹ gánh này).

Quy tắc ghi nhớ: nếu bài toán của bạn là "cần phân tích tức thời trên chính dữ liệu vừa ghi vào" → HTAP/SingleStore. Nếu chỉ nghiêng hẳn về một phía → dùng công cụ chuyên dụng của phía đó.

Một thoáng cú pháp

Vì tương thích MySQL, DDL của SingleStore trông rất quen, chỉ thêm vài từ khoá phân tán. Ví dụ một bảng giao dịch dạng columnstore (không chạy trong sandbox Postgres):

-- (minh hoạ — SingleStore)
CREATE TABLE transactions (
    txn_id      BIGINT       NOT NULL,
    account_id  BIGINT       NOT NULL,
    amount      DECIMAL(18,2) NOT NULL,
    channel     VARCHAR(20),
    status      VARCHAR(16),
    created_at  DATETIME(6)  NOT NULL,
    SHARD KEY (account_id),                 -- quyết định partition nào giữ dòng
    SORT KEY (created_at),                  -- thứ tự sắp trong columnstore
    KEY (account_id) USING CLUSTERED COLUMNSTORE
);

SHARD KEY băm account_id để trải dữ liệu đều lên các node, SORT KEY sắp theo thời gian để quét khoảng ngày cực nhanh, và CLUSTERED COLUMNSTORE chọn lưu trữ cột. Ba khái niệm này lần lượt được đào sâu ở sharding & phân tán và Universal Storage.

Bản đồ toàn series

Đây là bài mở màn của loạt 10 bài đi từ mô hình tinh thần đến vận hành thực chiến:

Danh sách và liên kết:

1. Tổng quan & định vị HTAP — bài này.
2. Kiến trúc cluster — aggregator, leaf, partition, HA.
3. Universal Storage — rowstore in-memory vs columnstore, hợp nhất row + column.
4. Sharding & phân tán — SHARD KEY, reference table, distributed join.
5. Thực thi truy vấn — biên dịch ra mã máy, MPP, plan cache.
6. Indexing & tối ưu — hash index, sort key, EXPLAIN/PROFILE.
7. Pipelines & ingest — nạp streaming từ Kafka/S3, exactly-once.
8. Transaction, HA & DR — ACID, MVCC, sao lưu/phục hồi.
9. Vector & hybrid search — kiểu VECTOR, ANN, kết hợp full-text cho AI/RAG.
10. Vận hành trong ngân hàng — resource pool, workload management, use case thực chiến.

Use case thực tế

Bối cảnh: NCB muốn một hệ thống phát hiện gian lận thẻ theo thời gian thực. Khi một giao dịch phát sinh, hệ thống cần vừa ghi giao dịch vào sổ, vừa tính ngay vài chỉ số phân tích trên lịch sử của tài khoản đó: "trong 10 phút qua tài khoản này giao dịch mấy lần?", "tổng số tiền so với trung bình 30 ngày?", "có giao dịch ở địa điểm bất thường không?" — tất cả phải xong trong vài chục mili-giây để quyết định cho qua hay chặn.

Vấn đề với kiến trúc tách đôi: nếu giao dịch ghi vào PostgreSQL rồi mới ETL sang warehouse để phân tích, thì lúc cần ra quyết định, dữ liệu phân tích đã cũ hàng giờ — vô dụng cho việc chặn gian lận ngay lúc quẹt thẻ. Xây thêm một lớp cache/stream riêng thì lại phình độ phức tạp.

Giải pháp với SingleStore (HTAP):

1. Giao dịch ghi thẳng vào bảng transactions trên SingleStore (rowstore/Universal Storage, ACID).
2. Cùng lúc, câu truy vấn phân tích cửa sổ trượt (sliding window) chạy ngay trên chính bảng đó, tận dụng columnstore + MPP để aggregate lịch sử tài khoản trong mili-giây.
3. Không có đường ETL ở giữa → không có độ trễ dữ liệu → quyết định dựa trên trạng thái tức thời.

Kết quả (minh hoạ điển hình của loại triển khai này): truy vấn tính điểm rủi ro (risk score) hoàn tất trong khoảng 10–50 mili-giây ngay cả khi bảng tích luỹ hàng trăm triệu dòng, hệ thống loại bỏ được một database và một đường ETL so với kiến trúc cũ. Các con số là minh hoạ theo bậc độ lớn, không phải số đo chính thức của một hệ thống NCB cụ thể. Bài vận hành trong ngân hàng sẽ dựng chi tiết loại use case này.

Ghi nhớ

• SingleStore tiền thân là MemSQL (đổi tên 2020), là database quan hệ phân tán HTAP, tương thích giao thức MySQL (nhưng engine hoàn toàn riêng, không phải InnoDB).
• HTAP = gộp OLTP + OLAP vào một hệ thống trên cùng dữ liệu, xoá bỏ đường ETL sang warehouse riêng → dữ liệu tươi, ít hệ thống, ít lệch dữ liệu.
• Nền tảng kỹ thuật: lưu trữ kép (rowstore in-memory + columnstore trên đĩa), Universal Storage cho point lookup/update ngay trên columnstore, kiến trúc shared-nothing scale-out.
• Định vị: nằm giữa OLTP thuần (Postgres/MySQL) và OLAP thuần (ClickHouse/BigQuery); họ hàng gần là TiDB, CockroachDB (distributed SQL).
• NÊN dùng khi cần phân tích tức thời trên dữ liệu vừa ghi hoặc gộp workload transaction + analytics; KHÔNG NÊN khi thuần OLTP nhỏ, thuần OLAP batch, hoặc phụ thuộc tính năng đặc thù Postgres.
• Cú pháp quen thuộc kiểu MySQL, thêm từ khoá phân tán: SHARD KEY, SORT KEY, USING CLUSTERED COLUMNSTORE.
• Trong ngân hàng, điểm ngọt của SingleStore là các bài toán real-time + cần cả ghi lẫn phân tích: phát hiện gian lận, giám sát giao dịch, cá nhân hoá tức thời.

Nguồn tham khảo

• SingleStore Documentation — tài liệu chính thức của SingleStore.
• SingleStore Documentation — mục "Cluster Architecture" (kiến trúc shared-nothing, aggregator/leaf).
• SingleStore Documentation — mục "How SingleStore Stores Data" / "Universal Storage" (rowstore, columnstore, lưu trữ kép).
• SingleStore Documentation — mục "Distributed SQL / SHARD KEY" (sharding, reference table, distributed join).
• SingleStore Documentation — mục "Query Compilation" (biên dịch truy vấn ra mã máy).
• MySQL Documentation — tham chiếu phần tương thích giao thức/cú pháp MySQL.
• ClickHouse và BigQuery — bài đối chiếu phía OLAP trong Knowledge Base.