Published about 4 hours ago 7 min read

Greenplum Database Bài học 11: DISTRIBUTED RANDOMLY vs DISTRIBUTED REPLICATED: Khi nào nên dùng và cái giá phải trả

Ở Bài học 9 và 10, chúng ta đã thấu hiểu sức mạnh của Hash Distribution (DISTRIBUTED BY) — chiến lược tối ưu nhất cho 90% các bảng dữ liệu lớn nhờ khả năng thực hiện Co-located Join. Tuy nhiên, trong thực tế xây dựng hệ thống Data Warehouse, bạn sẽ gặp những bảng dữ liệu không có bất kỳ cột nào thích hợp làm khóa băm, hoặc những bảng danh mục nhỏ nhưng xuất hiện trong mọi câu truy vấn phân tích.

Đó là lúc hai chiến lược còn lại xuất hiện: DISTRIBUTED RANDOMLY và DISTRIBUTED REPLICATED. Mỗi lựa chọn này đều mang lại những lợi ích tuyệt vời nhưng cũng đi kèm với những "cái giá phải trả" rất đắt nếu dùng sai chỗ.

1. DISTRIBUTED RANDOMLY: Giải pháp "Cứu cánh" khi không có khóa tự nhiên

1.1. Bản chất hoạt động

Khi bạn tạo bảng với cú pháp DISTRIBUTED RANDOMLY, Greenplum sẽ không dùng hàm băm (Hash) dựa trên bất kỳ cột nào. Thay vào đó, nó sử dụng thuật toán xoay vòng (Round-Robin) để rải lần lượt từng dòng dữ liệu mới nạp vào hệ thống xuống các Segments một cách ngẫu nhiên.

[ Dữ liệu mới nạp ] ──► Segment 0 (Dòng 1, 4, 7...)
                    ──► Segment 1 (Dòng 2, 5, 8...)
                    ──► Segment N (Dòng 3, 6, 9...)

1.2. Ưu điểm tuyệt đối: Triệt tiêu hoàn toàn Data Skew

Vì dữ liệu được rải đều luân phiên, dung lượng lưu trữ trên các Segments luôn cân bằng tuyệt đối 100%.
Đây là lựa chọn hoàn hảo cho các Staging Tables (bảng đệm trung gian) nơi bạn cần đổ hàng triệu dòng dữ liệu thô (raw logs, file CSV trích xuất từ Kafka/S3) vào hệ thống với tốc độ nhanh nhất mà không lo sợ một Segment nào bị quá tải (Skew).

1.3. Cái giá phải trả: Thảm họa Motion khi truy vấn

Mất cục bộ dữ liệu (Zero Locality): Vì dữ liệu nằm rải rác vô định hình, khi bạn thực hiện câu lệnh SELECT có điều kiện WHERE user_id = 123 hoặc câu lệnh JOIN với bảng khác, Greenplum buộc phải bật toán tử Redistribute Motion để quét toàn bộ các Segment, làm tẻ nhánh và bão hòa mạng Interconnect.
Quy tắc vàng: Chỉ dùng DISTRIBUTED RANDOMLY cho các bảng tạm thời (temporary/staging tables) cần xóa đi sau khi xử lý ETL, hoặc các bảng Log ghi nhận sự kiện thuần túy không bao giờ đem ra JOIN phức tạp.

2. DISTRIBUTED REPLICATED: Vũ khí tối thượng cho bảng danh mục nhỏ

2.1. Bản chất hoạt động

Ngược lại hoàn toàn với việc chia nhỏ dữ liệu, chiến lược DISTRIBUTED REPLICATED sẽ nhân bản và copy nguyên văn 100% toàn bộ bảng đó xuống TẤT CẢ các Segments trong cụm.

Nếu cụm của bạn có 50 Segments, một bảng Replicated chứa 1.000 dòng sẽ thực tế chiếm không gian lưu trữ cho 50 x 1.000 = 50.000 dòng trên toàn hệ thống.

[ Master Node ] ──(Copy nguyên văn)──► Segment 0 (Bản sao hoàn chỉnh)
                ──(Copy nguyên văn)──► Segment 1 (Bản sao hoàn chỉnh)
                ──(Copy nguyên văn)──► Segment N (Bản sao hoàn chỉnh)

2.2. Ưu điểm tuyệt đối: Local Join thần tốc

Không tốn một byte mạng: Khi một bảng giao dịch khổng lồ (Fact Table) ở Segment 0 cần tra cứu tên tỉnh thành hoặc loại sản phẩm từ bảng danh mục, nó không cần phải đi hỏi các Segment khác qua mạng Interconnect. Bản thân Segment 0 đã lưu sẵn một bản sao của bảng danh mục đó rồi. Phép JOIN diễn ra tức thì.

2.3. Cái giá phải trả: Lãng phí dung lượng và Phí tổn ghi dữ liệu (Write Amplification)

