Sıkıcı Veritabanlarını Övmek

Gönderdiğim her proje sonunda Postgres'e yerleşiyor. Daha heyecan verici bir seçeneği tercih ederek başlayan projeler de sonunda Postgres'e geldi — genellikle gece saat ikide.

Örüntü

Yeni bir iş yükü ortaya çıkar. Biri ilişkisel modelin buna uymadığını söyler. O işe özel bir veri deposu kullanırız. O tek konuda gerçekten daha iyidir. Sonra:

1. Ürün birleştirme (join) gerektirir.
2. Ürün işlem (transaction) gerektirir.
3. Ürün “sadece tablo gibi sorgula” ihtiyacı duyar.

Özel amaçlı depo yanlış değildi — erkendi. Onun için tasarlanan iş yükü daha sonra, taşımanın acı verdiği ölçekte ortaya çıkar.

Sıkıcı seçeneğin kazandırdıkları

• Tek bir zihinsel model. İndeksler, kısıtlar ve rüyamda bile yazabildiğim bir sorgu dili.
• Araç ekosistemi. Yedekleme, çoğaltma, gözlemlenebilirlik ve her dil için sürücüler — hepsi olgun.
• İşe alım ve oryantasyon. Gece saat ikide Postgres konusunda herkes yardım edebilir.

Sıkıcı seçeneğin yanlış olduğu durumlar

Gerçekten çok yüksek yazma hacimli anahtar-değer erişimi, grafik dolaşımları, aşırı ölçekte tam metin arama ve saniyede milyonlarca ileti işleyen kuyruklar. Doğru aracı kullanın — ölçüm yaptıktan sonra ve mümkünse sıkıcı seçeneğin ölçülebilir biçimde yetersiz kaldığını gördükten sonra.

En iyi veritabanı, on yıl sonra bile iyi çalışmaya devam eden ve bir daha düşünmenizi gerektirmeyen veritabanıdır.