Numberly has been using both ScyllaDB and MongoDB in production for 5+ years. Learn which NoSQL database they rely on for different use cases and why. NoSQL alanında, ScyllaDB ve MongoDB iki tamamen farklı hayvanlardır. MongoDB bir tanıtım gerektirmez. Basit kabul ve geniş bir topluluk / ekosistem ile başlamak için de facto standart haline gelmiştir. ve sayısız web uygulamalarını güçlendirmek. ScyllaDB'nin metal yakınındaki mimarisi, yüksek geçişte öngörülebilir düşük gecikme sağlar. ve Bazıları da büyüdüğünde ve mevcut veri tabanları ile duvarı vurmak. Nükleer çelişki Traktör Data Intensive Uygulamaları Bunun yerine, bu iki belirgin olarak farklı veritabanının aynı teknoloji kümesi içinde nasıl birlikte var olabileceğine bir göz atalım – temel olarak nasıl farklı oldukları ve her birinin en iyi kullanım durumları. Farklı ayakkabılar maraton koşusu vs. Everest'i ölçmek vs. düğününe katılmak için daha iyi çalıştığı gibi, farklı veritabanlar farklı çalışma yükleri ve gecikme / geçiş beklentileri ile farklı kullanım durumları için daha iyi çalışır. Ne zaman ScyllaDB vs. MongoDB kullanmalısınız ve neden? Tedarikçi bakış açısı sunmak yerine, ScyllaDB ve MongoDB'yi üretimde kullanarak geniş deneyime sahip açık kaynaklı bir hayranın fikirlerini paylaşacağız: Alexys Jacob, Numberly'nin CTO'su. Alexys, ScyllaDB Summit 2019'da bakış açığını paylaştı. İşte ayrıntılı teknoloji konuşmasından üç ana alıntı: Scaling Writes MongoDB'de Daha Karmaşık MongoDB topolojisinin temel birimi, birincil bir düğümden ve genellikle çok sayıda ikincil düğümlerden oluşan bir kopya kümesi olarak adlandırılır (sıcak kopyaları düşünün). Verileri yazmak için yalnızca birincil düğüm izin verilir. MongoDB'de dikey yazma ölçeklenmesinden sonra, ölçeklenmek için tek seçeneğiniz bir bölünmüş bir kümesi olarak adlandırılır. Bu, tek bir kopya kümesinde çok sayıda birinciliğe sahip olamayacağınız için yeni bir kopya kümesi eklemeyi gerektirir. MongoDB'nin replika setleri arasındaki verileri bölmek, her replika setinin hangi verilerden sorumlu olduğunu belirlemek için özel bir anahtar kullanmak ve aynı zamanda her replika üzerinde hangi veri parçalarının yaşadığını izleyen bir metadata replika setinin oluşturulması gerekmektedir (aşağıdaki grafikteki mavi üçgen). Ayrıca, bir MongoDB kümesine bağlanmak için müşterilerin hangi düğmeyi yönlendireceğini belirlemesine yardımcı olması gerekir. MongoDB'de Yazıların Boyama Karmaşıklığı Tüm bu düğmelere sahip olmak daha yüksek işletme ve bakım maliyetlerine ve kayıp kaynaklara yol açar, çünkü Alexys'in belirttiği gibi kopya düğmeleri için IO'ya dokunamazsınız, bu da bölünmüş MongoDB kümelerini toplam mülkiyet maliyetinizin en kötü düşmanı yapar. ScyllaDB için, ölçüm yazılar çok daha basittir. “ScyllaDB tarafında, daha fazla geçiş eklemek istiyorsanız, sadece düğmeleri ekleyin. hikaye sonu.” Alexys bu aşamalı thread'i bağladı: “Lütfen MongoDB kümeleri oluşturmaktan kaçının! Bu konudaki savaş hikayeleri ile bir kitap yazabilirim. Nedenin ana nedeni, MongoDB'nin iş yükünü CPU'lara bağlamadığı gerçeğidir. Ve bir kümedeki replika kümeleri arasındaki verilerin dağılımı, bir arka plan çalışması (bilansatör) tarafından yapılır. Bu bilansatör her zaman çalışıyor, her zaman bölünmenin nasıl yapılacağına bakıyor ve her zaman verilerin kümede yayılmasını ve dengelenmesini sağlamaktadır. Bu, tutarlı hashing üzerine kurulmadığı için doğal değildir. Bu, tekrar tekrar tekrar hesaplanmalı bir şeydir. Verileri parçalara bölüyor ve daha sonra etrafta hareket ediyor. Bu, MongoDB kümelerinizin performansına doğrudan bir etkiye sahiptir, çünkü bu iş yük MongoDB, performans üzerinde esnekliği tercih ederken, ScyllaDB, çok yönlü performansı tercih eder ScyllaDB ve MongoDB, esneklik ve performans açısından farklı önceliklere sahiptir. Veri modelleme önünde, MongoDB doğal olarak coğrafi sorgular, metin arama, birleştirme borular, grafik sorguları ve değişim akışları destekler. ScyllaDB – geniş sütun depolama (a.k.a. anahtar-değer) – kullanıcı tanımlı türleri, sayıcıları ve hafif işlemleri desteklerken, veri modelleme seçenekleri MongoDB’den daha kısıtlıdır. Alexys, “Geliştirme açısından, bir JSON nesnesi ile etkileşim yapmak sadece bir satırla etkileşimden daha doğal hissediyor.” ScyllaDB verileri eklemeden önce şema doğrulamasını yürütme Bu veriler belirlenmiş şemaya uymaktadır. seçeneği İhtiyaç Soruşturma MongoDB ile de daha basittir, çünkü sadece JSON ile filtreleme ve etkileşim kuruyorsunuz. Ayrıca daha esnektir, daha iyi ya da daha kötü. MongoDB, üretim iş yükünüzle suboptimal performanslara neden olan sorular da dahil olmak üzere, herhangi bir soru türünü yayınlamanıza izin verir. ScyllaDB buna izin vermez. Eğer denerseniz, ScyllaDB sizi uyarır. Alexys, gelişme bakış açısından temel farklılıkları özetledi: “MongoDB, performans üzerinde esnekliği tercih eder. İlişki etmek kolaydır ve sizin yolunuzda olmayacaktır. Ama performans üzerinde etkisi olacak – bazı iş yükleri için iyi ama diğerleri için kabul edilemez etkiler. Diğer taraftan, ScyllaDB, çok yönlü performans üzerinde tutarlı performans tercih eder. Dışarıdan biraz daha sabit ve biraz daha katı görünüyor. Ama yine de, bu, tutarlı performans, iyi çalışabilir ve sistemle iyi etkileşime girebileceğiniz için kendi iyiliğiniz için. Benim görüşümde, bu, gecikme ve performans duyarlı iş yüklerinizde gerçek bir fark yaratır.” Performans en iyi uygulamaları takip eden sorguların bile MongoDB'de ScyllaDB'de olduğundan farklı davranacağına dikkat etmek önemlidir.Ne kadar dikkatli olursanız olun, temel mimari farklılıklardan kaynaklanan performans cezasını aşmayacaksınız. Birlikte, ScyllaDB ve MongoDB büyük bir NoSQL Combo “Bu bir ölüm karşılaşması değil; MongoDB ve ScyllaDB’nin mutlu kullanıcılarıyız,” dedi Alexys. Numerly, her kullanım durumunun teknik gereksinimleri için en iyi veritabanını seçer. Numerly'de, MongoDB iki tür kullanım vakası için kullanılır: REST API'leri ve olası olarak esnek şemaları ile web backendleri. Tahmin edilemez davranış verileri hakkında gerçek zamanlı sorgular. Örneğin, Numerly'nin bazı uygulamaları, müşterilerinin topladığı ve gönderdiği web izleme verileriyle doludur (her bir müşteri kendi içsel olarak geliştirilen uygulamalarıyla). Numerly'in bu verilere sıkı bir şemayı uygulamak için bir yolu yoktur, ancak sorgulama ve işleme yeteneğine ihtiyaç vardır. Alexys'in sözlerine göre, "MongoDB burada iyi; esnekliği avantajlıdır çünkü verileri bir yerde saklamayı ve kolayca sorgulamayı sağlar." ScyllaDB, Numerly'de üç tür kullanım vakası için kullanılır: Gerçek zamanlı gecikme duyarlı veri borular. Bu, veri borularında gerçek zamanlı olarak ilişkilendirilmesi gereken çok sayıda veri kaynağı olan çok sayıda veri zenginleştirilmesini içerir. Alexys’e göre, “Bu yapmak zordur... ve müşterilerinizin boru hattına bağlı olduğu uygulamaların ve veri işlemlerinin SLA’larını kırmamak için güçlü gecikme garantilerine ihtiyacınız vardır.” Numerly ayrıca ScyllaDB'de çok sayıda seri ve gerçek zamanlı çalışma yükünü karıştırır, çünkü her iki dünyadaki en iyisini sağlar (Numerly'nin daha önce paylaştığı gibi). "Bir yoldan Hive'i ve diğer yoldan MongoDB'yi kullandık. her şeyi ScyllaDB'ye ve sürdürülebilir Hadoop benzeri seri çalışma yüklerine ve gerçek zamanlı boru hattı iş yüklerine koyduk." Bazı Numerly web backend'leri GraphQL'de uygulanır. şemaya dayalı API'lerle çalışırken, düşük gecikme ve yüksek kullanılabilirlik ile şemaya dayalı bir veritabanına sahip olmak mükemmel bir mantıktır. Alexys, “Bakend mühendislerimizden ve ön bölüm mühendislerimizden birçoğu da ScyllaDB’yi kabul ediyor. ScyllaDB’yi kabul eden insanların bir eğilimi görüyoruz, giderek daha fazla teknoloji insanı ‘bu kullanım örneği var, ScyllaDB’yi iyi bir şekilde kullanabilir miyim?’ diye soruyor. Çoğu zaman, cevabı ‘evet.’ Bonus: Alexys Jacob'dan Daha Fazla Görüş Alexys, hem kod hem de konferans konuşmaları açısından açık kaynak topluluklarına son derece cömert bir katkıda bulunur. https://ultrabug.fr/ Hakkında Cynthia Dunlop Hakkında Cynthia, ScyllaDB'de içerik stratejisi üst düzey direktörüdür ve 20 yıldan fazla bir süredir yazılım geliştirme ve kalite mühendisliği hakkında yazıyor.
