1. Cấu hình Partition và Replication Factor cho dữ liệu lớn
Bước 1: Xác định số lượng partition và replication factor dựa trên kích thước dữ liệu và độ dư thừa mong muốn.
Tại sao: Nebula Graph chia dữ liệu thành các partition nhỏ để phân tán. Nếu số partition quá ít, một số node sẽ quá tải. Replication factor (số bản sao) càng cao thì khả năng chịu lỗi càng tốt nhưng tốn dung lượng.
Kết quả mong đợi: Không gian lưu trữ được chia đều, không có điểm nghẽn (hotspot).
Để xem cấu hình hiện tại của space, hãy kết nối qua nGQL console.
SHOW SPACES;
Kết quả sẽ hiển thị danh sách các space. Chọn space cần tối ưu (ví dụ: 'test_data') để xem chi tiết.
SHOW SPACE SPACE_ID test_data;
Nếu space chưa được tạo hoặc cần tạo mới với cấu hình tối ưu, sử dụng lệnh CREATE SPACE. Giả sử chúng ta cần 100 partition và 3 replica cho dữ liệu lớn.
CREATE SPACE IF NOT EXISTS large_data_space (PARTITION_NUM = 100, REPLICA_FACTOR = 3);
Verify: Kiểm tra lại cấu hình vừa tạo.
SHOW SPACE SPACE_ID large_data_space;
Kết quả phải hiển thị Partition num: 100 và Replication factor: 3.
2. Tối ưu hóa tham số trong graph.conf cho workload cụ thể
Bước 1: Chỉnh sửa file cấu hình của Graph Service để tối ưu bộ nhớ đệm và số lượng kết nối.
Tại sao: Mặc định của Nebula Graph phù hợp cho môi trường demo. Với workload lớn (nhiều query song song), cần tăng cache và giới hạn connection để tránh OOM (Out of Memory) hoặc tắc nghẽn.
Kết quả mong đợi: Graph Service xử lý được nhiều request đồng thời hơn, giảm latency.
File cấu hình nằm tại /etc/nebula-graph/graph.conf. Sử dụng nano hoặc vim để chỉnh sửa.
sudo nano /etc/nebula-graph/graph.conf
Thêm hoặc chỉnh sửa các tham số sau vào phần [conf] hoặc [graph] tùy phiên bản, đảm bảo các giá trị phù hợp với RAM của server (ví dụ 16GB RAM).
[conf]
# Tăng bộ đệm cho kết nối
max_connection_num = 10000
# Tăng kích thước cache cho vertex/edge
vertex_cache_size = 104857600
edge_cache_size = 104857600
# Tối ưu hóa bộ nhớ cho query
query_cache_size = 52428800
# Giới hạn độ sâu của query để tránh treo
max_depth = 10
Sau khi lưu file, cần restart dịch vụ để áp dụng.
sudo systemctl restart nebula-graph
Verify: Kiểm tra trạng thái service và xem log để đảm bảo không có lỗi khởi động.
sudo systemctl status nebula-graph
Log khởi động thành công sẽ không có dòng báo lỗi liên quan đến "failed to bind" hay "config error".
3. Sử dụng Balancer để cân bằng tải dữ liệu
Bước 1: Kích hoạt và cấu hình Balancer tự động để phân phối đều các partition giữa các Storage Service.
Tại sao: Khi dữ liệu tăng trưởng, các partition có thể bị dồn về một vài storage node gây mất cân bằng. Balancer tự động di chuyển các partition (hot partitions) để đảm bảo tải đều.
Kết quả mong đợi: Số lượng partition trên mỗi storage node gần như bằng nhau.
Truy cập vào nGQL Console để cấu hình balancer. Lệnh để bật tính năng tự động cân bằng.
SET BALANCER STATUS = true;
Để xem trạng thái hiện tại của balancer.
SHOW BALANCER STATUS;
Nếu muốn kiểm tra sự phân bổ hiện tại trước khi cân bằng.
SHOW SPACE large_data_space;
Để thực hiện cân bằng thủ công ngay lập tức cho một space cụ thể (tạo task balancer).
BALANCE SPACE large_data_space;
Kiểm tra tiến trình của task balancer vừa tạo.
SHOW BALANCER PROCESS;
Verify: Chờ vài phút để balancer chạy xong, sau đó kiểm tra lại sự phân bổ.
SHOW SPACE large_data_space;
Kết quả: Cột "Storage Hosts" và số lượng partition trên mỗi host phải đồng đều. Nếu trước đây có host có 50 partition và host kia 0, giờ sẽ là 25 và 25.
4. Cấu hình chính sách làm sạch và Backup tự động
Bước 1: Thiết lập TTL (Time To Live) để tự động xóa dữ liệu cũ và cấu hình backup định kỳ.
Tại sao: Dữ liệu lớn cần được dọn dẹp để tiết kiệm disk. Backup tự động đảm bảo an toàn dữ liệu khi có sự cố phần cứng.
Kết quả mong đợi: Dữ liệu quá hạn được xóa tự động, bản backup mới được tạo theo lịch.
Đầu tiên, cấu hình TTL cho một Tag cụ thể. Ví dụ: Tag 'user_logs' chỉ lưu trong 30 ngày.
ALTER TAG user_logs SET TTL = "30d";
Kiểm tra cấu hình TTL.
SHOW TAGS;
Tiếp theo, cấu hình Backup. Trước hết cần tạo một backup directory trên Storage Service (thực hiện trên tất cả node storage).
mkdir -p /data/nebula-data/backup
sudo chown nebula:nebula /data/nebula-data/backup
Sau đó, tạo backup task trong nGQL. Backup toàn bộ space 'large_data_space'.
BACKUP SPACE large_data_space TO "backup_space_2024" WITH OPTIONS ("start_time" = "2024-01-01 00:00:00", "end_time" = "2024-12-31 23:59:59");
Để tự động hóa, cần sử dụng cron job trên server Graph Service để gọi lệnh backup định kỳ (ví dụ mỗi ngày lúc 2 AM). Lưu ý: Lệnh backup cần chạy qua nGQL tool hoặc API. Ở đây giả định dùng script shell gọi nGQL.
sudo crontab -e
Thêm dòng sau vào crontab (thay đổi đường dẫn đến nebula-console hoặc nGQL client nếu cần).
0 2 * * * /home/nebula/bin/backup.sh large_data_space backup_daily_$(date +%F)
Verify: Kiểm tra xem backup đã được tạo chưa.
SHOW BACKUP;
Kết quả phải hiển thị task backup với trạng thái "FINISHED" hoặc "RUNNING". Kiểm tra thư mục backup trên disk.
ls -lh /data/nebula-data/backup
Thư mục phải chứa các file snapshot mới.
5. Đo lường hiệu năng với công cụ benchmark đơn giản
Bước 1: Sử dụng Nebula Graph Benchmark tool hoặc script nGQL đơn giản để đo Latency và Throughput.
Tại sao: Sau khi tối ưu, cần con số cụ thể để so sánh trước và sau khi điều chỉnh.
Kết quả mong đợi: Thời gian thực thi query giảm, số lượng query/giây tăng.
Tạo một script đơn giản để chèn dữ liệu và truy vấn. Giả sử file script benchmark.nGQL.
INSERT VERTEX player (name, age) VALUES ("p1", 20);
INSERT VERTEX player (name, age) VALUES ("p2", 21);
INSERT VERTEX player (name, age) VALUES ("p3", 22);
INSERT EDGE follows (rank) VALUES ("p1", "p2", 1), ("p2", "p3", 1);
MATCH (p:player)-[f:follows]->(p2:player) RETURN p.name, p2.name;
Chạy script này nhiều lần để đo tốc độ. Sử dụng lệnh time của shell để bao quanh lệnh chạy nGQL.
time nebula-console -u root -p nebula123 -n 127.0.0.1:9669 -f benchmark.nGQL
Để benchmark chuyên sâu hơn, sử dụng tool Nebula Graph Benchmark (nGQL Benchmark) nếu đã cài đặt.
cd /opt/nebula-graph-benchmark
./ngb -c config.json
Trong đó config.json chứa cấu hình số lượng node, thread, và loại query.
{
"host": "127.0.0.1",
"port": 9669,
"username": "root",
"password": "nebula123",
"space": "large_data_space",
"concurrency": 50,
"duration": "1m",
"query_type": "read"
}
Verify: Quan sát kết quả in ra màn hình.
Kết quả hiển thị các chỉ số:
- QPS (Queries Per Second): Số query xử lý mỗi giây.
- Latency (P50, P99): Thời gian phản hồi trung bình và 99%.
So sánh giá trị QPS hiện tại với giá trị trước khi tối ưu (phần 1-4). Nếu QPS tăng và Latency giảm, việc tối ưu thành công.
Điều hướng series:
Mục lục: Series: Triển khai Database Graph phân tán với Nebula Graph trên Ubuntu 24.04
« Phần 4: Cấu hình quản trị và kết nối qua Nebula Console và nGQL
Phần 6: Xử lý sự cố, giám sát và nâng cao kiến thức »