Perplexity DynamoDB'yi bıraktı: Rust ile yazılmış kendi veritabanı CobbleDB

Ne değişti?

Perplexity bir soruya cevap verirken önce ilgili web sayfalarını seçiyor. Sonra bu sayfaların önceden hazırlanmış parçalarını ve vektörlerini veritabanından topluca çekip modele veriyor.

Şirketin 14 Eylül tarihli yazısına göre tek bir Search API isteği 100–120 sayfa anahtarı içeriyor. Bunlar 10–20’lik gruplar hâlinde okunuyor ve her kayıt ortalama 50 KB. Bu verinin tutulduğu yer, Amazon’un yönetilen veritabanı DynamoDB idi. Artık yerini kendi yazdıkları CobbleDB aldı.

DynamoDB neden yetmedi?

Perplexity üç sorun sayıyor:

• Fatura. DynamoDB okunan ve yazılan her bayt için ücret alıyor. İndeks büyüdükçe ve sorgu arttıkça fatura da büyüdü.
• Kontrol yok. Hangi verinin hangi makinede durduğuna, önbelleğe ne kadar bellek ayrıldığına ya da isteğe hangi kopyanın (replica) cevap verdiğine karar veremiyorlardı.
• Sıkı bağlılık. Sayfaları işleyen hat doğrudan veritabanına yazıyordu. Büyük bir yeniden işleme, canlı okumalarla yarışıyordu.

Uç gecikme: En yavaş halka

İkinci madde neden bu kadar önemli? Çünkü toplu okumada cevap, en yavaş parça gelince tamamlanıyor. 20 anahtardan 19’u hemen gelse bile, biri yavaş bir makinede takılırsa bütün istek bekliyor.

Bu yüzden ortalama değil, p99 gibi ölçülere bakılır. p99, isteklerin %99’unun altında kaldığı süre. Yani en kötü %1’lik dilim. Çok sayıda parçayı bir araya toplayan sistemlerde bu kötü dilim, sandığından çok daha sık karşına çıkar.

CobbleDB nasıl çözüyor?

CobbleDB genel amaçlı bir veritabanı değil. Tek bir işe odaklanıyor: “Bu sayfa kimliklerini bana hızlıca ver.”

• Veri bölümlere (partition) ayrılıyor. Her bölümün üç farklı makinede üç kopyası var.
• Her makine veriyi açık kaynak RocksDB motoruyla saklıyor. Önbellekteki veri doğrudan bellekten, gerisi hızlı NVMe disklerden okunuyor.
• Anahtarlar bölümlerine göre gruplanıp paralel okunuyor.
• Bir makine yavaş cevap verirse, aynı okuma başka bir makinedeki kopyaya da gönderilebiliyor. Buna hedged request (sigortalı istek) deniyor. Google’ın uç gecikme üzerine bilinen makalesinde anlatılan bu teknikte, hangi kopya önce cevap verirse o kullanılır.
• İhtiyaç duymadıkları özellikleri bilerek atmışlar: İşlem (transaction) desteği yok. Bir kaydın yazılmasıyla okunabilmesi arasında kısa bir gecikme kabul edilebilir.

Sonuçlar

Perplexity’nin paylaştığı canlı ortam ölçümleri:

• Medyan toplu okuma: 31,4 ms → 5,6 ms
• p99: 123 ms → 24,2 ms
• Kendi maliyet modellerine göre her taahhüt seviyesinde DynamoDB’den en az %20 ucuz.

Şirket dürüst bir not da düşüyor: Bu, aynı istekler üzerinde kontrollü bir deney değil, farklı zamanlardaki canlı trafiğin önce–sonra karşılaştırması. Bu yüzden ayrıca sentetik testler de yapmışlar.

Ajanların payı

CobbleDB’nin çekirdeği yaklaşık 40 bin satır Rust. Perplexity’ye göre iki mühendis ve yüzlerce yapay zekâ ajanı bunu iki ayda kurdu. Ajanlar kod incelemesi yaptı, düzeltmeler, testler, izleme ayarları ve dokümantasyon hazırladı, CI ve inceleme adımlarını takip etti. Mimariyi mühendisler belirledi, önemli değişiklikleri onlar inceledi ve canlı ortamdaki her işlemi onlar onayladı.

Perplexity, yapay zekâ ajanlarının “satın al mı, kendin yap mı?” hesabını kendin yapmaktan yana kaydırdığını söylüyor. Ama unutma: DynamoDB’nin asıl sunduğu şey, dağıtık bir veritabanını işletme yükünü üstlenmesiydi. O yük şimdi Perplexity’de. CobbleDB’yi yakında açık kaynak yapmayı planlıyorlar.

Düşün

• Kullandığın bir hazır servisin hangi özelliğine aslında hiç ihtiyacın yok?
• Bir isteği iki yere birden göndermek hızı artırırken neyi artırır?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.