DynamoDB vs MongoDB NoSQL [kapalı]

Gelecekteki bir proje için neleri kullanabileceğimi anlamaya çalışıyorum, ilk yılda ayda yaklaşık 500 bin kayıt depolamayı planlıyoruz ve belki de gelecek yıllar için bu dikey bir uygulamadır, bu nedenle Bunun için bir noSQL veri depolama seçmeye karar verdim nedeni budur.

Aklıma gelen ilk seçenek mongo db oldu çünkü topluluktan çok destek alan çok olgun bir ürün ama diğer taraftan en iyi performansta yönetilen bir hizmet sunan yepyeni bir ürün aldık, bunu geliştireceğim uygulama ama bakım planı (en azından şimdilik) bu yüzden amazon ölçeklendirmek için elastik bir yol sağladığı için bu büyük bir avantaj olacağını düşünüyorum.

Benim büyük endişe sorgu yapısı hakkında, henüz dynamoDB sorgu yetenekleri bakmadım ama ak / v veri depolama beri bu mongo db daha sınırlı olabilir hissediyorum.

Birisi bir projeyi mongoDB'den DynamoDB'ye taşıma deneyimine sahip olsaydı, herhangi bir tavsiye tamamen takdir edilecektir.

Kısa süre önce MongoDB'mi DynamoDB'ye taşıdım ve performans, maliyetle ilgili bazı deneyim ve verileri paylaşmak için 3 blog yazdım.

MongoDB'den AWS DynamoDB + SimpleDB'ye geçiş

MongoDB'yi DynamoDB Üzerinde Kullanmanız İçin 7 Neden

MongoDB Üzerinde DynamoDB Kullanmanız Gereken 3 Neden

Bunun eski olduğunu biliyorum, ancak karşılaştırmayı aradığınızda hala ortaya çıkıyor. Mongo'yu kullanıyorduk, neredeyse tamamen bizim ilk tercihimiz olan Dinamo'ya taşındık. Daha fazla özelliği olduğu için değil. Mongo'nun daha iyi bir sorgu dili vardır, bir yapı içinde indeksleyebilirsiniz, birçok küçük şey var. Dinamo'nun üstünlüğü OP'nin yorumunda belirttiği şeydir: kolay. Herhangi bir sunucuya bakmak zorunda değilsiniz. Mongo parçalanmış bir çözüm kurmaya başladığınızda, karmaşıklaşır. Hosting şirketlerinden birine gidebilirsiniz, ama bu da ucuz değil. Dinamo ile daha fazla verime ihtiyacınız varsa, bir düğmeyi tıklamanız yeterlidir. Otomatik olarak ölçeklemek için komut dosyaları yazabilirsiniz. Dinamoyu yükseltmenin zamanı geldiğinde, iş senin için bitti. Bu çok değerli stres ve zaman harcanmamış. Eğer yapmazsan

Şimdi varsayılan olarak Dinamo'ya gidiyoruz. Mongo belki, eğer veri yapısı onu garanti edecek kadar karmaşıksa, ama muhtemelen bir SQL veritabanına geri döneceğiz. Dinamo geniş, gerçekten nasıl inşa edeceğinizi düşünmeniz gerekiyor ve muhtemelen karmaşık şeyler için çalışmasını sağlamak için Redc'i Rubbercache'de kullanacaksınız. Ama bununla ilgilenmemek güzel. Siz kodlayın. Bu kadar.

500 bin belge ile ölçeklendirmek için hiçbir neden yoktur. SSD ve 8GB ram'a sahip tipik bir dizüstü bilgisayar kolayca 10 milyonlarca kayıt yapabilir, bu nedenle ölçeklendirme nedeniyle seçmeye çalışıyorsanız, seçiminiz gerçekten önemli değildir. En çok neyi beğendiğinizi ve belki de en çok çevrimiçi desteği nerede bulabileceğinizi seçmenizi öneririm.

Hızlı genel bakış karşılaştırmaları için, birçok karşılaştırma sayfası olan bu web sitesini çok beğendim, örneğin AWS DynamoDB vs MongoDB; http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB

Kısa cevap: SQL ile başlayın ve yalnızca gerektiğinde / gerekiyorsa NoSQL ekleyin. (çok basit sorguların ötesinde bir şeye ihtiyacınız yoksa)

