Cấu hình Replication tự động trên nhiều Region
Turso sử dụng mô hình Multi-Region Replication tự động. Bạn không cần cấu hình file replication thủ công như MySQL hay PostgreSQL truyền thống. Việc này được quản lý qua CLI để xác định nơi lưu trữ dữ liệu (Region) và chính sách sao chép (Replication Policy).
Để kích hoạt sao chép dữ liệu từ Region chính (Primary) sang các Region phụ (Secondary) nhằm giảm độ trễ (latency) cho người dùng toàn cầu, ta thực hiện lệnh sau:
turso db show --region us-central
Kết quả mong đợi: Hiển thị thông tin database hiện tại đang nằm ở region us-central.
Tiếp theo, ta thêm các region khác vào database để Turso tự động sao chép dữ liệu. Lệnh này sẽ tạo một bản sao (replica) tại region eu-west:
turso db add-replica eu-west
Kết quả mong đợi: Thông báo "Replica created successfully" và thời gian ước tính để đồng bộ dữ liệu ban đầu.
Để thêm thêm một region ở châu Á (ví dụ: ap-southeast) để đảm bảo độ trễ thấp cho người dùng khu vực này:
turso db add-replica ap-southeast
Kết quả mong đợi: Database đã có 3 region (us-central, eu-west, ap-southeast). Dữ liệu sẽ được tự động đồng bộ qua mạng nội bộ của Turso.
Verify kết quả bằng cách liệt kê tất cả các replica đang hoạt động:
turso db show
Kết quả mong đợi: Đầu ra hiển thị danh sách các region với trạng thái "Healthy" hoặc "Syncing".
Sử dụng Local Branch để phát triển Offline và đồng bộ
Trong môi trường serverless, việc phát triển offline hoặc test tính năng mới mà không ảnh hưởng đến dữ liệu production là cực kỳ quan trọng. Turso hỗ trợ Local Branch thông qua Local LibSQL, cho phép bạn làm việc với database trên file SQLite local và đồng bộ (push/pull) khi có mạng.
Trước tiên, tạo một branch mới từ branch chính (main) để phát triển tính năng:
turso db branch create feature-offline-test
Kết quả mong đợi: Thông báo "Branch created" kèm theo đường dẫn hoặc ID của branch mới.
Tạo một thư mục làm việc cho local development và khởi tạo local database từ branch vừa tạo:
mkdir -p ~/turso-dev && cd ~/turso-dev && turso db clone feature-offline-test --branch feature-offline-test
Kết quả mong đợi: File database local (thường là .db file) được tạo ra trong thư mục ~/turso-dev chứa toàn bộ dữ liệu từ branch feature-offline-test.
Thực hiện các thay đổi trên local database (ví dụ: tạo bảng mới hoặc chèn dữ liệu) bằng sqlite3:
sqlite3 feature-offline-test.db "CREATE TABLE local_dev_test (id INTEGER PRIMARY KEY, message TEXT); INSERT INTO local_dev_test VALUES (1, 'Offline data');"
Kết quả mong đợi: Dữ liệu được ghi vào file local, không ảnh hưởng đến database trên cloud.
Khi sẵn sàng đồng bộ dữ liệu local lên cloud (push), thực hiện lệnh:
turso db branch push feature-offline-test --branch feature-offline-test
Kết quả mong đợi: Turso sẽ so sánh local và remote, sau đó áp dụng các thay đổi (conflict resolution nếu có). Thông báo "Push successful" sẽ xuất hiện.
Verify kết quả bằng cách truy vấn trực tiếp vào branch đó trên cloud:
turso db execute "SELECT * FROM local_dev_test" --branch feature-offline-test
Kết quả mong đợi: Trả về hàng dữ liệu "Offline data" đã được đẩy từ local lên.
Tối ưu hóa truy vấn phức tạp với Explain Query Plan
Việc tối ưu hóa hiệu năng trong môi trường serverless dựa vào việc giảm chi phí tính toán (compute cost) và thời gian thực thi. Công cụ mạnh nhất để phân tích là EXPLAIN QUERY PLAN. Nó cho phép bạn nhìn thấy cách SQLite thực thi truy vấn (Full Table Scan, Index Scan, etc.).
Tạo một bảng mẫu lớn với dữ liệu giả lập để thực hiện test hiệu năng:
turso db execute "CREATE TABLE IF NOT EXISTS logs (id INTEGER PRIMARY KEY, user_id INTEGER, action TEXT, timestamp DATETIME);"
Chèn dữ liệu mẫu (10.000 dòng) để có dữ liệu đủ lớn cho việc phân tích:
for i in $(seq 1 10000); do turso db execute "INSERT INTO logs (user_id, action, timestamp) VALUES ($RANDOM, 'login', datetime('now'));"; done
Kết quả mong đợi: Database có 10.000 dòng dữ liệu trong bảng logs.
Thực hiện truy vấn tìm kiếm không có index (Full Table Scan) và xem kế hoạch thực thi:
turso db execute "EXPLAIN QUERY PLAN SELECT * FROM logs WHERE user_id = 123;"
Kết quả mong đợi: Đầu ra hiện "SCAN logs". Điều này nghĩa là SQLite phải quét toàn bộ 10.000 dòng, rất chậm và tốn tài nguyên.
Tối ưu hóa bằng cách tạo Index cho cột thường dùng trong điều kiện WHERE:
turso db execute "CREATE INDEX IF NOT EXISTS idx_logs_user_id ON logs(user_id);"
Kết quả mong đợi: Thông báo "Index created".
Chạy lại EXPLAIN QUERY PLAN để xác nhận SQLite đã chuyển sang dùng Index:
turso db execute "EXPLAIN QUERY PLAN SELECT * FROM logs WHERE user_id = 123;"
Kết quả mong đợi: Đầu ra thay đổi thành "SEARCH logs USING INDEX idx_logs_user_id". Điều này chứng tỏ truy vấn đã được tối ưu.
Verify hiệu năng thực tế bằng cách đo thời gian thực thi (sử dụng thời gian thực hiện của lệnh):
time turso db execute "SELECT * FROM logs WHERE user_id = 123;"
Kết quả mong đợi: Thời gian thực thi (real time) giảm đáng kể so với khi chưa có index (thường giảm từ vài trăm ms xuống vài ms).
Đánh giá hiệu năng Đọc/Ghi trong môi trường Serverless
Môi trường serverless của Turso (dựa trên Cloudflare Workers và LibSQL) có đặc thù riêng: Đọc (Read) có thể được phân tán đến edge node gần nhất, trong khi Ghi (Write) thường phải về Primary Region để đảm bảo tính nhất quán (Consistency). Việc đánh giá hiệu năng cần tập trung vào độ trễ (Latency) và thông lượng (Throughput).
Thiết lập một kịch bản benchmark đơn giản để đo thời gian phản hồi (Response Time) cho các thao tác Đọc và Ghi từ các Region khác nhau.
Đo lường hiệu năng Đọc (Read Latency) từ Region hiện tại (ví dụ: us-central) so với Region xa (eu-west):
time turso db execute "SELECT COUNT(*) FROM logs;" --region us-central
Kết quả mong đợi: Thời gian thực thi nhanh (thường dưới 50ms nếu local network).
Chạy lại lệnh tương tự nhưng chỉ định region xa để thấy sự khác biệt về độ trễ mạng:
time turso db execute "SELECT COUNT(*) FROM logs;" --region eu-west
Kết quả mong đợi: Thời gian thực thi tăng lên (có thể 100-200ms tùy vị trí mạng của bạn) do phải chuyển tiếp qua mạng đến region eu-west, nhưng vẫn nhanh hơn nhiều so với database truyền thống ở xa.
Đo lường hiệu năng Ghi (Write Latency) - Thao tác này luôn về Primary Region:
time turso db execute "INSERT INTO logs (user_id, action, timestamp) VALUES (999, 'benchmark_write', datetime('now'));" --region eu-west
Kết quả mong đợi: Thời gian thực thi bao gồm thời gian mạng để đi từ client đến eu-west rồi quay về primary (us-central) để commit transaction, sau đó quay lại client. Tổng thời gian thường cao hơn Read.
Để đánh giá khả năng chịu tải (Throughput), thực hiện một vòng lặp ghi nhanh:
time (for i in $(seq 1 50); do turso db execute "INSERT INTO logs (user_id, action, timestamp) VALUES ($i, 'load_test', datetime('now'));"; done)
Kết quả mong đợi: Tổng thời gian thực hiện 50 lệnh INSERT. Bạn có thể tính toán TPS (Transactions Per Second) bằng cách chia 50 cho tổng thời gian (giây). Giá trị này giúp bạn xác định giới hạn rate limit của plan hiện tại.
Verify kết quả cuối cùng bằng cách kiểm tra tổng số dòng trong bảng để đảm bảo không có dữ liệu bị mất do lỗi mạng hoặc rate limit:
turso db execute "SELECT COUNT(*) FROM logs;"
Kết quả mong đợi: Số lượng dòng tăng lên đúng bằng 10.000 (ban đầu) + 50 (benchmark) = 10.050 dòng.
Điều hướng series:
Mục lục: Series: Triển khai Database Serverless với Turso và SQLite trên Ubuntu 24.04
« Phần 5: Kết nối ứng dụng với Turso qua SDK và LibSQL
Phần 7: Xử lý sự cố, bảo mật và tips nâng cao »