ExtendDB: DynamoDB API'sini Kendi Veritabanınızda Çalıştırın

Diyelim ki bir hastane kayıt sisteminin bina içinde kalması gerekiyor — hasta verisi şirket içi ağdan asla çıkamıyor, her bağımlılığı bir denetçi onaylıyor ve geliştirici dizüstülerinin hiç internet erişimi yok. Ekip uygulamayı zaten DynamoDB API'sine karşı yazmış ve bundan memnun: tek haneli milisaniyelik anahtar aramaları, temiz bir öğe modeli, dadılık edilecek şema göçü yok. Ama yönetilen DynamoDB bir bulut servisidir ve burada "veriyi AWS'ye gönder" baştan elenir.

ExtendDB tam olarak bu boşluk için yapıldı. DynamoDB hat protokolünü konuşur, ama veriyi sizin çalıştırdığınız bir veritabanında saklar.

ExtendDB nedir?

ExtendDB, AWS'nin açık kaynaklı adaptörüdür (Rust ile yazılmıştır) ve DynamoDB JSON hat protokolünü, PostgreSQL gibi kendi çalıştırdığınız bir veritabanının üzerine uygular. Mevcut AWS SDK'larınız ve AWS CLI değişmeden çalışmaya devam eder — yalnızca uç nokta URL'si değişir — böylece veriyi yönetilen bulut servisine göndermeden DynamoDB API'sini elde edersiniz.

ExtendDB, AWS'den gelen açık kaynaklı bir adaptördür — AWS DynamoDB mühendisleri tarafından yazıldı ve AWS Database Blog'da duyuruldu — ve DynamoDB JSON hat protokolünü Rust ile uygular. Yönetilen servisin cevapladığı HTTP API'sinin aynısını cevapladığı için mevcut AWS SDK'larınız ve AWS CLI değişmeden çalışır. Yer değiştiren tek şey uç nokta URL'sidir — kod baştan yazılmaz, yeni bir istemci kütüphanesi gerekmez.

İşin ilginç kısmı o API'nin arkasında duran şey. ExtendDB'nin takılabilir depolama arka uçları vardır: PostgreSQL referans uygulamadır ve Cassandra da olası bir başka arka uç olarak anılıyor. Yeni arka uçlar çekirdek değiştirilmeden uygulanır, yani DynamoDB uyumluluk katmanı ile depolama katmanı birbirinden bağımsız evrilir.

Bir istek de şöyle akar:

Neyi destekliyor — neyi desteklemiyor

Başlangıç belgelerine ve duyuruya göre ExtendDB (v0.1) uygulamaların gerçekten çağırdığı işlemlerin çoğunu kapsıyor:

• Tablolar — Create, Delete, Describe, List, Update.
• Öğeler — Put, Get, Delete, Update (SET / REMOVE / ADD / DELETE güncelleme eylemleri dahil).
• Query ve Scan — anahtar koşulları, filtre ifadeleri, projeksiyonlar, sayfalama ve ikincil dizinler.
• Batch — BatchGetItem ve BatchWriteItem.
• Transaction'lar — TransactGetItems ve TransactWriteItems.
• Stream'ler, TTL, Import/Export ve Tags.

Bilinçli olarak uygulamadığı şey, DynamoDB'ye özgü yönetilen özellikler kümesidir — en başta Global Tables ve bölgeler arası çoğaltma. Bunlar API yüzeyinin değil, yönetilen servisin küresel altyapısının özellikleridir, dolayısıyla kendi barındırdığınız bir adaptöre taşınmazlar.

DynamoDB Local ile karşılaştırma

Çevrimdışı geliştirme için zaten DynamoDB Local kullanıyor olabilirsiniz. O, tek bir makinede birim testleri için tasarlanmış tek bir JAR'dır (ya da amazon/dynamodb-local Docker imajı). ExtendDB bu tek süreçli araçtan daha geniş bir hedefe oynuyor: yerel geliştirme, şirket içi kurulumlar, uç ve hava boşluklu ortamlar ve DynamoDB API'sini isteyip verinin sizin denetlediğiniz altyapıda kalmasını istediğiniz hibrit / çoklu bulut düzenleri.

Yönetilen DynamoDB ile karşılaştırma

AWS'nin açıkça çizdiği sınır budur ve önemlidir:

ExtendDB, DynamoDB değildir. Uyumlu bir uygulamadır, yönetilen servisin yerini tutmaz. Performans özellikleri, ölçeklenme davranışı ve operasyonel nitelikleri farklıdır.

Somut olarak, ExtendDB çalıştırdığınızda:

• Veritabanının erişilebilirliği ve yedekleri sizin sorumluluğunuzdadır. Sizin adınıza çalışan yönetilen çok AZ'li dayanıklılık ya da zaman noktası kurtarma yoktur — bu iş size ve PostgreSQL operasyonlarınıza kalır.
• Uç noktada TLS zorunludur.
• Kimlik bilgileri IAM benzeridir ama AWS IAM'den ayrıdır — ExtendDB'nin kendi kimlik bilgisi modeli vardır; AWS hesabınıza karşı kimlik doğrulaması yapmaz.

