Posted inDatabase

Mở rộng PostgreSQL: Hướng dẫn thực hành về kiến trúc và cài đặt YugabyteDB

Database tutorial - IT technology blog
Database tutorial - IT technology blog

“Bức tường” mở rộng lúc 2 giờ sáng

Sáu tháng trước, instance PostgreSQL chính của chúng tôi đã chạm ngưỡng giới hạn. Chúng tôi đang chạy trên AWS r6g.2xlarge và mặc dù có 64GB RAM, mức sử dụng CPU vẫn luôn ở mức 95% trong giờ cao điểm. Chúng tôi đã thử các giải pháp thông thường: thêm read replicas và tối ưu hóa index. Tuy nhiên, độ trễ sao chép (replication lag) sớm chạm mốc 10 giây, gây ra các vấn đề nghiêm trọng về tính nhất quán dữ liệu cho người dùng.

Chúng tôi đứng trước một quyết định khó khăn. Hoặc dành nhiều tháng để xây dựng một lớp sharding tùy chỉnh—điều này đồng nghĩa với việc phải viết lại các truy vấn JOIN phức tạp—hoặc chuyển sang một cơ sở dữ liệu được thiết kế để mở rộng hàng ngang (horizontal scale). Sau khi đánh giá nhiều lựa chọn, chúng tôi đã chuyển các dịch vụ cốt lõi sang YugabyteDB. Đây là những gì chúng tôi đã học được và cách bạn có thể bắt đầu.

Tại sao SQL truyền thống gặp khó khăn khi tăng trưởng

PostgreSQL và MySQL được xây dựng cho kỷ nguyên mà một máy chủ khổng lồ thống trị trung tâm dữ liệu. Mặc dù chúng cực kỳ đáng tin cậy, nhưng kiến trúc của chúng có ba lỗ hổng cơ bản đối với các ứng dụng hiện đại, lưu lượng truy cập cao:

  • Nghẽn cổ chai khi ghi (The Write Bottleneck): Trong thiết lập tiêu chuẩn, chỉ có một node có thể xử lý việc ghi. Nếu tốc độ nạp dữ liệu vượt quá khả năng xử lý của một CPU, bạn sẽ bị kẹt.
  • “Thuế” Sharding (The Sharding Tax): Việc chia nhỏ dữ liệu thủ công trên nhiều instance là một cơn ác mộng về vận hành. Nó phá vỡ các giao dịch ACID và khiến việc báo cáo chéo giữa các shard gần như không thể thực hiện được.
  • Khoảng trống khi chuyển vùng dự phòng (Failover Gaps): Ngay cả với các công cụ có tính sẵn sàng cao, việc nâng cấp một bản sao (replica) mới thường dẫn đến 30 đến 60 giây downtime. Trong một môi trường tốc độ cao, đó là cả một thiên niên kỷ.

Đánh giá các giải pháp thay thế

Đầu tiên tôi đã xem xét Amazon Aurora. Đó là một dịch vụ tuyệt vời, nhưng nó vẫn dựa vào một writer node duy nhất cho mỗi cluster. Nếu bạn cần khả năng ghi đa vùng (multi-region write) mà không muốn chịu độ trễ của một single global master, Aurora sẽ trở nên phức tạp và đắt đỏ rất nhanh.

YugabyteDB chọn một cách tiếp cận khác. Nó sử dụng lại mã nguồn C thực tế của PostgreSQL cho lớp truy vấn nhưng thay thế storage engine bằng một hệ thống phân tán có tên là DocDB. Điều này có nghĩa là bạn giữ lại được các tính năng như trigger và stored procedure, nhưng dữ liệu sẽ tự động được trải rộng trên một cluster gồm nhiều node. Nó mang lại cảm giác như dùng Postgres, nhưng khả năng mở rộng như một NoSQL engine.

Thiết lập cụm YugabyteDB đầu tiên của bạn

Mặc dù môi trường production thường chạy trên Kubernetes, nhưng việc thiết lập một cluster cục bộ là cách nhanh nhất để hiểu về kiến trúc này. Chúng ta sẽ sử dụng công cụ yugabyted để quản lý quá trình này.

1. Cài đặt

Tải xuống bản binary mới nhất. Tại thời điểm viết bài, phiên bản 2.19 là bản ổn định cho hầu hết người dùng.

# Tải gói cài đặt
wget https://downloads.yugabyte.com/releases/2.19.2.0/yugabyte-2.19.2.0-b121-linux-x86_64.tar.gz

# Giải nén tệp
tar xvfz yugabyte-2.19.2.0-b121-linux-x86_64.tar.gz
cd yugabyte-2.19.2.0/

# Chạy cấu hình môi trường
./bin/post_install.sh

2. Khởi chạy Cluster

