Bối cảnh & Tại sao hệ thống của bạn cần OLAP
Dashboard doanh thu quay mòng mòng 30 giây mỗi lần sếp đổi bộ lọc quý. Thậm chí có lúc báo lỗi 504 Gateway Timeout. Đây là kịch bản quen thuộc ở nhiều đội ngũ kỹ thuật khi dữ liệu bắt đầu phình to.
Phản xạ đầu tiên thường thấy là đánh thêm index cho MySQL hoặc nâng RAM máy chủ PostgreSQL từ 16GB lên 64GB. Giải pháp này chỉ cầm cự được vài tuần. Khi lượng dữ liệu vượt mốc 20-50 triệu dòng, tình trạng nghẽn cổ chai lại tái diễn.
Bản chất vấn đề nằm ở kiến trúc lưu trữ:
- CSDL giao dịch (OLTP – MySQL, PostgreSQL): Lưu dữ liệu theo từng dòng (Row-oriented). Cơ chế này cực kỳ tối ưu khi bạn cần thêm mới một đơn hàng hoặc đọc thông tin một user cụ thể (chưa tới 2ms). Nhưng khi cần tính toán tổng hợp (SUM, COUNT, AVG) trên hàng chục triệu bản ghi, hệ thống buộc phải lật giở toàn bộ các trang dữ liệu từ ổ đĩa. Đĩa I/O chạm ngưỡng 100%, CPU quá tải lập tức.
- CSDL phân tích (OLAP – StarRocks): Lưu trữ theo từng cột riêng biệt (Columnar storage). Toàn bộ dữ liệu của cột
pricehayorder_dateđược nén chặt và gom thành các block liền kề. Cần tính tổng doanh thu? StarRocks chỉ đọc đúng cột giá tiền và bỏ qua các cột còn lại. Lượng dữ liệu cần đọc giảm từ 80% đến 95%.
StarRocks xử lý tác vụ này rất nhanh nhờ kiến trúc Vectorized Engine tận dụng lệnh SIMD của CPU. Thay vì mất 20 giây như trên MySQL, câu query phân tích phức tạp thường trả về kết quả dưới 150ms. Đặc biệt, StarRocks tương thích hoàn toàn giao thức MySQL. Bạn có thể cắm trực tiếp Metabase, Apache Superset hay Tableau vào cổng 9030 mà không cần viết lại query hay đổi thư viện kết nối.
Cài đặt cụm StarRocks với Docker
Hệ thống StarRocks phân tách rõ ràng thành hai thành phần:
- Frontend (FE): Tiếp nhận kết nối từ client, parse câu lệnh SQL, lập kế hoạch thực thi tối ưu và quản lý metadata cụm.
- Backend (BE): Trực tiếp lưu trữ các khối dữ liệu cột và gánh toàn bộ tải tính toán song song.
Để dựng môi trường thử nghiệm nhanh nhất trên máy cá nhân, Docker Compose là lựa chọn thuận tiện nhất. Khởi tạo thư mục làm việc:
mkdir starrocks-lab && cd starrocks-lab
touch docker-compose.ymlKhai báo cấu hình sau vào docker-compose.yml:
version: '3.8'
services:
starrocks-fe:
image: starrocks/fe-ubuntu:3.2-latest
container_name: starrocks-fe
hostname: starrocks-fe
environment:
- HOST_TYPE=IP
ports:
- "8030:8030" # Web UI
- "9020:9020" # FE edit log
- "9030:9030" # Cổng truy vấn MySQL Client
- "9242:9242" # Internal RPC
networks:
starrocks-net:
ipv4_address: 172.20.0.2
starrocks-be:
image: starrocks/be-ubuntu:3.2-latest
container_name: starrocks-be
hostname: starrocks-be
environment:
- HOST_TYPE=IP
ports:
- "8040:8040" # BE Web Server
- "9050:9050" # Heartbeat Service Port
- "9060:9060" # BE Service Port
networks:
starrocks-net:
ipv4_address: 172.20.0.3
depends_on:
- starrocks-fe
networks:
starrocks-net:
driver: bridge
ipam:
config:
- subnet: 172.20.0.0/16Chạy lệnh sau để khởi động cụm:
docker compose up -dChờ khoảng 30 đến 45 giây để hai container hoàn tất quá trình bootstrap. Lúc này, FE và BE hoạt động độc lập và chưa nhận diện nhau. Hãy dùng MySQL client kết nối vào cổng 9030 của FE:
# Tài khoản mặc định là root, mật khẩu để trống
mysql -h 127.0.0.1 -P 9030 -u rootNếu máy bạn chưa có sẵn MySQL client, có thể gọi trực tiếp binary bên trong container:
docker exec -it starrocks-fe mysql -P 9030 -u rootĐăng ký node BE vào cụm thông qua địa chỉ IP nội bộ cùng cổng heartbeat (9050):
-- Liên kết BE vào danh sách quản lý của FE
ALTER SYSTEM ADD BACKEND "172.20.0.3:9050";Thiết kế bảng và nạp dữ liệu mẫu
StarRocks hỗ trợ 4 mô hình bảng chính: Duplicate Key, Aggregate Key, Unique Key và Primary Key. Đối với dữ liệu chi tiết cần giữ nguyên từng dòng (như đơn hàng hay log truy cập), Duplicate Key mang lại hiệu năng ghi và quét tốt nhất.
Tạo database cùng bảng quản lý đơn hàng thương mại điện tử:
CREATE DATABASE IF NOT EXISTS retail_analytics;
USE retail_analytics;
CREATE TABLE IF NOT EXISTS orders (
order_id BIGINT NOT NULL,
order_date DATE NOT NULL,
customer_id INT NOT NULL,
category VARCHAR(50) NOT NULL,
price DECIMAL(10, 2) NOT NULL,
quantity INT NOT NULL,
region VARCHAR(30) NOT NULL
)
ENGINE=OLAP
DUPLICATE KEY(order_id, order_date)
PARTITION BY RANGE(order_date) (
START ("2024-01-01") END ("2024-12-31") EVERY (INTERVAL 1 MONTH)
)
DISTRIBUTED BY HASH(order_id) BUCKETS 4
PROPERTIES (
"replication_num" = "1"
);Ý nghĩa kỹ thuật của từng cấu hình quan trọng:
ENGINE=OLAP: Kích hoạt cơ chế lưu trữ cột chuyên dụng.PARTITION BY RANGE: Cắt nhỏ bảng theo từng tháng (Data Pruning). Khi truy vấn dữ liệu tháng 3, engine tự động bỏ qua 11 tháng còn lại, giảm đáng kể dữ liệu phải quét.DISTRIBUTED BY HASH ... BUCKETS 4: Chia nhỏ mỗi partition thành 4 tablet phân tán. Càng nhiều bucket phù hợp, hệ thống càng tận dụng tốt khả năng xử lý đa lõi của CPU.replication_num = 1: Do môi trường lab chỉ có 1 node BE nên đặt 1 bản sao. Khi triển khai Production với cụm tối thiểu 3 node, hãy đặt thông số này bằng 3 để đảm bảo khả năng chịu lỗi (High Availability).
Chèn một vài bản ghi thử nghiệm:
INSERT INTO orders VALUES
(1001, '2024-03-01', 501, 'Electronics', 1200.00, 1, 'Hanoi'),
(1002, '2024-03-02', 502, 'Home & Kitchen', 45.50, 3, 'HCM'),
(1003, '2024-03-02', 503, 'Electronics', 350.00, 2, 'Danang'),
(1004, '2024-03-05', 504, 'Fashion', 85.00, 4, 'Hanoi'),
(1005, '2024-03-10', 505, 'Electronics', 2100.00, 1, 'HCM');Thực thi câu truy vấn tổng hợp doanh thu thường dùng trên dashboard:
SELECT
category,
region,
COUNT(order_id) AS total_orders,
SUM(price * quantity) AS total_revenue,
ROUND(AVG(price), 2) AS average_item_price
FROM orders
WHERE order_date >= '2024-03-01'
GROUP BY category, region
ORDER BY total_revenue DESC;Vận hành & Giám sát
Hệ thống phân tán cần được kiểm tra kỹ lưỡng về tình trạng node trước khi tiếp nhận tải lớn.
1. Kiểm tra sức khỏe Cluster qua MySQL CLI
Kiểm tra danh sách và trạng thái các node FE và BE:
-- Kiểm tra danh sách node Frontend
SHOW PROC '/frontends';
-- Kiểm tra danh sách node Backend
SHOW PROC '/backends'\G;Hãy chú ý kỹ hai trường trong kết quả của BE: Alive phải hiển thị true và ErrCode phải bằng 0. Nếu Alive: false, hãy kiểm tra lại kết nối mạng Docker subnet hoặc log cổng 9050.
2. Theo dõi chỉ số qua Web UI
Giao diện Web UI tích hợp sẵn giúp bạn quan sát tài nguyên trực quan. Mở trình duyệt và truy cập:
http://localhost:8030Đăng nhập bằng user root (không cần mật khẩu). Tại đây, bạn có thể giám sát dung lượng đĩa cứng, mức tiêu thụ RAM của từng node và danh sách câu truy vấn đang thực thi theo thời gian thực.
3. Đọc Query Profile để bóc tách hiệu năng
Khi gặp một truy vấn chậm trên tập dữ liệu hàng chục GB, hãy bật tính năng Profiling để phân tích từng giai đoạn:
-- Bật profiling cho session hiện tại
SET enable_profile = true;
-- Chạy câu query cần chẩn đoán
SELECT category, SUM(price * quantity) FROM orders GROUP BY category;Truy cập Web UI, chọn tab Queries và bấm vào Query ID vừa chạy. Bạn sẽ thấy cây thực thi chi tiết (Execution Graph), chỉ rõ thời gian quét đĩa (OLAP_SCAN_NODE), thời gian gom nhóm (AGGREGATION_NODE) và lưu lượng mạng trao đổi giữa các node.
Tách biệt workload phân tích (OLAP) khỏi cơ sở dữ liệu vận hành (OLTP) là bước đi cốt lõi khi hệ thống mở rộng. Với cụm Docker nhỏ gọn tốn chưa tới 2GB RAM này, bạn đã có ngay một môi trường chuẩn để benchmark hiệu năng trước khi đưa StarRocks vào production pipeline.