v0.1 sürümünde ve Apache 2.0 lisanslıdır. Onu erken aşama yazılım olarak görün: yukarıdaki ortamlar için harika, üretim ölçeğindeki yönetilen DynamoDB'nin doğrudan yerine geçecek bir şey değil.

ExtendDB'nin kendisi RCU ya da WCU ölçmez — kapasite PostgreSQL'inizin derdidir. Aynı API çağrıları us-east-1 bölgesinde on-demand modda yönetilen DynamoDB'ye gittiğinde, 1 KB'lık bir PutItem 1 WCU, 4 KB'lık bir GetItem ise nihai tutarlı okumada 0,5 RCU faturalandırır. ExtendDB'yi gecikme için kıyaslayın; aynı erişim deseninde bulut faturasının nasıl görüneceğini karşılaştırmak için fiyat hesaplayıcıyı kullanın.

Kurulum

ExtendDB Linux ve macOS üzerinde çalışır ve Rust 1.85+ ile PostgreSQL 14+ ister. Akış iki komuttan ibaret:

extenddb init
extenddb serve

init şemayı PostgreSQL veritabanınızda hazırlar; serve ise https://127.0.0.1:8000 gibi bir uç noktayı dinleyen hat protokolü sunucusunu başlatır (TLS zorunlu olduğu için https).

AWS SDK'yı ona, başka herhangi bir özel uç noktaya yönelttiğiniz gibi yöneltin — değişen tek şey URL ve kimlik bilgileridir:

import {DynamoDBClient} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({
  endpoint: 'https://127.0.0.1:8000',
  region: 'local',
  credentials: {accessKeyId: '<extenddb-key>', secretAccessKey: '<extenddb-secret>'}
});

İstemci yapılandırmasından sonraki her şey — PutItem, Query, TransactWriteItems — yönetilen DynamoDB'ye karşı yazacağınız kodla birebir aynıdır. Tek tablolu bir öğe yerleşimi de tam olarak buluttaki gibi çalışır:

Bunu DynoTable'da yapın

ExtendDB DynamoDB hat protokolünü konuştuğu için onun için ayrı bir yönetim aracına ihtiyacınız yok — DynoTable uygulamasını ExtendDB uç noktasına, tıpkı DynamoDB Local bağlar gibi yöneltin: ExtendDB portu ve tek kullanımlık kimlik bilgileriyle bir çevrimdışı (yerel) profil oluşturun; DynoTable öğelere göz atar, sorgular ve düzenler — yalnız artık onları bir JAR'ın bellek içi deposu değil, kendi diskinizdeki PostgreSQL besliyor.

Hat protokolü uyumluluğunun getirisi budur: SQL Workbench, görsel sorgu oluşturucu ve öğe düzenleme ExtendDB'ye karşı da değişmeden çalışır; yani scan betikleri yazmadan kendi barındırdığınız verinin üzerinde gerçek bir GUI elde edersiniz.

Planlamanız gereken bir uyarı: ExtendDB'nin uç noktası yalnızca HTTPS'tir, oysa DynoTable'ın çevrimdışı profili (çoğu DynamoDB Local kurulumu gibi) bir loopback host:port hedefler. İstemciniz ya da araçlarınız düz metin bir loopback dinleyicisi istiyorsa, TLS'i ExtendDB'nin önünde sonlandırın (ya da yerel bir ters vekil çalıştırın) ve GUI'yi ona yöneltin — her hâlükârda hat üzerindeki protokol yine DynamoDB JSON'dur.

Tuzaklar

• v0.1'i üretim DynamoDB'si gibi görmeyin. Ölçeklenme, gecikme ve dayanıklılık AWS'nin değil, PostgreSQL'inizin sorumluluğundadır. Ona bel bağlamadan önce iş yükünüz için kıyaslayın.
• Global Tables / bölgeler arası çoğaltma yok. Tasarımınız çok bölgeli aktif-aktif üzerine kuruluysa ExtendDB doğru yol değildir — bu bir yönetilen servis özelliğidir.
• Alttaki veritabanını kendiniz yedekleyin. Yönetilen PITR yoktur; silinen bir PostgreSQL birimi geri gelmez. Diğer her PostgreSQL gibi pg_dump / WAL arşivlemeyi kurun.
• Kimlik bilgileri AWS IAM'in değil, ExtendDB'nin kendisinindir. Erişimi IAM politikaları, rolleri ya da koşul anahtarlarının yöneteceğini beklemeyin — o yetkilendirme modeli buraya taşınmaz.

Sonraki adımlar

• Önce erişim desenlerinizi modelleyin — arka uç ister DynamoDB ister ExtendDB üzerinden PostgreSQL olsun, aynı tek tablo tasarımı disiplini geçerlidir.
• Okumalarınızı ve yazmalarınızı DynamoDB Expression Builder ile kurup inceleyin, sonra test verilerinizi düz JSON ile hat biçimi arasında DynamoDB-JSON dönüştürücüyle çevirin.
• Canlı bir ExtendDB örneğini kurcalamaya hazır olduğunuzda DynoTable uygulamasını bağlayın ve ona diğer tablolar gibi göz atın.