Kişisel deneyimim: Sorgular için MongoDB kullanmadım ancak Nisan 2015 itibarıyla DynamoDB, en temel anahtar / değer sorgularının ötesinde bir şey söz konusu olduğunda hala çok sakat. Ben temel şeyler için seviyorum ama sorgu dili istiyorsanız o zaman gerçek bir SQL veritabanı çözümüne bakın.

DynamoDB'de bir karma veya karma ve aralık anahtarında sorgulama yapabilir ve birden çok ikincil global dizine sahip olabilirsiniz. Ben 4 olası filtre parametreleri ile tek bir tabloda sorgular yapıyorum ve sonuçları sıralama, bu (ancak) küresel ikincil dizinleri filtre ifadeleri ile desteklenmektedir. Sorun, filtreyle eşleşen toplam sonuçları elde etmeye çalıştığınızda ortaya çıkar, yalnızca filtreyle eşleşen ilk 10 öğeyi arayamazsınız, bunun yerine 10 öğeyi kontrol eder ve sizi yeniden tutmaya zorlayan 0 geçerli sonuç alabilirsiniz. devam anahtarından tarama - boyunda ağrı ve basit bir senaryo için masanızın okuma kotasını çok fazla tüketir.

Sorgudaki filtrelerle ilgili sınır sorunu hakkında açık olmak gerekirse, bu dokümanlardan ( http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit ):

Yanıt olarak DynamoDB, eşleşen tüm sonuçları
Limit değerinin kapsamı. Örneğin, bir Sorgu yayınlarsanız
veya Sınır değeri 6 olan ve filtresiz bir Tarama isteği
ifadesi, işlemin ilk altı öğeyi döndürür 
istek parametreleriyle eşleşen tablo. Ayrıca bir
FilterExpression, işlem içindeki öğeleri döndürür 
tablodaki filtre gereksinimlerine uyan ilk altı öğe.

Benim sonucum, FilterExpressions içeren sorguların çok nadir durumlarda kullanılabilir ve ölçeklenebilir olmamasıdır, çünkü her sorgu çok fazla DynamoDB okuma birimi tüketen tablonuzun çoğunu veya tamamını kolayca okuyabilir. Çok fazla okuma birimi kullandıktan sonra kısıtlanır ve düşük performans görürsünüz.

Uzman görüşü: 9 Nisan 2015'teki AWS zirvesinde, Çözüm Mimarisi, AWS Müdürü Brett Hollman, ilk 10 milyon kullanıcısını korkutmak konusundaki konuşmasında bir SQL veritabanından başlayıp daha sonra NoSQL'i sadece mantıklı olduğunda ve kullanıldığında savunuyor. Çünkü er ya da geç yığınınızda bir yerde bir SQL sunucusuna ihtiyacınız olacaktır. Slaytları burada: http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users Bkz. Slayt 28.

