Ampbase yalnızca object storage üzerinde çalışıyor, eksik veritabanı özelliklerini kendisi inşa ediyor

Altında veritabanı olmayan bir control plane

Hacker News ana sayfasında şu anda yer alan Tigris Data blogundaki bir konuk yazısı, Ampbase'in control plane'ini tamamen object storage üzerinde nasıl çalıştırdığını anlatıyor. Ampbase kurucusu JP tarafından kaleme alınan yazı, şirketin kullanmamayı tercih ettiği veritabanı motorları hakkındaki önceki bir makalenin devamı niteliğinde: stack'te ilişkisel bir veritabanı yok, yalnızca Tigris var — ki o da dağıtık bir key-value store olan FoundationDB üzerine inşa edilmiş bir object storage servisi. Yazar türün farkında olarak, veritabanının gereksiz olduğunu ilan eden yazıların kötü yaşlandığına ve çoğu zaman Postgres'e utanarak yapılan bir göçün habercisi olduğuna dair şaka yapıyor.

İki katmanlı bucket yapısı

Her şey iki katmanda yaşıyor. Tek bir global directory bucket, organizasyonların listesini tutuyor; her organizasyon için anahtarlar şunları içeriyor: metadata, üyeler (email adresinin SHA-256 hash'i ile anahtarlanıyor ve index işlevi görüyor), faturalandırma durumu (compare-and-swap hedefi), kanal metadatası, API token'ları, denetim olayları ve bir operasyon kuyruğu. Her müşteriye ise kendi bucket'ı veriliyor; bu bucket kanal slug'ları (unique constraint), konfigürasyon ve bundle metadatası ile history table işlevi gören versiyonlanmış kayıtları, yerinde üzerine yazılan aktif konfigürasyon işaretçisini ve bir event stream'i içeriyor.

Kayıtlar başlangıçta JSON'dı ancak marshaling maliyetleri beklentileri aştığında Protocol Buffers'a geçildi; storage katmanı her iki formatı da işleyebildiği için eski JSON kayıtları hâlâ yükleniyor. Yazıya göre Protobuf, migration, bağlantı yönetimi ve şema yönetimi gibi bütün bir veritabanı iş kategorisini ortadan kaldırıyor; bedeli ise alan adlarının fiilen kalıcı olması — yazar bunu Postgres, MySQL veya SQLite'ta kolon yeniden adlandırmaya benzetiyor.

İzolasyon altyapının içine itildi. Müşteri başına prefix'ler ve karmaşık IAM politikaları içeren tek bir bucket yerine Ampbase, Tigris'in Partner Integration Program'ını kullanıyor: tek bir çağrı bir Tigris organizasyonu, bir bucket ve o müşteriye kapsamlı erişim anahtarları oluşturuyor. Bir müşterinin kimlik bilgileri başka birinin verisine erişemediği için uygulama kodunda unutulacak bir tenant filtresi yok — yazar bunu, platform geliştiricilerinin en sık yaptığı hata olarak gösteriyor.

İki primitifden veritabanı garantileri inşa etmek

Yazı bir veritabanı motorunu altı şeye bölüyor: güçlü read-after-write tutarlılığı, conditional write'lar, unique constraint'ler, transaction'lar, index'ler ve history table'lar. Tigris ilk ikisini hazır olarak sunuyor; Ampbase diğer dördünü kendisi uyguladı.

Güçlü tutarlılık object storage için görece yeni. Yazı, object store'ların Aralık 2020 civarına kadar güçlü bir tutarlılık modelinden yoksun olduğuna dikkat çekiyor ve iç mekaniğe dair Werner Vogels'ın bir yazısına işaret ediyor. Tigris'i ayıran özellik, yalnızca bucket adlarının değil bucket verilerinin de global olması. Okumalar bir bölge içinde güçlü tutarlılıkta, ancak global replikasyon bölgeler arası davranışı eventually consistent yapıyor; dolayısıyla güçlü tutarlılığın nerede gerçekten gerekli olduğuna karşı nerede eventual consistency'nin yeterli olduğuna karar vermek merkezi bir tasarım sorusu haline geliyor.

Conditional write'lar compare-and-swap anlamına geliyor. Tigris, write'larda HTTP precondition'larını destekliyor: If-None-Match: * yalnızca anahtar henüz yoksa başarılı oluyor, bir ETag taşıyan If-Match ise yalnızca nesne okunduğundan beri değişmediyse başarılı oluyor. Yazara göre compare-and-swap bir kez elinizde olduğunda, her veritabanı motorunun altında yatan çekirdek primitive'e sahip oluyorsunuz.

Unique constraint konusunda yazı, unique index'lerin arama hızından çok tekrarları önlemek için var olduğunu savunuyor — bir email kolonunu index'leme nedeniniz, onu iki kez depolamayı engellemek. Ampbase, content-aware storage'ı conditional write'larla birleştiriyor, böylece özdeş veri iki kez yazılamıyor. Yayınlanan metin açıklamanın ortasında kesiliyor, dolayısıyla transaction, index ve history uygulamalarının ayrıntılı mekaniği alıntının ötesinde sürüyor; yine de yukarıda tarif edilen storage düzeni her primitive'in hangi anahtarlara eşlendiğini şimdiden gösteriyor.

Neden önemli

Makale, veritabanlarının gerçekte ne yaptığının bir diseksiyonu olarak iş görüyor. Unique constraint'ler, transaction'lar, index'ler ve history table'lar çoğu ekibin düşünmeden tükettiği özelliklerdir; bunların conditional write'lardan ve tutarlılık garantilerinden yeniden inşa edilişini görmek, bir veritabanının size gerçekte ne sattığını ve bir olmadan ne zaman idare edilebileceğini netleştiriyor. Ayrıca fizibilite çıtasının kaymasını da gösteriyor: object storage yalnızca 2020 sonunda güçlü tutarlılık kazandı ve conditional write'lar artık aynı katmanda, S3 tarzı store'ları control plane ölçeğindeki iş yükleri için makul bir kalıcılık zemini haline getiriyor. İzolasyon tasarımı ise başlı başına aktarılabilir bir ders — kimlik bilgilerini altyapı düzeyinde müşteriye göre kapsamlandırmak, uygulama düzeyindeki filtrelemenin davet ettiği bir sınıf multi-tenant hatasını tamamen ortadan kaldırıyor.