Neki của PlanetScale mang sharding đến với Postgres thực thụ
Neki đặt một router giao thức Postgres phía trước các shard vốn chỉ là Postgres thuần, nên driver và ORM của bạn vẫn hoạt động. Nó đang ở giai đoạn platform preview, và PlanetScale nói đừng chạy production trên đó.

PlanetScale đã ra mắt Neki ở dạng platform preview: Postgres phân mảnh (sharded) trong đó mỗi shard là một cụm Postgres không chỉnh sửa. Lời chào hàng hẹp và cụ thể — bạn giữ nguyên ngữ nghĩa Postgres thực, các extension, và hành vi SQL, rồi mở rộng theo chiều ngang bằng cách thêm shard thay vì mua một cỗ máy to hơn.
Công ty định vị nó như câu trả lời cho một vấn đề họ liên tục gặp với khách hàng PlanetScale Postgres: các đội hết dư địa trên một máy, và mọi lối thoát hiện có đều phải trả giá. Sharding ở tầng ứng dụng đẩy logic định tuyến vào code của bạn. Các cơ sở dữ liệu phân tán tương thích Postgres thì giấu shard key, bỏ hỗ trợ extension, và thêm độ trễ khó debug. Đặt cược của Neki là một router nói giao thức Postgres sẽ giúp bạn tránh cả hai.
Kiến trúc: bốn thành phần chuyển động
Ứng dụng của bạn kết nối tới một Neki router qua giao thức Postgres chuẩn bằng một connection string duy nhất. Router mang theo một parser truy vấn Postgres đầy đủ và một query planner phân tán: nó phân tích truy vấn, quyết định shard nào sẽ thực thi, điều phối công việc, và hợp nhất kết quả thành một luồng. Router mở rộng theo chiều dọc và chiều ngang, nên bản thân tầng router không được thiết kế để làm nút thắt cố định.
Phía sau router, các shard là những cụm Postgres đầy đủ — một primary và ít nhất hai replica trải trên ba vùng sẵn sàng (availability zone). Không có storage engine tùy chỉnh. Các shard được nhóm thành shard group, cho phép các bảng hoặc workload khác nhau nằm trên các tập shard riêng, mỗi tập có profile cấu hình riêng bao gồm kích thước instance, số replica, storage, tham số Postgres, và extension.
Connection pooling chạy dưới dạng sidecar bên cạnh mỗi instance Postgres. Đây là phần PlanetScale khẳng định tốt hơn đáng kể so với việc dựng PgBouncer trước một database: vì Neki nắm cả hai đầu kết nối, nó có thể định cỡ pool theo những gì một instance thực sự phục vụ được thay vì ước lượng từ bên ngoài tiến trình.
Control plane theo dõi sức khỏe node, chạy switchover có kế hoạch và failover ngoài kế hoạch, và điều phối các workflow cho resharding, thay đổi schema, và nâng cấp phiên bản. Gắn kết tất cả là data topology, một cấu hình JSON ánh xạ các bảng logic lên các shard vật lý. Bạn định nghĩa shard index — cột mà Neki định tuyến dựa trên đó và cách nó băm giá trị — cùng các shard group kiểm soát số shard mà một tập bảng trải rộng. Các router cache topology và tham chiếu nó trong mỗi lần lập kế hoạch.
Vận hành trực tuyến, và lối vào chưa shard
Những công việc thường đồng nghĩa với một cửa sổ bảo trì giờ chạy như workflow tích hợp sẵn: cấp phát node đích, bắt kịp qua replication, chuyển traffic qua một metafunction __neki, và ngừng các node cũ — tất cả trên chính kết nối psql mà ứng dụng của bạn dùng. Mô hình đó bao trùm thay đổi schema, nâng cấp phiên bản, failover, import, và resharding.
Bạn không cần phải shard ngay từ ngày đầu. Neki chạy như một primary đơn với các replica, cho bạn pooling cải thiện, DDL trực tuyến, nâng cấp không downtime, và giám sát sức khỏe ngay từ đầu. Resharding sau này là một workflow trên chính cụm bạn đã có. Các tính năng PlanetScale như Insights, gợi ý schema, branching, và MCP đi kèm.
Lưu ý về bản preview
Đây là platform preview, và PlanetScale nói rõ: đừng chạy workload production trên đó. Sản phẩm vẫn đang thay đổi, và một số thay đổi sẽ gây phá vỡ (breaking). Phản hồi đi qua support ticket hoặc Discord của họ.
Toàn bộ đặt cược của Neki là bạn không nên phải chọn giữa mở rộng theo chiều ngang và Postgres thực thụ. Nhãn preview là phần cần coi trọng.
| Thành phần | Vai trò | Mô hình mở rộng |
|---|---|---|
| Neki router | Phân tích truy vấn, lập kế hoạch trên các shard, hợp nhất kết quả; nói giao thức Postgres | Chiều dọc và chiều ngang |
| Shard | Cụm Postgres đầy đủ: 1 primary, ít nhất 2 replica trải trên 3 AZ | Thêm shard |
| Shard group | Nhóm các bảng/workload vào tập shard riêng với profile cấu hình theo nhóm | Định cỡ theo nhóm |
| Connection pooling sidecar | Định cỡ pool từ bên trong mỗi instance Postgres thay vì ước lượng từ bên ngoài | Theo instance |
| Control plane | Theo dõi sức khỏe, switchover, failover, workflow resharding và nâng cấp | Được quản lý |
| Data topology | Ánh xạ JSON từ bảng logic sang shard vật lý và shard index | Được router cache |
Thảo luận
0 bình luận
Hãy là người đầu tiên thảo luận.