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

Diyelim ki bir hastane kayıt sistemi binanın içinde kalmak zorunda — hasta verisi asla şirket-içi ağdan çıkamaz, bir denetçi her bağımlılığı onaylar ve geliştirici dizüstülerinin hiç interneti yok. Ekip uygulamayı zaten DynamoDB API'sine karşı yazdı ve onu beğeniyor: tek haneli milisaniye anahtar aramaları, temiz bir öğe modeli, bakacak şema geçişleri yok. Ama yönetilen DynamoDB bir bulut hizmetidir ve "veriyi AWS'ye gönder" burada söz konusu değildir.

ExtendDB tam da bu boşluk için inşa edilmiştir. DynamoDB wire protokolünü konuşur ama veriyi sizin çalıştırdığınız bir veritabanında saklar.

ExtendDB nedir

ExtendDB, AWS'den açık kaynaklı bir adaptördür — AWS DynamoDB mühendisleri tarafından yazılmış ve AWS Database Blog'da duyurulmuştur — ve DynamoDB JSON wire protokolünü Rust'ta uygular. Yönetilen hizmetin yanıtladığı aynı HTTP API'yi yanıtladığı için, mevcut AWS SDK'larınız ve AWS CLI değişmeden çalışır. Hareket eden tek şey endpoint URL'dir — kod yeniden yazımı yok, yeni istemci kütüphanesi yok.

İlginç kısım, o API'nin arkasında ne olduğudur. ExtendDB'nin takılabilir depolama arka uçları vardır: PostgreSQL referans uygulamasıdır ve Cassandra başka bir olası arka uç olarak gösterilir. Yeni arka uçlar çekirdeği değiştirmeden uygulanır, böylece DynamoDB-uyumluluk katmanı ve depolama katmanı bağımsız olarak gelişir.

Yani bir istek şöyle akar:

uygulamanız  ──DynamoDB JSON──▶  ExtendDB (Rust)  ──▶  PostgreSQL
(değişmemiş SDK)                 wire-protokol           veriniz, diskiniz

Neyi destekler — ve neyi desteklemez

başlangıç dokümanlarına ve duyuruya göre, ExtendDB (v0.1) uygulamaların gerçekten çağırdığı işlemlerin çoğunu kapsar:

• 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 index'ler.
• Batch — BatchGetItem ve BatchWriteItem.
• Transaction'lar — TransactGetItems ve TransactWriteItems.
• Streams, TTL, Import/Export ve Tags.

Kasıtlı olarak uygulamadığı şey, DynamoDB'ye özgü yönetilen özellikler kümesidir — en önemlisi Global Tables ve bölgeler arası çoğaltma. Bunlar API yüzeyinin değil, yönetilen hizmetin global altyapısının özellikleridir, bu yüzden kendiniz barındırdığınız bir adaptöre taşınmazlar.

DynamoDB Local'a karşı

Çevrimdışı geliştirme için zaten DynamoDB Local kullanıyor olabilirsiniz. Bu, tek bir makinede unit testleri için tasarlanmış tek bir JAR'dır (ya da amazon/dynamodb-local Docker imajı). ExtendDB o tek-süreçli araçtan daha geniş hedefler: yerel geliştirme, şirket-içi dağıtımlar, edge ve hava-boşluklu ortamlar ve DynamoDB API'sini istediğiniz ama verinin kontrol ettiğiniz altyapıda yaşadığı hibrit / çoklu-bulut kurulumları.

Yönetilen DynamoDB'ye karşı

Bu, AWS'nin açıkça çizdiği çizgidir ve önemlidir:

ExtendDB, DynamoDB değildir. Uyumlu bir uygulamadır, yönetilen hizmetin yerine geçen değil. Performans özellikleri, ölçekleme davranışı ve operasyonel özellikler farklıdır.

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

• Veritabanının kullanılabilirliği ve yedeklerinin sahibi sizsiniz. Sizin için bunu yapan yönetilen çok-AZ dayanıklılığı ya da point-in-time recovery yok — bu sizin ve PostgreSQL operasyonlarınızın sorumluluğunda.
• TLS endpoint'te 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ğrulamaz.

