OLTP vs OLAP — hai workload đối lập trên cùng dữ liệu

TL;DR: Một hệ thống dữ liệu phục vụ hai loại công việc rất khác nhau. OLTP (online transaction processing) là các giao dịch nhỏ, nhiều, ghi/đọc vài dòng theo khoá — đặt hàng, cập nhật trạng thái task. OLAP (online analytical processing) là các truy vấn phân tích quét hàng triệu dòng để tổng hợp — "doanh thu theo tháng theo vùng". Chạy query OLAP nặng trên database OLTP đang phục vụ người dùng làm chậm cả hệ thống, nên thực tế người ta tách dữ liệu sang một kho phân tích riêng (data warehouse) với mô hình lưu trữ tối ưu cho đọc. Hiểu sự phân đôi này là nền tảng để thiết kế vòng đời dữ liệu.

Dashboard TaskFlow chạy mượt suốt nhiều tháng. Một sáng, team Business mở báo cáo mới: "tổng số giờ hoàn thành task theo từng phòng ban, theo từng tháng, trong 2 năm qua". Query này quét 18 triệu dòng trong bảng tasks, GROUP BY phòng ban và tháng. Ngay khi nó chạy, mọi người dùng đang thao tác trên TaskFlow thấy app đơ: tạo task mất 4 giây thay vì 40ms, có request timeout.

Cùng một database, cùng một bảng — nhưng một câu query đã kéo sập trải nghiệm của hàng nghìn người dùng. Vì sao? Vì bạn vừa bắt một hệ thống thiết kế cho giao dịch làm công việc phân tích. Bài này phân biệt hai loại workload đó, giải thích vì sao chúng xung khắc, và vì sao mọi hệ thống dữ liệu trưởng thành đều tách chúng ra.

1. Analogy — Quầy thu ngân và phòng kế toán

Một siêu thị có hai bộ phận làm việc trên cùng dữ liệu bán hàng, nhưng theo hai nhịp hoàn toàn khác:

• Quầy thu ngân xử lý từng giao dịch một: quét mã, trừ kho, in hoá đơn — mỗi lần chạm vài món hàng, cực nhanh, xảy ra liên tục cả nghìn lần mỗi giờ. Sai một giao dịch là khách hàng phàn nàn ngay.
• Phòng kế toán cuối tháng mới ngồi tổng hợp: doanh thu theo ngành hàng, so sánh quý này với quý trước, lãi gộp theo chi nhánh — đọc toàn bộ sổ sách, ít lần, nhưng mỗi lần rất nặng.

Bắt nhân viên thu ngân dừng quét hàng để tính tổng doanh thu cả năm thì hàng người xếp hàng sẽ kẹt cứng. Đó chính xác là điều xảy ra khi bạn chạy query OLAP trên database OLTP.

2. OLTP — workload giao dịch

OLTP (online transaction processing) là loại workload phục vụ hoạt động hằng ngày của ứng dụng. Đặc trưng: số lượng query rất lớn, mỗi query chạm ít dòng và được định vị bằng khoá (primary key hoặc index). Người dùng cuối kích hoạt chúng và mong phản hồi tức thì.

-- OLTP: doc 1 task theo khoa -- vai mili-giay
SELECT id, title, status, assignee_id
FROM tasks
WHERE id = 48217;

-- OLTP: ghi mot trang thai moi
UPDATE tasks SET status = 'done', completed_at = NOW()
WHERE id = 48217;

-- OLTP: them mot dong
INSERT INTO tasks (title, project_id, assignee_id, status)
VALUES ('Fix login bug', 12, 7, 'todo');

Yêu cầu cốt lõi của OLTP: độ trễ thấp và throughput cao cho hàng nghìn giao dịch đồng thời, cùng tính đúng đắn (ACID — xem Module 7). Mỗi giao dịch nhỏ nên cái giá phải tối ưu là số lượt, không phải khối lượng mỗi lượt.

3. OLAP — workload phân tích

OLAP (online analytical processing) phục vụ ra quyết định kinh doanh: tổng hợp, so sánh, tìm xu hướng. Đặc trưng ngược hẳn OLTP: số lượng query ít, nhưng mỗi query quét rất nhiều dòng rồi aggregate (SUM, COUNT, AVG, GROUP BY). Người chạy là analyst hoặc dashboard, chấp nhận chờ vài giây đến vài phút.

-- OLAP: tong hop tren hang trieu dong
SELECT
  d.department_name,
  DATE_TRUNC('month', t.completed_at) AS month,
  COUNT(*)                            AS tasks_done,
  SUM(t.effort_hours)                 AS total_hours
FROM tasks t
JOIN users u       ON u.id = t.assignee_id
JOIN departments d ON d.id = u.department_id
WHERE t.completed_at >= '2024-01-01'
GROUP BY d.department_name, DATE_TRUNC('month', t.completed_at)
ORDER BY month;

Query này không quan tâm một dòng cụ thể — nó đọc toàn bộ task trong 2 năm, nhóm lại và tính tổng. Thứ cần tối ưu là thông lượng quét (đọc nhiều dòng nhanh nhất có thể), không phải độ trễ tra cứu một dòng.

4. Cơ chế — vì sao hai workload xung khắc

Vấn đề không chỉ là "query nặng". Vấn đề là cách dữ liệu được sắp trên đĩa tối ưu cho loại này thì tệ cho loại kia.

