Bütün NoSQL olayı hakkında biraz kafam karıştı. Ne zaman Oracle veya MySQL gibi bir şey üzerinde MongoDB gibi bir şey kullanmayı tercih edersiniz? Kullanımlar arasında gidince "farkı" gerçekten anlamıyorum.
Anladığım kadarıyla, NoSQL tipi veritabanları RDBMS'lerin yerini almayı amaçlamıyor, ancak tam olarak ne yapmaları gerekiyor?
Daha önce üç evcil hayvan projesi için CouchDB kullandım.
Bunu MSSQL veya MySQL gibi bir şeyden seçmemizin ana nedeni, kullanırken elde ettiğiniz esnekliktir. Katı şema yok. Çizgiden üç ay sonra fazladan bir alana sahip olmak için belirli bir masaya ihtiyacınız varsa ve bu ve bunu değiştirirsiniz ve oradan dışarı çıkar.
Nasıl kullanılacağını öğrenmek için Apress tarafından Beuchning CouchDB kullandım.
Örneğin, CouchDB veritabanına/veritabanından iletişim kurmak için json kullanır. Diliniz POST veri ise, o zaman DB ile iletişim kurmak için kullanabilirsiniz.
Ayrıca okuyun: Neden ilişkisel veritabanı yerine belge tabanlı veritabanı kullanmalıyım? StackOverflow üzerinde
Başka bir cevap eklediğim için üzgünüm, ancak buradaki yanıtların hiçbiri çok tatmin edici değil. Bu cevap MongoDB'ye özgüdür (ilişkisel veritabanları olmayan diğer veri depolama seçeneklerinin aksine).
Artıları:
Eksileri:
Yanlış Anlaşılan Puanlar:
Utanmadan Renesis 'dan çalmak için (aslında bu cevabı CW yapıyorum):
Diğer türler yerine RDBMS'leri kullanma:
Verileriniz ilişkisel olmadığında, performans ve ölçeklenebilirlik (elbette koşullara bağlı olarak) gibi NoSQL veritabanlarını kullanmanın büyük faydaları olabilir. CQRS gibi bazı tasarım kalıpları, geleneksel olarak bir SQL veritabanının özel olarak kullanılmasını gerektiren alanlarda ilişkisel olmayan verilerden yararlanmayı çok daha kolay hale getirir.
Önbelleğe alınmış veriler için mongo gibi veritabanlarının kullanılması yaygındır. Örneğin, bir rapor oluşturmanız gerekiyorsa, bir grup veriyi anında birleştiren ve toplayan karmaşık bir SQL sorgusu yapabilirsiniz veya mongo veritabanınızdan zaten oluşturmanız gereken her şeye sahip tek bir json belgesi alabilirsiniz rapor. Bu, veri okumayı gerçekten (ve hızlı!) Yapar, ancak veri yazma işlemini oldukça karmaşık hale getirebilir (CQRS burada devreye girer).
MongoDB gibi veritabanları genellikle verilerinizin nerede olduğunu bildiğinizde mükemmeldir (birkaç karmaşık sorgu yazmanın aksine). Moğol ile "ilgili" veriler ya üst verilerde iç içe ya da birincil/yabancı anahtarlara sahiptir. Örneğin, Yazılarınız ve Yorumlarınız varsa bu harikadır; genel olarak, yorumları bir gönderinin bağlamı dışında göstermeyeceksiniz, bu nedenle yorumların bir gönderinin içinde yer alması mantıklıdır (bu şekilde yazı için tüm yorumları ayrı bir tablo sorgulamaya gerek kalmadan alırsınız).
MongoDB şematiktir. Bu, ona attığınız verilerin yapısını çoğunlukla alacak anlamına gelir.
Öte yandan, toplu işlevleri kullanmanız ve verileri Mongo'daki yerleştirmeler veya basit ilişkiler yoluyla gerçekleştirilemeyen karmaşık yollarla sorgulama gereksiniminiz varsa, o zaman MySQL veya PostgreSQL gibi bir RDBMS kullanmanın zamanı geldiğini bilirsiniz.
MongoDB, SQL'in yerini almaz. Sadece farklı ihtiyaçları karşılar ve MongoDB ve RDBMS birlikte kullanılabilir. Bence, verilerinizin esnek veya bir üst belgeye gömülmesi gerekmiyorsa, MongoDB o kadar da gerekli değildir. MongoDB ile geliştirme çok eğlencelidir, çünkü bir projeyi (örneğin Rails'te) hazırlayıp çalıştırmak için çok daha az adım vardır. Değişiklik yapmanız mı gerekiyor? Sorun değil. Sadece modelinize bir özellik ekleyin. Bitti.
Diğer birçok NoSQL veritabanı için konuşamıyorum, ancak genellikle benzer şekilde bir RDBMS tarafından karşılanamayan belirli bir ihtiyacı karşılamak için tasarlanmış olduklarını biliyorum. Bazıları tamamen bellekte bulunur veya kolayca kırılabilir veya ölçeklenebilir. Cassandra bir düğüm düşerse veri kaybı olmadan çalışmaya devam etmek için tasarlanmıştır eminim. Redis temelde bellekte bulunan bir anahtar değer deposu (periyodik disk kalıcılık için yazar), aynı zamanda kümeler gibi veri türlerini saklama ve sıralama yeteneğine de sahiptir.
En büyük kazanç, verileri parçalamak veya çoklu ana veritabanlarına sahip olmak istediğiniz zamandır. MySQL'deki verileri parçalayabilirsiniz, ancak büyük bir acıya dönüşür. Çok sayıda yazma işlemi yapıyorsanız, verileri birden fazla sunucuda parçalamak genellikle yararlıdır, sorun şu ki, güçlü referans tutarlılığına sahip olmak istiyorsanız, bu mümkün değilse CAP teoremini aramak çok zor olabilir.
SQL veritabanları çok iyi tutarlılığa sahiptir, ancak gerçekten kötü bölümleme desteği vardır, NoSQL veritabanları diğer tarafa gitme eğilimindedir. Bölünmesi kolaydır, ancak genellikle nihai tutarlılık denir. Tamam bir mesajlaşma sitesi inşa ediyorsanız, bir banka için muhtemelen Tamam değil.
Artı, artık verilerin nasıl saklanacağına dair birden fazla modelin bulunmasıdır, böylece her şeyi nasıl uygulayacağınız konusunda seçim yapabilirsiniz, daha önce SQL veritabanları vardı.
SE Radio bu konuda birkaç iyi bölüm geçirdi.
Çok fazla veri yazdığınızda ve sorgulama ihtiyaçlarınız çok karmaşık olmadığında MongoDB iyi çalışır. Bu nedenle, Komut tarafında Olay Sağlama ile CQRS uyguladığınızda MongoDB iyi bir seçimdir - yani, olay deponuz bir MongoDB veritabanıdır.
Sorgulama tarafında, esnekliği nedeniyle yine de görünümleri ve WCF Veri Hizmetleri olan bir SQL Server db kullanıyoruz. Çoğu durumda gerçekten sorgulama için ilişkisel bir DB gücüne ihtiyacınız olacağını düşünüyorum.
MongoDB ve RDBMS arasındaki anlık ve temel fark, temeldeki veri modelidir. İlişkisel bir veritabanı, verileri tablolara ve satırlara yapılandırırken MongoDB, verileri JSON belgeleri koleksiyonlarına dönüştürür. JSON kendi kendini tanımlayan, okunabilir bir veri formatıdır. Başlangıçta tarayıcı ve sunucu arasındaki hafif değiş tokuşlar için tasarlanmış olup, birçok uygulama türü için yaygın olarak kabul edilmiştir.
JSON belgeleri özellikle çeşitli nedenlerle veri yönetimi için kullanışlıdır. JSON belgesi, kendileri anahtar/değer çiftleri olan bir dizi alandan oluşur. Bu, her JSON belgesinin nereye giderse gitsin kendi insan tarafından okunabilen şema tasarımını taşıdığı ve belgelerin anlamlarını kaybetmeden veritabanı ve istemci uygulamaları arasında kolayca hareket etmesine izin verdiği anlamına gelir.
JSON ayrıca uygulama katmanında kullanım için doğal bir veri biçimidir. JSON, sütun ve satırlardan oluşan tablolardan daha zengin ve daha esnek bir veri yapısını destekler. Sayı, dize, Boole vb. Alan türlerini desteklemenin yanı sıra, JSON alanları diziler veya iç içe geçmiş alt nesneler olabilir. Bu, uygulamalarımızın üzerinde çalıştığı nesnelerin daha yakın bir temsili olan bir dizi karmaşık ilişkiyi temsil edebileceğimiz anlamına gelir. Veritabanımızda JSON belgeleri kullanmak, veritabanımızla hizmet ettiği uygulamalar arasında nesne ilişkisel eşleştiriciye ihtiyacımız olmadığı anlamına gelir. Verilerimizi doğru biçimde saklayabiliriz
Verileriniz çok fazla sorgulamaya ihtiyaç duyuyorsa, NoSQL çözümü iyi değildir ve işlem desteğine (ACID) ihtiyacınız olduğunda NoSql en uygun değildir. Sanırım hızlı olması gereken çok fazla okuma olduğunda ve yapı biraz adhoc olduğunda NoSQL parlıyor, belge veya sayfa yapısı, böyle bir şey ile alıyorsunuz. Ancak birçok NoSQL çözümü oldukça hızlı bir şekilde gelişir, bu nedenle yakında eksikler olabilir. Her neyse, ilişkisel veritabanlarının çoğu uygulama için hala iyi olduğunu düşünüyorum.