PostgreSQL ve MongoDB, verinin biçimine göre seçilir.
Kayıt defterleri, kurallar ve paranın dokunduğu her şey için ilişkisel; biçimin kiracıya göre değiştiği yerlerde doküman. Her ikisini de kendi ürünlerimizin altında modelleyen, ayarlayan, taşıyan ve işleten mühendisler.
- PostgreSQL
- MongoDB
- Redis
- PgBouncer
- Debezium
- Kafka
PostgreSQL, geliştirdiğimiz her şeyin altındaki varsayılan veri deposudur.
Bir sadakat kayıt defteri, bir satış primi planı, bir yük mutabakatı, bir satın alma onayı — her biri ilişkileri ve değişmezleri olan bir olgular kümesidir ve gerçek işlemleri, kısıtları ve olgun bir sorgu planlayıcısı olan ilişkisel bir veritabanı bu değişmezleri ait oldukları yerde uygular. Kendi ürünlerimizin — Loyalty & Retention, Sales Performance, Order & Supply Management ve Workflow & Procurement — üzerinde çalıştığı teknoloji yığınının bir parçasıdır ve JSONB sütunları, bir zamanlar bir doküman veritabanına başvurulan durumların birçoğunu karşılar.
MongoDB, verinin biçimi gerçekten değiştiğinde yerini hak eder: her kategoride farklı nitelikleri olan bir ürün kataloğu, her kiracının farklı şekilde genişlettiği bir üye profili, editörlerin haftalık değiştirdiği bir içerik modeli, anahtarla geri okunan yüksek hacimli olay ve oturum verisi. Erişim desenine karşı değil onun etrafında modellendiğinde hızlıdır, sharding’i kolaydır ve Node.js üzerinden çalışmak rahattır.
Kullanmadığımız durumlar: parayı, kotaları veya onayları bir doküman veritabanına koymayız ve şeması olmayan veriye sabit bir şema dayatmayız. Analitik veri ambarına aittir — bkz. Veri Mühendisliği — önbellekler ise bu ikisine değil Redis’e aittir.
PostgreSQL ve MongoDB ile yaptığımız altı iş.
Kayıt sistemleri
Kayıt defterleri, planlar, siparişler ve onaylar için normalize edilmiş PostgreSQL şemaları; kısıtlar, yabancı anahtarlar ve yalnızca ekleme yapılan denetim tabloları sayesinde hatalı veriyi uygulama devreye girmeden önce veritabanı reddeder.
Çok kiracılı SaaS veri modelleri
Tek bir ortamdan çok sayıda müşteriye hizmet veren platformlar için satır düzeyinde güvenlik, kiracı kapsamlı indeksler ve havuzlanmış bağlantılar — çok kiracılı bir ürünün ilk kiracısından itibaren ihtiyaç duyduğu model.
MongoDB’de katalog, profil ve içerik
Okuma desenlerinden yola çıkılarak tasarlanmış doküman modelleri: birlikte okunan veri gömülü, bağımsız değişen veri referanslı; esnekliğin sapmaya dönüşmemesi için şema doğrulamasıyla.
Performans ve sorgu ayarlama
İndeks incelemesi, plan analizi, zaman serisi tablolarının bölümlenmesi ve PgBouncer ile bağlantı havuzlama — en büyük kazanç genellikle en yavaş sorgulardan gelir, kimse daha büyük bir sunucu satın almadan çok önce.
Aşamalı geçişler
Genişlet-daralt yöntemiyle şema değişiklikleri, gruplar hâlinde geri doldurmalar ve bir yeniden mühendislik programı sırasında provası yapılmış geçiş anlarıyla Oracle, SQL Server veya MySQL’den PostgreSQL’e taşımalar.
Değişiklik yakalama ve olay akışları
Write-ahead log üzerindeki Debezium ve outbox deseni, veritabanını Kafka tüketicileri için güvenilir bir olay kaynağına dönüştürür — çift yazma yok.
Hangisi ne zaman seçilir.
Verinin ilişkileri ve kuralları varsa PostgreSQL’i seçin: finansal olan her şey, denetlenen her şey, bir iş akışı olan her şey, raporlamanın ileride birleştireceği her şey. İşlemsel sistemler için güvenli varsayılandır ve birçok ekibin sandığından daha iyi ölçeklenir — bölümleme, okuma replikaları ve yönetilen bir servis, tek bir birincil sunucuyu çok uzağa taşır. Doküman doğal birimse, şemalar kiracıya veya kategoriye göre değişiyorsa, yazma hacmi yüksek ve okumalar anahtarla yapılıyorsa ve yatay sharding bir öngörü değil gerçek bir gereksinimse MongoDB’yi seçin.
Ekip şema geçişlerinden hoşlanmıyor diye MongoDB’yi seçmeyin; şema değişiklikleri yine olur, sadece görünür olmaktan çıkar. Çoğunlukla yapılandırılmamış veri paketlerinin çok yüksek hızlarda tanımlayıcıyla okunduğu, bir doküman veritabanının veya anahtar-değer önbelleğinin daha ucuz ve daha basit olduğu bir iş yükü için PostgreSQL’i seçmeyin. Milyarlarca satır üzerinde analitik için de hiçbirini seçmeyin — orası bir veri ambarı ya da lakehouse’tur ve operasyonel depodan değişiklik yakalama ile beslenir.
Hatalı veriyi reddedecek şekilde tasarlanmış bir kayıt defteri tablosu.
create table points_ledger (
id bigint generated always as identity primary key,
member_id uuid not null references members(id),
amount integer not null check (amount <> 0),
reason text not null,
idempotency text not null unique,
-- flexible per-tenant attributes live in JSONB, not in a second database
attrs jsonb not null default '{}',
created_at timestamptz not null default now()
) partition by range (created_at);
-- append-only: no update or delete grants on this table
create index concurrently on points_ledger (member_id, created_at desc);
+ alter table points_ledger enable row level security;Tipik bir ortamda her deponun yeri.
Teslim ettiğimiz veritabanlarında bulunanlar.
- Sürüm kontrolünde geçişler, yalnızca ileri yönlü, pull request’lerde incelenir ve CI hattı tarafından uygulanır — uygulamanın teknoloji yığınına göre Flyway, Prisma, Alembic veya Liquibase ile. Canlı ortamda elle DDL yok.
- Kısıtlar yalnızca kodda değil, veritabanında. Yabancı anahtarlar, check kısıtları, benzersiz indeksler ve MongoDB şema doğrulaması; böylece veriye dokunan her uygulama aynı kurallara tabi olur.
- Geri yüklemesi denenmiş yedekler. Point-in-time recovery açık, geri yüklemelerin provası düzenli aralıklarla yapılır, kurtarma süresi ve kurtarma noktası runbook’a sayı olarak yazılır.
- Varsayılan olarak yönetilen servisler — RDS veya Aurora, Azure Database, Cloud SQL, MongoDB Atlas — durağan veride şifreleme, özel ağ ve denetim günlüğü açık; kendi sunucularımızda barındırma yalnızca veri yerleşimi mevzuatı gerektirdiğinde.
- Deponun kendisinde gözlemlenebilirlik: yavaş sorgu günlükleri, sizinle belirlenen bir ritimde düzenli olarak incelenen
pg_stat_statementsveya Atlas profiler ve replikasyon gecikmesi ile bağlantı doygunluğu için uyarılar. - Servis başına en az ayrıcalıklı roller, bir kasadan döndürülen sırlar, kiracıların tablo paylaştığı yerlerde satır düzeyinde güvenlik ve GDPR / KVKK silme ve saklama için haritalanmış kişisel veriler.
- Canlı ortama benzer veriyle yük testi. Gerçekçi hacimler, gerçekçi dağılım çarpıklığı ve testten geçen sorgu planları sürümle birlikte kayda alınır.
- Bir veri sözlüğü — her tablo veya koleksiyon, sahibi, saklama süresi ve ona bağlı olanlar — böylece sonraki ekip şemayı tersine mühendislikle çözmek zorunda kalmaz.
Şemayla birlikte genellikle teslim edilenler.
- İlk geçiş yazılmadan önce varlık modeli ve erişim deseni incelemesi
- Her ortamda CI tarafından çalıştırılan geçiş seti, başlangıç verisi ve geri alma prosedürü
- En yavaş sorgular için öncesi-sonrası süreleriyle indeks ve sorgu planı raporu
- Yönetilen sunucular, replikalar, parametre grupları ve yedekleme politikası için Terraform
- Gecikme, replikasyon gecikmesi, bağlantılar, şişme ve disk için panolar ve uyarı kuralları
- Yük devretme, geri yükleme, ana sürüm yükseltmesi ve CDC yeniden oynatma prosedürünü kapsayan bir runbook
Sık sorulan sorular
Komşu teknoloji yığınları ve onları kullanan hizmetler.
Şemanız yetişemez hâle mi geldi?
En yavaş sorgunuzu ya da üzerinde tartıştığınız varlık modelini bize gönderin. Bir veritabanı mühendisi okur ve nasıl yaklaşacağımızı yazılı olarak iletir.