Veritabanı veriyi saklar ve sorgulanabilir kılar; mesaj kuyruğu ve olay akışı platformları ise uygulamalar arasında iş ve veri aktarımını düzenler. Önbellek ile arama indeksi de ayrı görevler üstlenir. Bu bileşenleri aynı ihtiyacın alternatifleri gibi değil, uygulamanın veri akışındaki rolleriyle değerlendirmek gerekir.
Bu kategorideki teknolojiler; veri modeli, tutarlılık, lisans, yüksek erişilebilirlik (HA) ve bakım ihtiyaçları açısından farklılaşır. Amaç her uygulamaya daha fazla bileşen eklemek değil, gerekli olanları işletilebilir bir mimaride birleştirmektir.
Hangi ihtiyaç için hangi teknoloji?
| İhtiyaç | Değerlendirilecek teknoloji | Temel karar |
|---|---|---|
| İlişkisel veri, SQL ve transaction | PostgreSQL, MariaDB / MySQL | Uygulama uyumu, sorgular, veri bütünlüğü ve yükseltme yolu |
| PostgreSQL otomatik failover | Patroni Cluster | Replikasyon modu, lider seçimi ve istemci yönlendirmesi |
| MariaDB multi-primary replikasyon | Galera Cluster | Quorum, yazma çakışmaları ve ağ gecikmesi |
| Doküman tabanlı veri | MongoDB, Couchbase | Belge modeli, sorgulama, indeks ve ölçekleme ihtiyacı |
| Önbellek ve bellek içi veri yapıları | Redis / Valkey | Verinin yeniden üretilebilirliği, bellek ve kalıcılık |
| Tam metin arama ve log analizi | Elasticsearch / OpenSearch | İndeks tasarımı, saklama süresi ve sorgu uyumu |
| Yeniden okunabilen olay akışı | Apache Kafka | Partition, sıralama, retention ve consumer lag |
| Görev kuyruğu ve mesaj yönlendirme | RabbitMQ | Exchange, kuyruk türü, onay ve yeniden deneme |
SQL ve NoSQL arasındaki fark nedir?
İlişkisel veritabanları tablo, ilişki ve kısıtlarla veri bütünlüğünü modellemeyi sağlar. Doküman veritabanları ise birlikte erişilen bilgileri belge yapısında toplamak için değerlendirilebilir. NoSQL, şema tasarlamamak veya tutarlılıktan vazgeçmek anlamına gelmez. PostgreSQL’in JSONB desteği de JSON kullanan her uygulamanın ayrı bir doküman veritabanına ihtiyaç duymadığını gösterir.
Kararı gerçek sorgularla verin: Hangi veriler birlikte okunuyor, hangi değişiklikler tek transaction içinde tamamlanmalı, hangi indeksler gerekiyor? “SQL yalnız dikey, NoSQL yalnız yatay ölçeklenir” gibi kesin ayrımlar ürünlerin gerçek mimarisini açıklamaz.
Mesaj kuyruğu ile olay akışı ne zaman gerekir?
Uzun süren bir işi kullanıcı isteğinden ayırmak, geçici yük artışını karşılamak veya servisleri birbirinden bağımsız çalıştırmak için mesajlaşma katmanı kullanılabilir. RabbitMQ’nun exchange ve kuyruk modeli ile Kafka’nın partition ve offset modeli farklı işleyişlere sahiptir. RabbitMQ Streams gibi seçenekler nedeniyle ayrım yalnız “biri siler, diğeri saklar” cümlesine indirgenmemelidir.
Örneğin sipariş kaydını veritabanına yazmak ile bildirim mesajını broker’a göndermek iki ayrı işlemdir. Biri başarılı, diğeri başarısız olursa ne yapılacağı tasarlanmalıdır. Outbox gibi bir yaklaşım, tekrar deneme ve idempotent tüketiciyle birlikte değerlendirilebilir; broker kurulması bu tutarlılık sorununu tek başına çözmez.
HA, failover ve backup aynı şey değildir
Node, sistemin bir üyesidir; cluster, birlikte çalışan node’lardan oluşur. Ancak cluster kurulması her verinin her node’da kopyası bulunduğunu veya her arızada otomatik failover yapılacağını göstermez.
- Replikasyon: Verinin başka node’lara aktarılmasıdır; hatalı silme de aktarılabilir.
- Failover: Arızada hizmet rolünün başka node’a devredilmesidir; uygulamanın yeniden bağlanması ayrıca sınanır.
- Backup ve restore: Yedek oluşturma ve o yedekten geri yükleme işlemleridir; replikasyondan ayrı planlanır.
- PITR (Point-in-Time Recovery): Destekleyen ürünlerde uygun backup ve kesintisiz işlem kaydı zinciriyle belirli bir ana dönmeyi sağlar.
- Disaster Recovery (DR): Veri merkezi, ağ veya hesap kaybında sistemi nerede ve nasıl ayağa kaldıracağınızı tanımlar.
RPO, kurtarma sonrasında kabul edilebilir veri kaybını zaman cinsinden; RTO, hizmetin yeniden çalışır duruma gelmesi için hedeflenen süreyi ifade eder. Bunlar ürün adından çıkarılan garantiler değil, tasarım ve kurtarma tatbikatıyla doğrulanacak hedeflerdir. Uzak veri merkezi eklemek gecikme ve quorum kararlarını da değiştirir.
Lisans ve işletim kapsamını birlikte değerlendirin
Bu listedeki bütün dağıtımlar aynı özgür yazılım lisansına sahip değildir. Redis ve Elasticsearch’te sürüm/dağıtım, MongoDB’de SSPL, Couchbase’te Community/Enterprise koşulları ayrıca incelenmelidir. Ücretsiz indirilebilen paket, sınırsız kullanım veya üretici desteği anlamına gelmez; ayrıntılar ilgili ürün sayfalarındadır.
Mevcut sistemden geçiş planlıyorsanız özgür yazılım veritabanı dönüşümü kapsamında şema, sorgu, istemci, veri aktarımı ve geri dönüş gereksinimlerini birlikte değerlendirebiliriz. Günlük bakım ve arıza yönetimi için Linux sistem yönetimi hizmetimiz incelenebilir.
