Tin tức

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 đó.

September 10, 2026· 4 min read
Neki của PlanetScale mang sharding đến với Postgres thực thụ

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.
Ban biên tập Manul X
Các thành phần của Neki và vai trò của từng thành phần
So sánh nhanh
Thành phầnVai tròMô hình mở rộng
Neki routerPhâ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 PostgresChiều dọc và chiều ngang
ShardCụm Postgres đầy đủ: 1 primary, ít nhất 2 replica trải trên 3 AZThêm shard
Shard groupNhó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àiTheo instance
Control planeTheo 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