- Infisical, günde 50 milyondan fazla secret işleyen bir platform olarak hızla büyüdü
- Kullanım arttıkça yığınını sürekli yükseltmesi gerekti ve yakın zamanda tüm veritabanını MongoDB'den PostgreSQL'e taşıdı
- Bu geçiş; yeni teknolojilerin benimsenmesi, veritabanı şemasının oluşturulması, mantığın yeniden yapılandırılması, sorguların yeniden yazılması ve milyonlarca (hatta milyarlarca) veri kaydının PostgreSQL'e taşınmasını içeren karmaşık bir süreçti
Başlangıç aşaması
- Infisical ilk geliştirilirken ekip, en aşina olduğu yığını kullanarak MongoDB + Mongoose ORM'i seçti
- İlk dönemde daha çok yönetilen SaaS hizmeti olan Infisical Cloud'a odaklanıldı ve kullanıcıların ürünü kendi kendine barındıracağı pek öngörülmedi
Neden MongoDB değil?
- MongoDB başlangıçta iyi çalıştı, ancak ürünün kullanım senaryoları yönetilen hizmetlerin ötesine geçtikçe dezavantajları görünür hale gelmeye başladı
- Birçok kuruluş, Infisical Cloud yerine Infisical'ı kendi kendine barındırmayı tercih etti ve bazıları şirket içi gereksinimleri karşılamak zorundaydı
- MongoDB'nin kısıtları ve kullanılabilirlik sorunları nedeniyle PostgreSQL'e geçme kararı alındı
Neden PostgreSQL seçildi?
- Yeni bir veritabanı aranırken yönetim kolaylığı, transaction desteği ve ilişkisel özellikler önemli unsurlar olarak değerlendirildi
- Dahili depolama ile harici depolama çözümleri arasında değerlendirme yapıldı, ancak tercih PostgreSQL'den yana oldu
- PostgreSQL; aktif bir topluluk, zengin dokümantasyon, çeşitli çözümler ve eklentiler sunuyor, ayrıca çoğu bulut sağlayıcısında yönetilen hizmet olarak mevcut
ORM hakkında
- PostgreSQL seçildikten sonra uygulamanın veritabanıyla nasıl etkileşime gireceğine karar verilmesi gerekti
- Mongoose ORM'e benzer bir deneyim sunan araçlar arandı ve Knex.js query builder kullanmaya karar verildi
- Knex.js, seeding ve migration araçları sağlıyor; TypeScript desteği için özel Zod entegrasyonu çalışmalarıyla birlikte istenen seviyeye ulaşıldı
Geçiş planı
- Kodun yeniden yazımı tamamlanmaya yaklaşırken, MongoDB verisinin PostgreSQL'e en az kesintiyle nasıl eşleneceği üzerine düşünüldü
- Kritik altyapıda rol oynayan Infisical için hiçbir downtime kabul edilemezdi; bunun yerine geçiş süresince yazma işlemlerinin durdurulması gibi bir uzlaşmaya gidildi
Büyük geçiş
- Geçiş hazırlığı için ayrıntılı bir kontrol listesi ve tahmini zaman çizelgesi hazırlandı
- Geçiş, 6 saat boyunca yalnızca okuma işlemlerine izin verilerek gerçekleştirildi ve veri taşındıktan sonra DNS yeni instance'a yönlendirildi
Sonuç
- Geçiş, veri kaybı olmadan sorunsuz şekilde tamamlandı ve müşteriye etkisi sınırlı olan bazı işlevsel hatalar 36 saat içinde düzeltildi
- Platform, join tabanlı sorgu optimizasyonu sayesinde performans artışı yaşadı; veritabanı maliyetleri de %50 azaldı
- PostgreSQL'e geçişle birlikte veri doğrulama iyileşti ve artık Infisical'ı kendi kendine barındırmak çok daha kolay hale geldi
Sonuç olarak
- MongoDB'den PostgreSQL'e geçme kararı kolay olmadı; dikkatli planlama ve tartışmalarla birlikte süreç 3-4 ay sürdü
- Böyle büyük bir projeye girişmeden önce kullanım senaryolarını ve uygulamayı derinlemesine düşünmeleri tavsiye ediliyor
1 yorum
Hacker News yorumları
Postgres ve MongoDB’yi büyük ölçekte çalıştırma deneyimi olan bir kullanıcı, her iki veritabanını da sevdiğini ancak Postgres’in yüksek erişilebilirlik (HA) ve yatay ölçeklenme desteğindeki eksikliği anlayamadığını belirtiyor. Postgres kurulumunun her seferinde kendine özgü olduğunu ve bunu telafi etmek için çeşitli eklentiler ile script’ler kullanmak gerektiğini söylüyor. Bu eklentilerin ise çoğu zaman hatalı ve yetersiz belgelenmiş olduğunu ekliyor. Postgres’in ana sürümlerde dosya formatını değiştirmesi nedeniyle yükseltmelerin çok zor olduğunu da belirtiyor. MySQL’in HA/sharding konusunda Postgres’ten çok daha iyi olmasına şaşırdığını ifade ediyor.
MongoDB’den PostgreSQL’e geçiş deneyimini teknik açıdan anlatan bir blog yazısını paylaşıyor. Yazının örnekler ve grafikler içerdiğini, daha teknik olduğunu ve iş tarafına daha az odaklandığını belirtiyor.
PostgreSQL’in veritabanı dünyasını ele geçirdiğini söyleyen bir kullanıcı, yazarların en başta veri modeline uygun olmayan bir mimari seçtiğine dikkat çekiyor. İlişkisel veriyi ilişkisel olmayan bir depoya koymanın her zaman sorun çıkaracağını söylüyor.
MongoDB ve Mongoose ORM seçiminin özellik geliştirme hızını artırmaya optimize edilmiş bir tercih olduğunu savunan ifade ile Tony Hoare’un "erken optimizasyon bütün kötülüklerin köküdür" alıntısıyla bu tercihi meşrulaştıran ifade arasındaki çelişkiye dikkat çekiliyor.
Doküman veritabanlarının yeni projeler için uygun olmadığını düşünen bir kullanıcı, MongoDB’nin lisans ve barındırma maliyetlerinin artacağını, buna karşılık özellik geliştirmesinin duraklayacağını öngörüyor.
MongoDB kaynaklı sorunlar nedeniyle Postgres’e geçen bir kullanıcı, bu karardan çok memnun olduğunu söylüyor. Ayrıca MongoDB’nin SQL yerine JavaScript kullanmasının rahatsız edici olduğunu ekliyor.
Gerçek yeniden yazım sürecinde yaşanan sorunların tartışılmasının eksik kaldığını söyleyen bir kullanıcı; sorguların eşdeğer biçimde kurulup kurulmadığını, ürünün her iki veritabanından da okuyup yazabilecek şekilde nasıl yapılandırıldığını, geçiş sırasında hata bulunup bulunmadığını ve sorguların bire bir taşınıp taşınamadığını soruyor.
MongoDB kullanmış bir kullanıcı, doküman veritabanlarının bazı kullanım senaryoları için uygun olduğunu ancak Mongoose kullanmak gerektiğini fark ettiğiniz anda ilişkisel veritabanına geçmeyi düşünmeniz gerektiğini söylüyor. Çoğu durumda Mongoose’un mevcut projelere sonradan eklendiğini, baştan itibaren gerekiyorsa ilişkisel veritabanı kullanılması gerektiğini tavsiye ediyor.
MongoDB kullanan bir projeyi devralan bir kullanıcı, BSON formatını kötü bulduğunu ancak JSON API’den veritabanına kadar aynı şemanın kullanılabilmesini sevdiğini belirtiyor. Bunun Go ve Rust’ta veri odaklı programlamaya uygun olduğunu da ekliyor. Sonuç olarak MongoDB’nin yalnızca okuma ağırlıklı işler için uygun olduğunu, yazma yoğun işlerde ise pek yardımcı olmadığını söylüyor.
PostgreSQL’e geçişin ana nedeninin teknik sebeplerden çok lisans sorunları olduğunu söyleyen bir kullanıcı, join kullanılan sorgu optimizasyonları sayesinde performans artışı yaşadığını paylaşıyor. Verinin anahtar-değer deposuna uygun şekilde modellenmemiş olmasının, uygun türde bir depoya geçişte belirleyici neden olduğunu söylüyor.