PlanetScale, yüz milyonlarca QPS'ye ulaşmak için tasarlanmış sharded Postgres hizmeti Neki'yi duyurdu

Neki nedir

PlanetScale, tek bir mantıksal veritabanını birçok makineye yayarken her shard üzerinde değiştirilmemiş PostgreSQL çalıştıran sharded Postgres hizmeti Neki'yi duyurdu. Şirketin duyuru yazısına göre Neki, saniyede yüz milyonlarca sorguya ve petabaytlarca veriye ulaşmak için tasarlandı ve şu anda platform önizlemesinde erişilebilir durumda.

Temel vaat, her shard'ın gerçek bir Postgres olması: özel bir storage engine bulunmuyor, dolayısıyla extension'lar, SQL davranışı ve performans geliştiricilerin beklediği şekilde kalıyor. Uygulamalar standart Postgres wire protocol üzerinden bir Neki router'a bağlanıyor; böylece mevcut driver'lar, ORM'ler ve connection string'ler çalışmaya devam ediyor.

PlanetScale ürünü, geçmişinin bir uzantısı olarak konumlandırıyor. Şirket, sekiz yıldır dünyanın en büyük sharded MySQL kümelerinden bazılarını işlettiğini ve yaklaşık bir buçuk yıl önce PlanetScale Postgres'i piyasaya sürdüğünden bu yana binlerce müşteriye hizmet verdiğini, bazılarının en büyük MySQL kullanıcıları kadar büyük olduğunu belirtiyor. Yazıya göre bu ekipler sürekli olarak tek bir makinenin yapabileceği şeyin sınırına takılıyor ve iyi bir sonraki adımları yoktu.

Mimari nasıl çalışıyor

Neki'nin dört ana bileşeni ve bir yapılandırma katmanı var.

Router'lar filonun önünde yer alıyor. Her biri tam bir Postgres sorgu parser'ı ve dağıtık bir sorgu planner'ı içeriyor: bir sorguyu ayrıştırıyor, hangi shard'ların bunu çalıştıracağına karar veriyor, işi dağıtıyor ve sonuçları tek bir akışta birleştiriyor. Router'lar dikey ve yatay olarak ölçekleniyor, böylece tek bir router darboğaz haline gelmiyor.

Her shard, üç availability zone'a yayılmış bir primary ve en az iki replica içeren tam bir Postgres kümesi. Shard'lar shard grupları halinde organize edilmiş durumda; bu sayede farklı tablolar veya iş yükleri ayrı donanım profillerinde çalışabiliyor, instance boyutu, replica sayısı, storage, Postgres parametreleri ve extension'lar grup bazında ayarlanabiliyor.

Sidecar'lar her Postgres instance'ının yanında çalışıyor ve connection pooling'i yönetiyor. PlanetScale'e göre bu, PgBouncer'ı veritabanının önüne koymaktan daha iyi, çünkü Neki her bağlantının her iki ucunu da kontrol ediyor ve havuzları bir instance'ın gerçekten sunabileceği boyuta göre, işlem dışından tahmin etmek yerine, ölçekleyebiliyor.

Bir control plane node sağlık durumunu takip ediyor, planlı ve plansız failover'ları yürütüyor ve operasyonel iş akışlarını koordine ediyor. Bunların tümünü bağlayan şey, mantıksal tabloları fiziksel shard'lara eşleyen bir JSON veri topolojisi: shard index'leri Neki'nin hangi kolon üzerinde route yaptığını ve değerlerin nasıl hash'lendiğini tanımlıyor, router'lar ise topolojiyi önbelleğe alıyor ve her sorgu planı için ona danışıyor.

Bakım pencereleri yerine online operasyonlar

Normalde bakım penceresi olarak planlanacak her şey yerleşik bir iş akışı olarak çalışıyor: şema değişiklikleri, Postgres sürüm yükseltmeleri, failover'lar, import'lar ve resharding. Her iş akışı yeni hedef node'ları hazırlıyor, replikasyonla bunları güncelliyor, trafiği bir __neki metafonksiyonu kullanarak geçiriyor ve eski node'ları emekliye ayırıyor; hepsi uygulamanın zaten kullandığı bağlantı üzerinden.

Cross-shard yazmalar koordine edildiği için commit'ler atomik: ya her shard bir transaction'ı uygular ya da hiçbiri uygulamaz. Her shard kendi write-ahead log'unu ve logical replication yolunu tutuyor, böylece change data capture standart Postgres desenleriyle uyumlu kalıyor. Mevcut bir veritabanı, veri kopyalanarak, devam eden değişiklikler replike edilerek, doğrulama yapılıp kaynak trafiğe hizmet vermeye devam ederken geçiş yapılarak içe aktarılabiliyor. Neki ayrıca replica'lı tek bir primary olarak shard'sız da çalışabiliyor; böylece ekipler önce pooling ve online operasyonları benimseyebilir, resharding'i daha sonra aynı kümeye karşı bir iş akışı olarak tetikleyebilir.

PlanetScale'in mevcut özellikleri olan Insights, şema önerileri, branching ve MCP de taşınıyor.

Platform önizlemesi uyarıları

Şirket, Neki'nin henüz üretime hazır olmadığını açıkça belirtiyor. Yazı, ürünün hâlâ değiştiğini ve bu değişikliklerden bazılarının kırıcı olacağını duyuruyor ve destek talepleri veya Discord üzerinden geri bildirim istiyor. Erişim, PlanetScale dashboard üzerinden opting in gerektiriyor.

Neden önemli

Neki'nin hedeflediği ölçekleme sorunları, hızla büyüyen bir Postgres dağıtımı çalıştıran herkese tanıdık: trafiği etkilemeden vacuum veya index yapılamayacak kadar büyük tablolar, saatler süren yedeklemeler, bağlantı limitleri, şema değişiklikleri için bakım pencereleri ve transaction wraparound. Daha büyük instance'lar sorunu sadece erteliyor ve PlanetScale'in belirttiği gibi, performans çekirdek ve IOPS eklendikçe doğrusal ölçeklenmiyor.

Mevcut alternatiflerin her biri bir taviz gerektiriyor. Uygulama seviyesinde sharding, yönlendirmeyi uygulama koduna taşıyor; Postgres uyumlu dağıtık veritabanları ise genellikle shard key'i gizliyor, extension desteğini kaldırıyor ve debug edilmesi zor bir gecikme ekliyor. Neki'nin bahsi, açık shard key'ler, her node'da gerçek Postgres ve online operasyonel iş akışlarının üçüncü bir yol sunması ve PlanetScale'in MySQL dönemi sharding deneyimini giderek rekabetçi hale gelen dağıtık Postgres alanına taşıması. Ancak önizlemden çıkana kadar, üretimde benimsenmesi bir bekle-gör sorusu olmaya devam ediyor.