Quick Start: Chạy YugabyteDB trong 5 phút
Nếu bạn đã quen với PostgreSQL thì mừng — YugabyteDB dùng được gần như y chang về SQL syntax và tooling. Cách nhanh nhất để thử là Docker:
docker pull yugabytedb/yugabyte
docker run -d --name yugabyte \
-p 5433:5433 -p 7000:7000 -p 9000:9000 -p 9042:9042 \
yugabytedb/yugabyte \
bin/yugabyted start --daemon=false
Đợi khoảng 30 giây rồi kết nối thử:
psql -h 127.0.0.1 -p 5433 -U yugabyte -d yugabyte
Lưu ý port 5433 (khác Postgres mặc định 5432) để tránh conflict nếu máy bạn đang chạy Postgres song song. Vào được rồi thì tạo bảng thử:
CREATE TABLE employees (
id SERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL,
department VARCHAR(50),
created_at TIMESTAMP DEFAULT NOW()
);
INSERT INTO employees (name, department) VALUES
('Nguyen Van A', 'Engineering'),
('Tran Thi B', 'DevOps'),
('Le Van C', 'Backend');
SELECT * FROM employees;
Chạy ngon — đây đã là distributed SQL database mà gõ lệnh y hệt Postgres. Dashboard web xem tại http://localhost:7000 hiển thị đầy đủ cluster info, tablet distribution, và node health.
YugabyteDB là gì và tại sao cần nó?
Postgres đơn lẻ chạy tốt cho hầu hết ứng dụng — nhưng đến lúc data tăng lên vài chục triệu record, traffic write tăng đột biến, hoặc cần deploy ở nhiều region cùng lúc thì bắt đầu vướng. Lúc đó có vài lựa chọn: sharding tay trong application code (phức tạp, dễ bug), dùng read replica (chỉ scale read, không scale write), hoặc chuyển sang distributed database.
YugabyteDB sinh ra để giải quyết đúng bài toán đó. Kiến trúc bên trong gồm 3 tầng:
- YSQL layer — tương thích PostgreSQL wire protocol, dùng lại hầu hết SQL syntax và driver
- DocDB — storage engine tự phát triển dựa trên RocksDB, dùng Raft consensus để đảm bảo consistency giữa các node
- Tablet system — tự động chia data thành các shard (gọi là tablet) và phân phối đều trên các node
Điểm mạnh nhất là auto-sharding — bạn không cần định nghĩa shard key hay viết routing logic trong app. YugabyteDB tự rebalance khi thêm hoặc bớt node.
Vài điểm khác biệt so với Postgres thuần
- SERIAL sequence: có gap (gap là bình thường, không phải bug) do distributed nature — nếu cần ID liên tục không gap thì dùng UUID
- Foreign key: hoạt động bình thường, nhưng join nặng giữa các bảng lớn cần khai báo colocation
- Extensions: hỗ trợ pgcrypto, pg_stat_statements và một số extension phổ biến — không hỗ trợ toàn bộ
- Port mặc định: 5433 cho YSQL, 9042 cho YCQL (Cassandra-compatible API)
Cài đặt cluster nhiều node
Single node bằng Docker thì dùng để dev/test. Để setup cluster thật với fault tolerance, cần tối thiểu 3 node. Dưới đây là ví dụ với 3 máy IP: 192.168.1.1, 192.168.1.2, 192.168.1.3.
Trên mỗi máy, download và giải nén:
wget https://downloads.yugabyte.com/releases/2.21.0.0/yugabyte-2.21.0.0-b545-linux-x86_64.tar.gz
tar xvfz yugabyte-2.21.0.0-b545-linux-x86_64.tar.gz
cd yugabyte-2.21.0.0/
Khởi động lần lượt từng node:
# Node 1 — khởi động đầu tiên
./bin/yugabyted start \
--advertise_address=192.168.1.1 \
--cloud_location=aws.us-east-1.us-east-1a
# Node 2 — join vào Node 1
./bin/yugabyted start \
--advertise_address=192.168.1.2 \
--join=192.168.1.1 \
--cloud_location=aws.us-east-1.us-east-1b
# Node 3 — join vào Node 1
./bin/yugabyted start \
--advertise_address=192.168.1.3 \
--join=192.168.1.1 \
--cloud_location=aws.us-east-1.us-east-1c
Kiểm tra trạng thái:
./bin/yugabyted status
Với replication factor mặc định là 3, khi 1 node chết thì cluster vẫn hoạt động bình thường — Raft consensus tự bầu lại leader, không cần can thiệp tay. Đây là điểm khác biệt lớn so với Postgres Streaming Replication truyền thống.
Cấu hình Multi-region
Deploy trên nhiều region (Tokyo + Singapore + Seoul chẳng hạn), chỉ cần thay tham số --cloud_location cho đúng region thật:
# Node Tokyo
./bin/yugabyted start \
--advertise_address=10.0.1.1 \
--join=10.0.1.1 \
--cloud_location=aws.ap-northeast-1.ap-northeast-1a
# Node Singapore
./bin/yugabyted start \
--advertise_address=10.0.2.1 \
--join=10.0.1.1 \
--cloud_location=aws.ap-southeast-1.ap-southeast-1a
# Node Seoul
./bin/yugabyted start \
--advertise_address=10.0.3.1 \
--join=10.0.1.1 \
--cloud_location=aws.ap-northeast-2.ap-northeast-2a
Sau đó dùng tablespace để pin data về region cụ thể — giảm latency cho user ở từng khu vực:
CREATE TABLESPACE tokyo_ts WITH (
replica_placement='{"num_replicas": 1, "placement_blocks": [
{"cloud": "aws", "region": "ap-northeast-1", "zone": "ap-northeast-1a", "min_num_replicas": 1}
]}'
);
CREATE TABLE orders (
id BIGSERIAL,
user_id INT,
region TEXT NOT NULL,
amount DECIMAL(10,2),
PRIMARY KEY (id, region)
) PARTITION BY LIST (region);
CREATE TABLE orders_tokyo PARTITION OF orders
FOR VALUES IN ('tokyo')
TABLESPACE tokyo_ts;
Tips thực tế khi làm việc với YugabyteDB
1. Dùng UUID thay SERIAL cho distributed workload
CREATE EXTENSION IF NOT EXISTS pgcrypto;
CREATE TABLE sessions (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
user_id INT,
token TEXT,
expires_at TIMESTAMP
);
UUID phân phối đều hơn trên các tablet, tránh hotspot khi insert số lượng lớn.
2. Colocation cho bảng nhỏ join nhiều
-- Database với colocation — bảng nhỏ nằm chung tablet
CREATE DATABASE myapp WITH COLOCATION = true;
-- Bảng lớn thì tắt colocation riêng
CREATE TABLE large_events (...) WITH (COLOCATION = false);
3. Import data từ CSV/JSON
Khi cần import dữ liệu test từ CSV vào database, mình thường convert sang JSON trước rồi mới dùng script Python để import. Mình hay dùng converter tại toolcraft.app/vi/tools/data/csv-to-json — chạy trên trình duyệt nên không sợ lộ data, tiện hơn viết script tay nhiều.
Sau khi có file JSON, import bằng Python với psycopg2 (kết nối y hệt Postgres):
import psycopg2
import json
conn = psycopg2.connect(
host="127.0.0.1",
port=5433, # port YSQL của YugabyteDB
database="yugabyte",
user="yugabyte",
password="yugabyte"
)
with open("data.json") as f:
records = json.load(f)
cur = conn.cursor()
for record in records:
cur.execute(
"INSERT INTO employees (name, department) VALUES (%s, %s)",
(record["name"], record["department"])
)
conn.commit()
cur.close()
conn.close()
print(f"Imported {len(records)} records")
4. Backup và restore
# Backup — cú pháp giống pg_dump
./bin/ysql_dump -h 127.0.0.1 -p 5433 -U yugabyte yugabyte > backup.sql
# Restore
./bin/ysqlsh -h 127.0.0.1 -p 5433 -U yugabyte -d yugabyte -f backup.sql
5. Kiểm tra health qua REST API
# Health tổng quan
curl http://localhost:7000/api/v1/health-check
# Phân phối tablet trên các node
curl http://localhost:7000/api/v1/tablet-servers
Khi nào nên dùng YugabyteDB?
Không phải project nào cũng cần distributed SQL. YugabyteDB phù hợp khi:
- Cần scale write horizontally — traffic write vượt khả năng 1 node Postgres đơn lẻ
- Cần multi-region active-active — user ở nhiều khu vực địa lý cần latency thấp
- Muốn fault tolerance tự động mà không phải tay handle failover lúc 3 giờ sáng
- Muốn giữ nguyên SQL — không muốn refactor sang NoSQL hay đổi ORM
Nếu app vẫn đang chạy tốt với Postgres single node, chưa cần migrate vội. Distributed system đi kèm complexity nhất định — network latency giữa các node, replication lag trong edge case. Nhưng khi đã đến ngưỡng cần scale, YugabyteDB là option ít đau đầu nhất vì không phải rewrite query hay học mô hình data hoàn toàn mới.

