Bunu yakın zamanda öğrendim (lisans değişikliğinden dolayı diyorlar). Bu beni düşündürdü çünkü son birkaç yılda MongoDB'nin ne kadar berbat olduğu ve hiç kimsenin onu kullanmaması gerektiği hakkında tonlarca makale gördüm. Ancak bu süre zarfında MongoDB çok daha olgun bir ürün haline geldi. Ne oldu? Bütün bu nefret gerçekten yeni bir DBMS'nin ilk pazarlamasındaki hatalardan mı kaynaklanıyor? Yoksa insanlar MongoDB'yi yanlış yerlerde mi kullanıyor?
MongoDB'yi savunduğumu düşünüyorsanız lütfen okuyun makalenin sonunda.
Yeni trend
Yazılım sektöründe söyleyebileceğimden daha uzun yıllardır çalışıyorum ama yine de sektörümüzü etkileyen trendlerin yalnızca küçük bir kısmına maruz kaldım. 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain'in yükselişine tanık oldum... liste sonsuzdur. Her yıl yeni trendler ortaya çıkıyor. Bazıları hızla kaybolurken, diğerleri yazılımın geliştirilme şeklini temelden değiştiriyor.
Her yeni trend genel bir heyecan yaratıyor: İnsanlar ya tekneye atlıyor ya da başkalarının çıkardığı gürültüyü görüp kalabalığı takip ediyor. Bu süreç Gartner tarafından kodlanmıştır. . Her ne kadar tartışmalı olsa da, bu zaman çizelgesi, teknolojiler sonunda kullanışlı hale gelmeden önce onlara ne olacağını kabaca anlatıyor.
Ancak zaman zaman yalnızca belirli bir uygulamanın yönlendirdiği yeni bir yenilik ortaya çıkar (veya bu durumda olduğu gibi ikinci bir yenilik gelir). NoSQL örneğinde, heyecan büyük ölçüde MongoDB'nin ortaya çıkışı ve hızlı yükselişinden kaynaklanıyordu. MongoDB bu eğilimi başlatmadı: Aslında büyük İnternet şirketleri büyük miktarlarda veriyi işlemede sorun yaşamaya başladı ve bu da ilişkisel olmayan veritabanlarının geri dönüşüne yol açtı. Genel hareket Google'ın Bigtable ve Facebook'un Cassandra'sı gibi projelerle başladı, ancak çoğu geliştiricinin erişebildiği en iyi bilinen ve erişilebilir NoSQL veritabanı uygulaması MongoDB oldu.
Not: Belge veritabanlarını sütunlu veritabanları, anahtar/değer depoları veya genel NoSQL tanımı kapsamına giren diğer birçok veri deposu türünden herhangi biriyle karıştırdığımı düşünebilirsiniz. Ve haklısın. Ancak o dönemde kaos hüküm sürüyordu. Herkes NoSQL'e takıntılı, artık herkes haline geldi kesinlikle çoğu kişi farklı teknolojilerdeki farklılıkları görmese de gerekliydi. Çoğu kişi için MongoDB artık ile eşanlamlı NoSQL.
Ve geliştiriciler bunun üzerine saldırdı. Herhangi bir sorunu çözmek için sihirli bir şekilde ölçeklenen, şemasız bir veritabanı fikri oldukça cazipti. 2014 yılı civarında, bir yıl önce MySQL, Postgres veya SQL Server gibi ilişkisel veritabanının kullanıldığı her yerde MongoDB veritabanlarının dağıtılmaya başladığı görüldü. Neden diye sorulduğunda, sıradan "bu web'in ölçeğidir" cevabından daha düşünceli "verilerim çok gevşek yapılandırılmış ve şemasız bir veritabanına iyi uyuyor" cevabına kadar bir yanıt alabilirsiniz.
MongoDB'nin ve genel olarak belge veritabanlarının, geleneksel ilişkisel veritabanlarıyla ilgili bir dizi sorunu çözdüğünü unutmamak önemlidir:
- Katı şema: İlişkisel bir veritabanıyla, dinamik olarak oluşturulmuş verileriniz varsa, ya bir grup rastgele "çeşitli" veri sütunu oluşturmaya, veri bloklarını buraya yerleştirmeye ya da yapılandırmayı kullanmaya zorlanırsınız ...tüm bunların önemli dezavantajları var.
- Ölçeklendirme zorluğu: Tek bir sunucuya sığmayacak kadar çok veri varsa, MongoDB bunun birden fazla makinede ölçeklenmesine olanak tanıyan mekanizmalar sundu.
- Karmaşık devre modifikasyonları: göç yok! İlişkisel bir veritabanında, veritabanı yapısını değiştirmek büyük bir sorun olabilir (özellikle çok fazla veri olduğunda). MongoDB süreci büyük ölçüde basitleştirmeyi başardı. Ve bunu o kadar kolaylaştırdı ki, devreyi ilerledikçe güncelleyebilir ve çok hızlı bir şekilde ilerleyebilirsiniz.
- Kayıt performansı: MongoDB performansı özellikle doğru şekilde yapılandırıldığında iyiydi. Sıklıkla eleştirilen MongoDB'nin kullanıma hazır konfigürasyonu bile bazı etkileyici performans rakamları gösterdi.
Tüm riskler sizin üzerinizde
MongoDB'nin potansiyel faydaları, özellikle belirli sorun sınıfları için çok büyüktü. Yukarıdaki listeyi içeriğini anlamadan ve deneyiminiz olmadan okursanız, MongoDB'nin gerçekten devrim niteliğinde bir DBMS olduğu izlenimine kapılabilirsiniz. Tek sorun, yukarıda listelenen faydaların, bazıları aşağıda listelenen bazı uyarılarla birlikte gelmesiydi.
Adil olmak gerekirse, 10gen/MongoDB Inc.'de hiç kimse bu konuyla ilgilenmiyor. Aşağıdakilerin doğru olmadığını söylemeyeceğim, bunlar sadece tavizdir.
- Kayıp işlemler: İşlemler birçok ilişkisel veritabanının (hepsinin değil ama çoğunun) temel bir özelliğidir. İşlemsel, birden fazla işlemi atomik olarak gerçekleştirebileceğiniz ve verilerin tutarlı kalmasını sağlayabileceğiniz anlamına gelir. Elbette bir NoSQL veritabanında işlemsellik tek bir belgede olabilir veya işlem semantiğini elde etmek için iki aşamalı taahhütleri kullanabilirsiniz. Ancak bu işlevi kendiniz uygulamanız gerekecek... ki bu zor ve zaman alıcı bir iş olabilir. İşlemlerin atomikliği garanti edilemediğinden, veritabanındaki verilerin geçersiz durumlarla sonuçlandığını görene kadar çoğu zaman bir sorun olduğunu fark etmezsiniz. Not: Birçok kişi bana MongoDB 4.0'ın geçen yıl işlemleri başlattığını ancak bazı sınırlamalarla birlikte olduğunu söyledi. Makaleden çıkan sonuç aynı: teknolojinin ihtiyaçlarınızı ne kadar iyi karşıladığını değerlendirin.
- İlişkisel bütünlüğün kaybı (yabancı anahtarlar): Verilerinizin ilişkileri varsa bunları uygulamada uygulamanız gerekecektir. Bu ilişkilere saygı duyan bir veritabanına sahip olmak, uygulamanın ve dolayısıyla programcılarınızın üzerindeki işin çoğunu alacaktır.
- Veri yapısını uygulama becerisi eksikliği: Katı şemalar bazen büyük bir sorun olabilir, ancak akıllıca kullanıldığında iyi veri yapılandırması için de güçlü bir mekanizmadırlar. MongoDB gibi belge veritabanları inanılmaz şema esnekliği sağlar ancak bu esneklik, verileri temiz tutma sorumluluğunu ortadan kaldırır. Bunlara dikkat etmezseniz, beklediğiniz biçimde saklanmayan verileri hesaba katmak için uygulamanızda çok sayıda kod yazmak zorunda kalırsınız. Şirketimizde Simple Thread'de sık sık söylediğimiz gibi... uygulama bir gün yeniden yazılacak, ancak veriler sonsuza kadar yaşayacak. Not: MongoDB şema kontrolünü destekler: faydalıdır ancak ilişkisel veritabanındakiyle aynı garantileri sağlamaz. Öncelikle şema denetimi eklemek veya değiştirmek, koleksiyondaki mevcut verileri etkilemez. Verileri yeni şemaya göre güncellemenizi sağlamak size kalmıştır. Bunun ihtiyaçlarınız için yeterli olup olmadığına kendiniz karar verin.
- Yerel sorgu dili/araç ekosisteminin kaybı: SQL'in ortaya çıkışı mutlak bir devrimdi ve o zamandan bu yana hiçbir şey değişmedi. İnanılmaz derecede güçlü bir dil ama aynı zamanda oldukça karmaşık. JSON parçalarından oluşan yeni bir dilde veritabanı sorguları oluşturma ihtiyacı, SQL ile çalışma deneyimi olan kişiler tarafından geriye doğru atılmış büyük bir adım olarak değerlendiriliyor. IDE'lerden raporlama araçlarına kadar SQL veritabanlarıyla etkileşime giren geniş bir araç evreni vardır. SQL'i desteklemeyen bir veritabanına geçmek, bu araçların çoğunu kullanamayacağınız veya bunları kullanmak için verileri SQL'e çevirmeniz gerektiği anlamına gelir ki bu, düşündüğünüzden daha zor olabilir.
MongoDB'ye yönelen geliştiricilerin çoğu, aradaki dengeyi gerçekten anlamadı ve genellikle onu birincil veri depoları olarak kurmaya balıklama daldı. Bundan sonra geri dönmek genellikle inanılmaz derecede zordu.
Ne farklı yapılabilirdi?
Herkes balıklama atlayıp dibe çarpmadı. Ancak birçok proje MongoDB'yi uymadığı yerlere kurdu ve uzun yıllar onunla yaşamak zorunda kalacaklar. Bu kuruluşlar teknoloji seçimleri üzerinde biraz zaman harcamış ve metodik olarak düşünmüş olsalardı, birçoğu farklı seçimler yapacaktı.
Doğru teknoloji nasıl seçilir? Teknoloji değerlendirmesi için sistematik bir çerçeve oluşturmaya yönelik çeşitli girişimlerde bulunulmuştur. и ama bana öyle geliyor ki bu gereksiz bir karmaşıklık.
Pek çok teknoloji yalnızca iki temel soru sorarak akıllıca değerlendirilebilir. Sorun, onlara sorumlu bir şekilde cevap verebilecek, cevapları bulmaya zaman ayıracak ve önyargısız insanları bulmaktır.
Herhangi bir sorunla karşılaşmıyorsanız yeni bir alete ihtiyacınız yoktur. Nokta.
Soru 1: Hangi sorunları çözmeye çalışıyorum?
Herhangi bir sorunla karşılaşmıyorsanız yeni bir alete ihtiyacınız yoktur. Nokta. Bir çözüm aramanıza ve sonra bir sorun icat etmenize gerek yok. Yeni teknolojinin mevcut teknolojinizden önemli ölçüde daha iyi çözdüğü bir sorunla karşılaşmadığınız sürece burada tartışılacak bir şey yok. Başkalarının kullandığını gördüğünüz için bu teknolojiyi kullanmayı düşünüyorsanız, onların hangi sorunlarla karşılaştıklarını düşünün ve bu sorunların sizde olup olmadığını sorun. Bir teknolojiyi başkaları kullanıyor diye kabul etmek kolaydır; asıl zorluk sizin de aynı sorunlarla karşılaşıp karşılaşmadığınızı anlamaktır.
Soru 2: Neyi kaçırıyorum?
Bu kesinlikle daha zor bir soru çünkü derinlemesine araştırmanız ve hem eski hem de yeni teknolojiyi iyi anlamanız gerekecek. Bazen yenisini onunla bir şeyler inşa edene veya bu deneyime sahip birine sahip olana kadar gerçekten anlayamazsınız.
Her ikisine de sahip değilseniz, bu enstrümanın değerini belirlemek için mümkün olan minimum yatırımı düşünmek mantıklı olacaktır. Peki yatırımı yaptıktan sonra kararı geri çevirmek ne kadar zor olacak?
İnsanlar her zaman her şeyi mahveder
Bu soruları olabildiğince tarafsız bir şekilde yanıtlamaya çalışırken bir şeyi unutmayın: İnsan doğasıyla savaşmak zorunda kalacaksınız. Teknolojiyi etkili bir şekilde değerlendirmek için aşılması gereken bir takım bilişsel önyargılar vardır. İşte sadece birkaçı:
- - herkes onu biliyor ama onunla savaşmak yine de zor. Teknolojinin gerçekten gerçek ihtiyaçlarınızı karşıladığından emin olun.
- — Birçok geliştirici, uzun süredir birlikte çalıştıkları teknolojileri küçümseme ve yeni teknolojinin faydalarını abartma eğilimindedir. Sadece programcılar değil, herkes bu bilişsel önyargıya karşı hassastır.
- - Var olanı görüp, eksik olanı gözden kaçırma eğilimindeyiz. Bu, yenilik etkisi ile birleştiğinde kaosa yol açabilir, çünkü yalnızca doğası gereği yeni teknolojiye aşırı değer vermekle kalmaz, aynı zamanda onun eksikliklerini de görmezden gelirsiniz..
Objektif değerlendirme kolay değildir ancak altta yatan bilişsel önyargıları anlamak, daha rasyonel kararlar vermenize yardımcı olacaktır.
Özet
Ne zaman bir yenilik ortaya çıksa, iki sorunun büyük bir dikkatle yanıtlanması gerekir:
- Bu araç gerçek bir sorunu çözüyor mu?
- Takasları iyi anlıyor muyuz?
Bu iki soruya kendinizden emin bir şekilde cevap veremiyorsanız, birkaç adım geriye çekilin ve düşünün.
Peki MongoDB doğru seçim miydi? Tabii ki evet; Çoğu mühendislik teknolojisinde olduğu gibi bu da birçok faktöre bağlıdır. Bu iki soruyu cevaplayanların birçoğu MongoDB'den faydalandı ve faydalanmaya devam ediyor. Bunu yapmayanlar için umarım abartılı döngüden geçme konusunda değerli ve çok da acı verici olmayan bir ders almışsınızdır.
sorumluluk reddi
MongoDB ile ne aşk ne de nefret ilişkim olmadığını açıklığa kavuşturmak istiyorum. MongoDB'nin çözmeye en uygun olduğu türde sorunlarla karşılaşmadık. 10gen/MongoDB Inc.'in olduğunu biliyorum. İlk başta çok cesurdu, güvenli olmayan varsayılanlar belirledi ve MongoDB'yi her yerde (özellikle hackathonlarda) her türlü veriyle çalışmak için evrensel bir çözüm olarak tanıttı. Muhtemelen kötü bir karardı. Ancak burada açıklanan yaklaşımı doğruluyor: Bu sorunlar, teknolojinin yüzeysel bir değerlendirmesiyle bile çok hızlı bir şekilde tespit edilebiliyor.
Kaynak: habr.com