Bùng nổ dung lượng đĩa: Nếu bạn dại dột Replicate một bảng có dung lượng lớn (ví dụ vài triệu dòng) xuống cụm 100 Segments, bạn đang tự tay lãng phí hàng trăm GB đĩa chỉ để chứa dữ liệu trùng lặp.
Chi phí ghi dữ liệu cực cao (INSERT / UPDATE): Mỗi khi có một dòng lệnh INSERT hoặc UPDATE thay đổi dữ liệu trên bảng Replicated này, Master phải gửi lệnh đó cập nhật xuống tất cả các Segments cùng lúc thông qua giao thức đồng bộ khóa phân tán. Thao tác ghi sẽ chậm đi gấp nhiều lần.

3. Bảng ma trận so sánh tổng quan 3 chiến lược phân phối

Để giúp các kỹ sư Backend và DBA dễ dàng đưa ra quyết định kiến trúc khi thiết kế cơ sở dữ liệu,

Tiêu chí	Hash (DISTRIBUTED BY)	Random (DISTRIBUTED RANDOMLY)	Replicated (DISTRIBUTED REPLICATED)
Mục đích chính	Lưu trữ và phân tích các bảng dữ liệu lớn (`Fact Tables`) có dung lượng khủng.	Nạp dữ liệu thô tạm thời (`Staging / Raw Log Tables`) hoặc dữ liệu không có khóa tự nhiên.	Các bảng danh mục, tham chiếu nhỏ (`Dimension / Lookup Tables`) dùng chung toàn cụm.
Dung lượng lưu trữ	Chia đều theo tỷ lệ Hash Key của cột phân phối (Tối ưu nếu key phân tán tốt).	Chia đều tuyệt đối 100% xuống mọi Segment (Cực kỳ cân bằng).	Nhân bản toàn bộ ( $N$ lần) lên mọi Segment trong cụm (Tốn kém dung lượng).
Hiệu năng JOIN	Cực tốt nếu hai bảng JOIN cùng chung khóa phân phối (`Co-located Join`, không qua mạng).	Kém: Buộc Greenplum phải kích hoạt `Redistribute Motion` (chạy qua mạng nội bộ để gom dữ liệu).	Cực tốt: JOIN cục bộ ngay lập tức tại mỗi Segment mà không phát sinh traffic mạng (`Broadcast Motion`).
Tốc độ ghi (INSERT)	Nhanh, ghi trực tiếp xuống Segment đích dựa vào mã Hash.	Nhanh nhất: Rải đều vòng tròn liên tục mà không cần tính toán thuật toán Hash.	Chậm hơn, vì hệ thống phải ghi đồng thời bản sao xuống toàn bộ các Segment.
Nguy cơ lệch dữ liệu (`Data Skew`)	Cao nếu chọn nhầm cột phân phối có độ phân tán thấp (VD: cột `status`, `gender`).	Bằng 0 (Tuyệt đối không bao giờ xảy ra lệch dữ liệu).	Không áp dụng (vì dữ liệu được nhân bản giống hệt nhau ở mọi nơi).

4. Lời khuyên thực chiến cho Kỹ sư Backend

Khảo sát quy mô bảng trước khi chọn chiến lược:
- Bảng trên 1 triệu dòng: Bắt buộc tìm cách dùng Hash Distribution.
- Bảng dưới 10.000 dòng, ít khi thay đổi (như danh mục tiền tệ, trạng thái đơn hàng, phân quyền): Mạnh dạn dùng Replicated Distribution.
- Bảng log hệ thống nạp tự động qua API, không có khóa tự nhiên: Dùng Random Distribution cho tầng Staging, sau đó ETL sang bảng Hash.
Kiểm tra loại bảng hiện tại trên Production: Bạn có thể dùng câu lệnh hệ thống pg_distributed_by kết hợp với pg_class để xem chiến lược phân phối của bất kỳ bảng nào trong Greenplum trước khi viết câu truy vấn tối ưu.

Tóm tắt Bài học 11

DISTRIBUTED RANDOMLY giúp rải đều 100% dữ liệu không cần suy nghĩ về khóa, triệt tiêu Data Skew, nhưng làm chậm các câu lệnh JOIN do phải dịch chuyển dữ liệu qua mạng. Chỉ nên dùng cho Staging Tables.
DISTRIBUTED REPLICATED nhân bản toàn bộ bảng xuống mọi Segment giúp tối ưu hóa tuyệt đối các phép JOIN danh mục nhỏ, nhưng đổi lại bằng cái giá tốn dung lượng đĩa và làm chậm thao tác ghi (INSERT/UPDATE).
Việc kết hợp linh hoạt ba chiến lược (Hash, Random, Replicated) là chìa khóa vàng giúp hệ thống Data Warehouse vừa đạt tốc độ xử lý hàng tỷ bản ghi, vừa tối ưu hóa tài nguyên phần cứng.

Ở bài học tiếp theo (Bài học 12), chúng ta sẽ đối mặt với "căn bệnh ung thư" của hệ thống MPP: Data Skew (Lệch dữ liệu) — Cách phát hiện các Segment bị quá tải và kỹ thuật xử lý triệt để.

Bạn có muốn thử phân tích một bài toán thực tế về việc lựa chọn giữa Hash và Replicated cho một bảng danh mục 50.000 sản phẩm tại Hasaki không?

cloud database