v0.1'dir ve Apache 2.0 ile lisanslıdır. Onu erken yazılım olarak ele alın: yukarıdaki ortamlar için harika, üretim ölçekli yönetilen DynamoDB için bir tak-çalıştır takas değil.

Kurulum

ExtendDB Linux ve macOS'ta çalışır ve Rust 1.85+ ile PostgreSQL 14+ gerektirir. Akış iki komuttur:

extenddb init
extenddb serve

init, PostgreSQL veritabanınızda şemayı sağlar; serve, https://127.0.0.1:8000 gibi bir endpoint'te dinleyen wire-protokol sunucusunu başlatır (TLS gereklidir, bu nedenle https).

AWS SDK'yı, herhangi bir özel endpoint'te yapacağınız gibi ona yöneltin — yalnızca URL ve kimlik bilgileri değişir:

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 aynıdır. Tek-tablo bir öğe düzeni, tıpkı bulutta olduğu gibi çalışır:

DynoTable'da yapın

ExtendDB DynamoDB wire protokolünü konuştuğu için, onun için ayrı bir yönetim aracına ihtiyacınız yok — DynoTable'ı ExtendDB endpoint'ine, onu DynamoDB Local'a bağlayacağınız gibi yöneltin: ExtendDB portu ve geçici kimlik bilgileriyle bir çevrimdışı (yerel) profil oluşturun ve DynoTable öğeleri gözden geçirecek, sorgulayacak ve düzenleyecek — yalnızca artık bir JAR'ın bellek-içi deposu yerine kendi diskinizdeki PostgreSQL ile destekleniyorlar.

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

Planlanacak bir uyarı: ExtendDB'nin endpoint'i yalnızca-HTTPS'tir, oysa DynoTable'ın çevrimdışı profili (çoğu DynamoDB-Local kurulumu gibi) bir loopback host:port hedefler. İstemciniz ya da aracınız düz-metin bir loopback dinleyicisine ihtiyaç duyarsa, TLS'i ExtendDB'nin önünde sonlandırın (ya da yerel bir ters proxy çalıştırın) ve GUI'yi ona yöneltin — telin üzerindeki protokol her iki durumda da yine DynamoDB JSON'dur.

Tuzaklar

• v0.1'i üretim DynamoDB'si gibi ele almayın. Ölçekleme, gecikme ve dayanıklılık AWS'nin değil, PostgreSQL'inizindir. Ona bağımlı olmadan önce iş yükünüz için benchmark yapın.
• Global Tables / bölgeler arası çoğaltma yok. Tasarımınız çok-Bölgeli active-active'e dayanıyorsa, ExtendDB yol değil — bu yönetilen-hizmet bir özelliğidir.
• Altında yatan veritabanını kendiniz yedekleyin. Yönetilen PITR yok; düşürülen bir PostgreSQL birimi gitti. Diğer herhangi bir PostgreSQL gibi pg_dump / WAL arşivlemeyi bağlayın.
• Kimlik bilgileri ExtendDB'nin kendisidir, AWS IAM değil. IAM politikalarının, rollerinin ya da koşul anahtarlarının erişimi yönetmesini beklemeyin — o yetkilendirme modeli taşınmaz.

Sonraki adımlar

• Önce erişim desenlerinizi modelleyin — aynı tek-tablo tasarım disiplini, arka uç ister DynamoDB ister PostgreSQL-via-ExtendDB olsun geçerlidir.
• Okumalarınızı ve yazmalarınızı DynamoDB Expression Builder ile oluşturup inceleyin, sonra fikstürleri düz JSON ile wire biçimi arasında DynamoDB-JSON dönüştürücüsü ile dönüştürün.
• Canlı bir ExtendDB örneğini kurcalamaya hazır olduğunuzda, DynoTable'ı bağlayın ve onu diğer herhangi bir tablo gibi gözden geçirin.