Database OLTP truyền thống lưu dữ liệu theo dòng (row-oriented): tất cả cột của một dòng nằm cạnh nhau. Đọc/ghi một task (tất cả cột của nó) chỉ cần chạm một chỗ — hoàn hảo cho OLTP. Nhưng khi query OLAP chỉ cần 2 cột (department_id, effort_hours) trên 18 triệu dòng, engine vẫn phải đọc qua mọi cột của mọi dòng (title, description, timestamps...) vì chúng nằm xen kẽ trên đĩa — lãng phí phần lớn I/O.

Row-oriented (OLTP) — moi cot cua 1 dong nam canh nhau:
[id=1, title=..., effort=3, dept=A] [id=2, title=..., effort=5, dept=B] ...
-> doc 1 task: 1 lan cham (nhanh)
-> SUM(effort): phai doc ca title, description... cua moi dong (phi)

Đó là lý do hệ thống phân tích dùng lưu trữ theo cột (column-oriented) — gom tất cả giá trị của một cột lại với nhau, để query analytic chỉ đọc đúng cột cần. Cơ chế row-store vs column-store và vì sao nó đổi mọi thứ được mổ riêng ở bài kế tiếp.

Thêm một xung khắc ở tầng tài nguyên: query OLAP quét bảng lớn chiếm hết bộ nhớ cache, I/O và CPU, đẩy các giao dịch OLTP nhỏ vào hàng đợi. Hai workload tranh nhau cùng một máy — đó là gốc rễ vì sao TaskFlow đơ ở đầu bài.

5. Lời giải — tách thành hai hệ thống

Vì hai workload xung khắc cả về mô hình lưu trữ lẫn tài nguyên, giải pháp chuẩn là tách: giữ database OLTP cho ứng dụng, và sao chép dữ liệu sang một data warehouse riêng tối ưu cho OLAP. Một pipeline định kỳ (ETL/ELT — xem bài 04) chuyển dữ liệu từ nguồn OLTP sang warehouse.

flowchart LR
  subgraph OLTP["He thong OLTP (ung dung)"]
    APP["App TaskFlow"] --> DB[("Database giao dich<br/>row-oriented")]
  end
  DB -->|"ETL / ELT dinh ky"| WH[("Data warehouse<br/>column-oriented")]
  subgraph OLAP["He thong OLAP (phan tich)"]
    WH --> BI["Dashboard / BI<br/>analyst query"]
  end

Sau khi tách: query "doanh thu theo tháng" chạy trên warehouse, không đụng tới database đang phục vụ người dùng. TaskFlow không còn đơ. Đổi lại, dữ liệu trong warehouse trễ so với thực tế (cập nhật theo chu kỳ ETL — vài phút đến hằng ngày), nên OLAP chấp nhận đọc dữ liệu hơi cũ để đổi lấy không ảnh hưởng production.

6. Các thao tác OLAP kinh điển

Khi dữ liệu đã ở warehouse, analyst khám phá nó qua vài thao tác chuẩn, thường hình dung dữ liệu như một "khối" (cube) nhiều chiều:

Bốn thao tác này đều quy về GROUP BY ở các mức khác nhau cộng với WHERE để lọc — kỹ thuật bạn đã học ở Module 3. Điểm khác là chúng chạy trên kho phân tích, trên khối lượng lớn.

7. Pitfall — chạy analytics trên database production

-- WRONG: chay thang tren DB production, gio cao diem
SELECT department_id, SUM(effort_hours)
FROM tasks
GROUP BY department_id;   -- quet 18M dong, dong bang trai nghiem user

-- DUNG (huong tiep can):
-- 1. Chay tren read replica / data warehouse, KHONG phai primary
-- 2. Hoac materialized view cap nhat dinh ky
-- 3. Hoac ETL sang warehouse column-oriented

8. 📚 Deep Dive

9. Liên hệ các bài khác

• Bài 02 — Row store vs column store: cơ chế lưu trữ giải thích vì sao OLTP và OLAP cần mô hình đĩa khác nhau — đọc ngay sau bài này.
• Bài 03 — Dimensional modeling & star schema: warehouse OLAP không chuẩn hoá như OLTP mà dùng lược đồ chiều để tối ưu đọc.
• Module 3 — GROUP BY & HAVING: nền tảng aggregate mà mọi thao tác OLAP dựa trên.
• Module 7 — Isolation levels: vì sao query phân tích dài giữ snapshot lâu gây áp lực lên DB giao dịch.

10. Tóm tắt

• OLTP = nhiều giao dịch nhỏ, đọc/ghi vài dòng theo khoá, độ trễ thấp — phục vụ ứng dụng.
• OLAP = ít query nhưng mỗi query quét nhiều dòng để tổng hợp — phục vụ phân tích, chấp nhận độ trễ cao hơn.
• Hai workload xung khắc vì mô hình lưu trữ (row vs column) và vì tranh tài nguyên trên cùng một máy.
• Lời giải chuẩn: tách dữ liệu sang data warehouse riêng, đồng bộ qua ETL/ELT; đổi lại dữ liệu phân tích trễ một chút.
• Thao tác OLAP kinh điển (roll-up, drill-down, slice, dice) đều quy về GROUP BY + WHERE ở các mức khác nhau.
• Pitfall: chạy aggregate lớn thẳng trên DB production làm chậm toàn bộ giao dịch — tín hiệu cần tách OLAP.

11. Tự kiểm tra

Bài tiếp theo: Row store vs column store — vì sao OLAP cần lưu theo cột