Bir sağlık ürünü için Mongo / Dynamo'nun bir kombinasyonunu seçtik. Temel olarak mongo daha iyi aramaya izin verir, ancak barındırılan Dynamo harikadır, çünkü HIPAA uyumlu herhangi bir ekstra çalışma olmadan uyumludur. Bu nedenle, standart bir kurulumda hiçbir kişisel veri içermeyen mongo bölümünü barındırıyoruz ve amazon'un altyapı açısından HIPAA kısmı ile baş etmesine izin veriyoruz. Moğoldan, ilişkilendirilebilir Dinamo belgesinin işaretçileriyle (ID'ler) belgeler getiren belirli öğeleri sorgulayabiliriz.

Dinamo tüm uygulama barındırma yerine mongo kullanarak bunu seçtik ana nedeni 2 nedenden dolayı oldu. Birincisi, Dynamo'nun iyi olmadığı ve o sırada büyük olan mongo'nun bulunduğu yere dayalı aramalar yapmamız gerekiyordu, ancak şimdi bir seçenekleri var.

İkincisi, bazı belgelerin yapılandırılmamış olmasıydı ve verilerin ne olacağını önceden bilmiyorduk, örneğin, kullanıcının "form" koleksiyonuna şu şekilde bir belge girdiğini söyleyelim: {"kullanıcı adı": "kullanıcı1", " e-posta ":" me@me.com "}. Ve başka bir kullanıcı bunu aynı koleksiyona yerleştirir {"phone": "813-555-3333", "location": [28.1234, -83.2342]}. Mongo ile bu dinamik ve bilinmeyen alanlardan herhangi birini istediğimiz zaman arayabiliriz, Dinamo ile bunu yapabilirsiniz, ancak aranabilir olmasını istediğiniz her yeni alan eklendiğinde bir dizin oluşturmanız gerekir. Dynamo belgenizde daha önce hiç telefon alanınız olmadıysa ve sonra birdenbire, bazıları bunu ekleyemez, tamamen araştırılamaz.

Şimdi bu, bahsettiğiniz başka bir noktayı gündeme getiriyor. Bazen iş için doğru çözümü seçmek her zaman iş için en iyi ürünü seçmek anlamına gelmez. Örneğin, oluşturduğunuz sisteme 10 yıldan fazla ihtiyaç duyan ve kullanacak bir müşteriniz olabilir. İşlerini halletmek için yeterince iyi bir SaaS / IaaS çözümü ile gitmek, sistemlerini uzun vadede tutmak ve korumak için amazon'a güvenebileceğiniz için daha iyi bir seçenek olabilir.

Hem ikisi de hem de hayranları üzerinde çalıştım.

Ama ne zaman ve ne amaçla kullanacağınızı anlamalısınız.

Tüm veritabanınızı DynamoDB'ye taşımak harika bir fikir değil, birincil ve ikincil anahtarlar dışında sorgulama yapmak zor, Dizinleme sınırlıdır ve DynamoDB'de tarama acı vericidir.

Kapsamlı sorgu-güçlü veri MongoDB olması gereken DB melez bir tür için gitmek istiyorum, tüm özellikleri ile asla geliştirme veya değişiklik sağlamak için kısıtlanmış hissediyorum.

DynamoDB şimşek hızında (MongoDB'den daha hızlı) yıldırımdır, bu nedenle DynamoDB genellikle ölçeklenebilir uygulamalardaki oturumlara alternatif olarak kullanılır. DynamoDB en iyi uygulamaları, daha az kullanılan çok fazla veri varsa, bunu diğer tabloya taşıdığını gösterir.

Bir makaleniz veya özet akışınız olduğunu varsayalım. İnsanların geçen hafta veya bu ayın eşyalarını arama olasılığı daha yüksektir. İnsanların iki yıllık verileri ziyaret etme şansı çok nadirdir. Bu amaçlar için DynamoDB, verilerin aylara veya yıllara göre farklı tablolarda saklanmasını tercih eder.

DynamoDB görünüşte ölçeklenebilir, MongoDB'de manuel olarak yapmanız gerekecek. ancak iş bölümü ve ölçeklemenin sahnenin arkasında nasıl çalıştığını bilmiyorsanız, DynamoDB'nin performansını kaybedersiniz.

DynamoDB, hızın kritik olduğu yerlerde kullanılmalıdır, diğer yandan MongoDB'nin çok fazla el ve özelliği var, DynamoDB'de eksik bir şey var.

örneğin, kopyadan birinin 8 (veya herhangi bir) saatlik veri örneğini içerecek şekilde bir MongoDB çoğaltma kümesine sahip olabilirsiniz. Eğer DB büyük bir zaman berbat ve veri eskisi gibi almak istiyorsanız, gerçekten yararlı.

Bu benim görüşüm.

Unutmayın, sadece MongoDB ile denemeler yaptım ...

Okuduğum kadarıyla, DynamoDB özellikler açısından çok yol kat etti. Son derece sınırlı depolama ve sorgulama özelliklerine sahip süper temel bir anahtar / değer deposu idi. O zamandan beri büyüdü, şimdi daha büyük belge boyutları + JSON desteği ve küresel ikincil endeksleri destekliyor . DynamoDB ve MongoDB'nin özellikler açısından sundukları arasındaki fark her ay artıyor. DynamoDB'nin yeni özellikleri burada genişletildi .

MongoDB ve DynamoDB karşılaştırmalarının çoğu, son zamanlarda DynamoDB özelliklerinin eklenmesi nedeniyle güncel değildir. Ancak, bu yazı DynamoDB'yi seçmek için başka ikna edici noktalar sunuyor, yani basit, düşük bakım ve genellikle düşük maliyet. Burada veritabanı seçimlerinin bir başka tartışması biraz eski olsa da okumak ilginçti.

Paketim: ciddi veritabanı sorguları yapıyorsanız veya DynamoDB tarafından desteklenmeyen dillerde çalışıyorsanız, MongoDB kullanın. Aksi takdirde, DynamoDB ile devam edin.