SpacetimeDB ölçekleme hikâyesini ortaya koyuyor: yatay depolama 31 Ekim'de geliyor

Ölçeğin üç bağımsız ekseni

Yazı önce dikey ölçekleme — daha büyük tek bir makineden daha fazla performans almak — ile makine sayısını ikiye çıkarmanın işi kabaca ikiye katladığı yatay ölçeklemeyi birbirinden ayırıyor. Yazar, ölçeklenebilirlik sorusunu soranların çoğunun yatay olanı kastettiğine dikkat çekiyor; çünkü tek bir bilgisayarın sert sınırları varken makineler ilke olarak sınırsız eklenebilir. Ancak evet-hayır cevabı konuyu kaçırıyor, çünkü ölçeklenebilirlik büyük ölçüde bağımsız üç boyuta ayrılıyor: bir sistemin kaç transaction işleyebildiğini ifade eden compute; ne kadar veri tutabildiğini ifade eden storage; ve kaç bağlantı ile ne kadar bant genişliğini sürdürebildiğini ifade eden networking. Bir veritabanı bir eksende ölçeklenip diğerlerinde başarısız olabilir ve yazı, çok farklı mimarilere sahip üç PostgreSQL-uyumlu sistemle bunu gösteriyor.

Karşılaştırılan Postgres, Neon ve CockroachDB

Yazıya göre Postgres temelde tek düğümlü bir sistem: birincil (primary) sunuculardan oluşan bir cluster kavramı yok, sunucular arası transaction çalıştıramıyor ve yalnızca elle replica kurarsanız okumaları ölçekleyebiliyor — ki bunlar read-after-write tutarlılığı uyarılarıyla geliyor. Değiştirilmiş bir Postgres türevi olan Neon, tabloların arkasına yerel bir page cache ile object storage koyarak depolamayı yatay ölçekliyor; böylece küçük uygulamalar bile çok büyük veri kümeleri biriktirebiliyor — ancak cache ıskalamaları gecikmeye mal oluyor ve tüm yazılar yine tek bir primary üzerinden geçiyor. Yazarın Spanner ve Aurora DSQL gibi genel amaçlı dağıtık ilişkisel sistemlerin temsilcisi olarak ele aldığı ve defalarca olağanüstü bir mühendislik başarısı olarak övdüğü CockroachDB ise her tabloyu cluster'a yayılan range'lere bölüyor ve her range tipik olarak iki ek makineye kopyalanıyor. Mimari simetrik — her düğüm herhangi bir SQL isteğini, okuma ya da yazma, işleyebiliyor — ve analitik veya ilgisiz anahtarlara yapılan yazılar gibi düzgün şekilde paralelleşen hesaplamayı iyi ölçekliyor.

Koordinasyonun bedeli

Argümanın özü şu: hiçbir sistem paralel hesaplamanın sınırlarından kaçamıyor. Transaction'lar aynı veri için çekiştiğinde, kaç makineniz olursa olsun güncellemeler tek tek yapılır; ama CockroachDB tarzı bir tasarım her transaction'a dağıtık koordinasyonun tam bedelini ödetir. Yazı bunu çarpıcı bir örnekle illustrating ediyor: tek bir makinenin bir milisaniyede bitirdiği iş, koordinasyon devreye girdiğinde on makinede yüz milisaniye sürebiliyor. İki yapısal sorun tanımlanıyor. Birincisi, veri sahipliği cluster'a eşit dağıtıldığı için bir transaction'ın dokunduğu satırlar nadiren aynı yerde bulunur; dolayısıyla neredeyse her transaction ağ gidiş-dönüşleri öder. İkincisi, hiçbir transaction bir range'e özel erişim elde edemez; bu yüzden tüm transaction'lar dağıtık eşzamanlılık kontrolü yükünü taşırken çakışanlar beklemek, iptal olmak veya yeniden denemek zorunda kalır. Yazı, ilgili tabloları aynı yerde tutan Spanner'ın table interleaving özelliğinin ilk sorunu kısmen hafiflettiğine dikkat çekiyor.

Spacetime'ın taahhüt ettikleri

Spacetime'ın kendi yol haritası için yazının özeti somut bir tarih veriyor: yatay ölçeklenen depolama 31 Ekim 2026'da geliyor — yazarın göreli olarak kolay kısım dediği şey. Buna karşılık compute ve networking genel durumda tamamen yatay ölçeklenemiyor. Şirketin öne sürdüğü iddia şu: Spacetime, yazının genel amaçlı dağıtık OLTP veritabanlarının kötüleştiğini iddia ettiği noktada, yani çekişme altında bile yüksek performansı korurken, geliştiricilere gerçekten paralelleşen OLTP iş yüklerini ölçekleme araçları sunuyor.

Neden önemli

Ölçekleme, yeni bir veritabanına karşı verilen refleks itirazdır ve bu yazı, ikili bir cevabı yerine mimarların herhangi bir sisteme — rakipler dâhil — uygulayabileceği bir çerçeve koyuyor: compute, storage, networking. Çekişme eleştirisi ayrıca tek bir primary ile dağıtık SQL arasında seçim yapan ekipler için pratik bir değerlendirme: koordinasyon maliyetleri her transaction'a ödetilir, zaten sıralanacak olanlar dâhil. Son olarak, 31 Ekim depolama tarihi mimari bir tartışmayı doğrulanabilir bir kilometre taşına dönüştürüyor. Spacetime'ın performansının gerçekten çekişmeli iş yükleri altında tutup tutmadığı, başlıktaki soruya nihai cevabı verecek olan şey.