PlanetScale'in Neki'si 512 Postgres shard üzerinde saniyede 118 milyon sorguya ulaştı

Neki saniyede 118,5 milyon sorguyu sürdürüyor

PlanetScale, yazının yayınlandığı günün bir öncesinde platform preview olarak yayınladığı dağıtık veritabanı platformu Neki için benchmark sonuçlarını paylaştı ve 1,22 PiB veri barındıran 512 shard üzerinde saniyede 118.538.803 sorgunun sürdürüldüğünü bildirdi. Hacker News ana sayfasına çıkan şirket blog yazısına göre test 16 dakika sürdü ve en yüksek tek ölçüm 118.747.267 QPS olarak kaydedildi.

Başlangıçtaki hedef çok daha küçüktü. PlanetScale'e göre ekip, Neki'nin saniyede 1 milyon sorguyu kaldırıp kaldıramayacağını görmek için yola çıktı, bu hedefi yalnızca beş shard ile aştı ve ardından tavanın nerede olduğunu bulmak için kapasite eklemeye devam etti.

Benchmark nasıl yapıldı

İş yükü bilinçli olarak basitti: primary key üzerinden sorgu başına tek satır getiren tek shard'lık point select'ler. Yazma, join veya birden fazla shard'a yayılan sorgu yoktu ve her shard izole bir iş akışı aldı.

Metodoloji, shard başına 200.000 QPS hedeflemek ve sonra kümeyi büyütmekti — önce beş shard'a, sonra ellisine, ardından 512'ye. Yazıya göre shard başına verimi, sırasıyla yaklaşık 1 milyon ve 10 milyon QPS veren beş shard'lık ve elli shard'lık çalışmalar arasında yüzde 0,8'in altında bir sapmayla sabit kaldı. 512 shard'da node'ların hâlâ fazla kapasitesi vardı; ekip yük üretecinin bunu kullanmasına izin verdi ve her shard 200.000 hedefi yerine yaklaşık 231.000 QPS'ye yerleşti.

PlanetScale'in listediği zirve koşusunun arkasındaki yapılandırma:

• Her biri r8g.16xlarge instance üzerinde tek bir Postgres primary olan 512 shard
• Her biri kendi 8xlarge instance'ında çalışan 480 Neki router'ı
• Router'da 6,06 ms, istemcide 13,95 ms p99 gecikme
• Saniyede 67 hata, yaklaşık 1,8 milyon sorguda bir
• Fleet genelinde 15,8 milyon okuma IOPS
• Saniyede 2 Tb'ı aşan ağ trafiği

Rakamlar neyi kanıtlıyor, neyi kanıtlamıyor

PlanetScale, bunun bir üretim simülasyonu değil, en iyi senaryodaki okuma benchmark'ı olduğunu açıkça söylüyor. Shard'lar kopyasız olarak yalnızca primary üzerinde çalıştı, iş yükü salt okunurdu ve ölçüm penceresi sırasında hiç failover yaşanmadı. Join'i veya shard'lar arası koordinasyonu olmayan, primary key ile point-select iş yükü, shard'lı bir sistemin yürütebileceği en kolay işlerden birine yakın; dolayısıyla bu rakam, karma iş yükü davranışının bir öngörüsü olarak değil, yatay okuma ölçeklemenin bir tavanı olarak okunmalı.

Şirket, bir devam yazısının 100 milyon QPS'yi aşmanın mühendislik çabasını ve beraberindeki zorlukları ele alacağını söylüyor.

Neden önemli

Manşet rakamından daha ilgi çekici olan, altındaki ölçekleme eğrisi. Beşten 50'ye, oradan 512 shard'a çıkılırken shard başına verim neredeyse hiç kıpırdamadı; bu da bu alandaki üreticilerin göstermek istediği en önemli özellik: küme büyüdükçe yönlendirme katmanının darboğaza dönüşmemesi. Router'da 6 ms p99'u tutarken saniyede 2 Tb'dan fazla veri taşımak, 480 router'lık katmanın fleet ile ayak uydurduğunu gösteriyor.

Bu koşu ayrıca, her shard'ın önünde bir Postgres primary bulunan Neki'nin Postgres tabanlı mimarisini doğruluyor — en çok MySQL uyumlu Vitess geçmişiyle tanınan bir şirket için dikkat çekici bir veri noktası.

Herhangi bir üretici tarafından yürütülen benchmark'ta olduğu gibi bu rakamlar da kendi tarafından raporlanmış ve seçilen iş yüküyle şekillenmiş durumda; bu yüzden diğer sistemlerle karşılaştırmalar dikkatle yapılmalı. Yine de, bir platform preview yayınlanmasından bir gün içinde 1,22 PiB üzerinde 118 milyon QPS'yi sürdürmek, dağıtık veritabanı pazarının geri kalanı için tartışılması gereken yüksek bir referans noktası oluşturuyor.