Bạn có thể khởi động một cơ sở dữ liệu đầy đủ chức năng chỉ với một câu lệnh. Lệnh này khởi tạo cả API YSQL (tương thích PostgreSQL) và YCQL (lấy cảm hứng từ Cassandra).

./bin/yugabyted start --base_dir=$HOME/yugabyte-data

3. Mô phỏng Cluster 3-Node

Một node duy nhất không thể hiện được sức mạnh của Distributed SQL. Để thấy cơ chế đồng thuận Raft hoạt động, chúng ta có thể mô phỏng nhiều node trên máy cục bộ bằng cách sử dụng các IP alias và cổng khác nhau.

# Khởi động node thứ hai
./bin/yugabyted start \
  --base_dir=$HOME/yugabyte-data-2 \
  --listen=127.0.0.2 \
  --join=127.0.0.1

# Khởi động node thứ ba
./bin/yugabyted start \
  --base_dir=$HOME/yugabyte-data-3 \
  --listen=127.0.0.3 \
  --join=127.0.0.1

Giờ đây bạn đã có một cluster có khả năng phục hồi. Nếu một node bị lỗi, hai node còn lại sẽ bầu ra một leader mới trong vài giây, giúp ứng dụng của bạn luôn trực tuyến.

Tương tác với dữ liệu của bạn

Bạn không cần công cụ mới. Nếu đã cài đặt psql, bạn có thể kết nối trực tiếp hoặc sử dụng shell ysqlsh tích hợp sẵn.

./bin/ysqlsh -h 127.0.0.1

Các lệnh SQL tiêu chuẩn hoạt động chính xác như mong đợi:

CREATE TABLE shipments (
    shipment_id INT PRIMARY KEY,
    customer_name TEXT NOT NULL,
    status TEXT,
    updated_at TIMESTAMP DEFAULT NOW()
);

INSERT INTO shipments (shipment_id, customer_name, status) 
VALUES (1001, 'Tập đoàn Logistics Toàn cầu', 'Đang vận chuyển');

Dưới lớp vỏ, YugabyteDB băm (hash) shipment_id và đặt dữ liệu vào một “tablet”. Tablet này được sao chép qua ba node của bạn. Bạn có được tính dư thừa dữ liệu mà không cần viết bất kỳ dòng logic sharding nào.

Xử lý nhập dữ liệu lớn

Việc di chuyển từ một hệ thống cũ thường liên quan đến việc chuyển hàng triệu dòng dữ liệu. Trong quá trình di chuyển của mình, chúng tôi đã phải chuyển đổi khoảng 800.000 bản ghi cũ từ định dạng CSV lộn xộn sang cột JSONB.

Để tăng tốc việc này mà không cần viết các script Python phức tạp, tôi đã sử dụng toolcraft.app/vi/tools/data/csv-to-json. Nó xử lý việc chuyển đổi cục bộ ngay trong trình duyệt của bạn. Điều này cho phép chúng tôi nhanh chóng định dạng dữ liệu cho lệnh COPY của Postgres mà không làm ảnh hưởng đến bảo mật dữ liệu.

Kiểm tra khả năng phục hồi

Giá trị thực sự của Distributed SQL là khả năng sống sót sau lỗi phần cứng. Hãy thử dừng một trong các tiến trình đang chạy trong khi một script đang ghi dữ liệu vào cluster:

# Xác định và dừng một node
ps aux | grep yugabyted
kill -9 <PID_CỦA_NODE_2>

Theo dõi log ứng dụng của bạn. Bạn sẽ nhận thấy một khoảng dừng ngắn—thường ít hơn 3 giây—trong khi cluster thực hiện tái cân bằng (re-balance). Sau đó, việc ghi sẽ tiếp tục bình thường. Không cần failover thủ công và không cần cập nhật chuỗi kết nối.

YugabyteDB có phù hợp với bạn không?

Đây không phải là lựa chọn đúng đắn cho mọi dự án. Nếu bạn đang xây dựng một MVP nhỏ có thể chạy thoải mái trên một VPS 10 USD/tháng, hãy trung thành với PostgreSQL tiêu chuẩn. Sự đơn giản trong vận hành của một instance duy nhất là rất khó đánh bại ở quy mô đó.

Tuy nhiên, nếu lộ trình của bạn bao gồm tính sẵn sàng đa vùng hoặc nếu bạn đã mệt mỏi với việc nâng cấp cấu hình máy chủ sáu tháng một lần, YugabyteDB là bước đi hợp lý tiếp theo. Nó cung cấp các đảm bảo ACID của Postgres với lộ trình tăng trưởng hàng ngang của đám mây. Bạn được giữ lại các kỹ năng SQL của mình trong khi loại bỏ được nỗi lo về việc mở rộng.

Share:
Tags: