İlişkisel bir veritabanına kıyasla MongoDB gibi şemasız bir veritabanı kullanmanın avantajları nelerdir?

MySQL veya PostgreSQL gibi ilişkisel veritabanlarını kullanmaya alışkınım ve Symfony, RoR veya Django gibi MVC çerçeveleriyle birleştiriyorum ve harika çalıştığını düşünüyorum.

Ancak son zamanlarda ilişkisel olmayan bir veritabanı olan MongoDB hakkında çok şey duydum veya resmi tanımdan alıntı yapacak olursak ,

ölçeklenebilir, yüksek performanslı, açık kaynaklı, şema içermeyen, belge odaklı bir veritabanı.

Gerginlikle gerçekten ilgileniyorum ve bir sonraki proje için sahip olacağım tüm seçeneklerden haberdar olmak ve oradaki en iyi teknolojileri seçmek istiyorum.

MongoDB'yi (veya benzer veritabanlarını) kullanmak hangi durumlarda "klasik" ilişkisel veritabanları kullanmaktan daha iyidir? Ve genel olarak MongoDB'nin MySQL'e karşı avantajları nelerdir? Ya da en azından neden bu kadar farklı?

Belgelere ve / veya örneklere işaretçileriniz varsa, bunun da çok yardımı olacaktır.

Web uygulamaları oluşturmak için MongoDB'nin avantajlarından bazıları şunlardır:

1. Belge tabanlı bir veri modeli. Temel depolama birimi JSON, Python sözlükleri, Ruby karmaları vb. İle benzerdir. Bu, dizileri ve diğer belgeleri tutabilen zengin bir veri yapısıdır. Bu, genellikle tek bir varlıkta, birkaç tablonun ilişkisel bir veri tabanında düzgün şekilde temsil edilmesini gerektiren bir yapıyı temsil edebileceğiniz anlamına gelir. Verileriniz değişmez ise bu özellikle kullanışlıdır.
2. Derin sorgulama yeteneği. MongoDB, neredeyse SQL kadar güçlü olan belge tabanlı bir sorgu dili kullanarak belgeler üzerinde dinamik sorguları destekler.
3. Şema geçişi yok. MongoDB şema içermediğinden, kodunuz şemanızı tanımlar.
4. Yatay ölçeklenebilirliğe giden açık bir yol.

Daha iyi bir fikir edinmek için bu konu hakkında daha fazla bilgi edinmeniz ve onunla oynamanız gerekecek. İşte çevrimiçi bir demo:

http://try.mongodb.org/

Çok sayıda avantajı var.

Örneğin veritabanı şemanız daha ölçeklenebilir olacak, geçişler konusunda endişelenmenize gerek kalmayacak, kod yazmak daha keyifli olacak ... Örneğin işte modelimin kodlarından biri:

class Setting
  include MongoMapper::Document

  key :news_search, String, :required => true
  key :is_availaible_for_iphone, :required => true, :default => false

  belongs_to :movie
end

Anahtar eklemek, yalnızca bir kod satırı eklemektir!

Daha iyi ölçeklenebilirlik ve hız gibi uzun vadede ortaya çıkacak başka avantajlar da vardır.

... Ancak ilişkisel olmayan bir veritabanının ilişkisel bir veritabanından daha iyi olmadığını unutmayın . Veritabanınızda çok sayıda ilişki ve normalleştirme varsa, MongoDB gibi bir şey kullanmak çok az mantıklı olabilir. Her şey iş için doğru aracı bulmakla ilgili.

Şey daha ben bir göz alarak tavsiye ediyorum okumaya İçin " Neden Mongo Raylar Çerçeveleriyle ne Veritabanları olduğunu düşünüyorum ya da" bu yazı mongodb web sitesinde. Heyecanlanmak ve Fransızca konuşuyorsanız, MongoDB'yi sıfırdan nasıl kuracağınızı açıklayan bu makaleye bir göz atın .

Düzenleme: Neredeyse hakkında söylemeyi unuttum bu railscast tarafından Ryan . Bu çok ilginç ve hemen başlamak istemenizi sağlıyor!

Şemadan bağımsız olmanın avantajı, yükünüz ne olursa olsun boşa çıkarabilmenizdir ve hiç kimsenin bundan şikayet etmek veya yanlış olduğunu söylemek için herhangi bir zemini olmayacak olmasıdır.

Aynı zamanda, içine döktüğünüz her şeyin, bunu yaptıktan sonra tamamen anlamsız kaldığı anlamına da gelir.

Bazıları bunu büyük bir dezavantaj olarak nitelendirirken, bazıları yapmaz.

İlişkisel bir veritabanının iyi oluşturulmuş bir şemaya sahip olması gerçeği, veritabanında kaydedilenlere anlam eklememize olanak tanıyan, iyi kurulmuş bir dizi genişletme yüklemine sahip olmasının bir sonucudur. ayrıca bunu yapmamız için gerekli bir ön koşul.

İyi kurulmuş bir şema, genişleme yüklemleri olmadan ve genişleme ön işaretleri olmadan, kullanıcının içine doldurulmuş olandan herhangi bir anlam çıkarması mümkün değildir.

MongoDB bu hafta FLOSS Weekly'de yayınlandı - http://twit.tv/floss105 Benzer bir konsept kullanan bir veritabanı, başka bir FLOSS Weekly'de sunulan CouchDB'dir: http://twit.tv/floss36

@Marcgg tarafından sağlanan bağlantılara ek olarak bunları dinlemeye değer olduğunu düşünüyorum.

Projelerimde her iki veri tabanı ile çalıştıktan sonra Postgres ve Mongo ile olan deneyimim.

Postgres (RDBMS)

Postgres, gelecekteki uygulamalarınızda çok sayıda birleştirme gerektiren karmaşık bir şemaya sahipse veya tüm verilerin birbiriyle ilişkisi varsa veya ağır yazılarımız varsa önerilir. Postgres açık kaynaklıdır, daha hızlıdır, ACID uyumludur ve diskte daha az bellek kullanır ve JSON depolaması için de iyi performans gösterir ve 3 seviyeli işlem yalıtımı ile işlemlerin tam serileştirilebilirliğini içerir.

Postgres'te kalmanın en büyük avantajı, her iki dünyanın da en iyisine sahip olmamızdır. Verileri kısıtlamalar, tutarlılık ve hız ile JSONB'ye depolayabiliriz. Öte yandan, tüm SQL özelliklerini diğer veri türleri için kullanabiliriz. Altta yatan motor çok kararlıdır ve çok çeşitli veri hacimleri ile iyi başa çıkmaktadır. Ayrıca seçtiğiniz donanım ve işletim sistemi üzerinde çalışır. Tam işlem desteğinin yanı sıra NoSQL yetenekleri sağlayan Postgres, JSON belgelerini alan verileri üzerinde kısıtlamalarla depolar.

Postgres için Genel Kısıtlamalar

Postgres'i Yatay olarak ölçeklemek önemli ölçüde daha zordur, ancak yapılabilir.

Postgres ile hızlı okuma işlemleri tam olarak gerçekleştirilemez.

SQL Veri Tabanı YOK

Mongo DB (Kablolu Kaplan)

MongoDB, Postgres'i “yatay ölçek” boyutunda yenebilir. JSON'u depolamak, Mongo'nun yapmak için optimize edildiği şeydir. Mongo, verilerini BSONb adı verilen ikili bir biçimde saklar; bu (kabaca), JSON'un bir üst kümesinin yalnızca bir ikili temsilidir. MongoDB, nesneleri tam olarak tasarlandıkları gibi saklar. MongoDB'ye göre, yazma yoğun uygulamalar için Mongo, yeni motorun (Wired Tiger) kullanıcılara yazma performansında 10 kata kadar artış sağladığını (bunu denemeliyim), depolama kullanımında yüzde 80 azalma sağladığını ve depolama maliyetlerinin düşürülmesine yardımcı olduğunu söylüyor. , donanımdan daha fazla yararlanın.

MongoDb'nin Genel Kısıtlamaları

Şema daha az depolama motorunun kullanılması, örtük şemalar sorununa yol açar. Bu şemalar depolama motorumuz tarafından tanımlanmaz, bunun yerine uygulama davranışına ve beklentilerine göre tanımlanır.

Bağımsız NoSQL teknolojileri, yapılandırılmamış uygulamalar için yüksek üretim performansı lehine kritik veri korumalarından ödün verdikleri için ACID standartlarını karşılamaz. ACID'yi NoSQL veritabanlarına uygulamak zor değildir, ancak veritabanını bir dereceye kadar yavaş ve esnek olmayacaktır. "NoSQL sınırlamalarının çoğu, önceki sınırlamalarını büyük ölçüde aşan yeni sürümlerde ve sürümlerde optimize edildi".

Her şey değiş tokuşlarla ilgili. MongoDB hızlıdır ancak ACID değildir, hiçbir işlemi yoktur. Bazı kullanım durumlarında MySQL'den daha iyi ve bazılarında daha kötüdür.

MongoDB'de Yazılan Körük Çizgileri: Kesin Kılavuz.

Birkaç iyi neden var:

1. Farklı türdeki belgeleri aynı koleksiyonda tutmak, geliştiriciler ve yöneticiler için bir kabus olabilir. Geliştiricilerin, her sorgunun yalnızca belirli türdeki belgeleri döndürdüğünden veya bir sorguyu gerçekleştiren uygulama kodunun farklı şekillerdeki belgeleri işleyebildiğinden emin olmaları gerekir. Blog gönderilerini sorguluyorsak, yazar verilerini içeren belgeleri ayıklamak zordur.
2. Bir koleksiyon listesi almak, bir koleksiyondaki türlerin bir listesini çıkarmaktan çok daha hızlıdır. Örneğin, koleksiyonda her belgenin "gözden kaçan", "bütün" veya "tıknaz maymun" belgesi olup olmadığını söyleyen bir tür anahtarımız olsaydı, bu üç değeri tek bir koleksiyonda bulmaktan çok daha yavaş olurdu üç ayrı koleksiyona sahip olmak ve adlarını sorgulamak
3. Aynı türden belgelerin aynı koleksiyonda gruplandırılması, veri konumuna izin verir. Yalnızca gönderi içeren bir koleksiyondan birkaç blog gönderisi almak, gönderileri ve yazar verilerini içeren bir koleksiyondan aynı gönderileri almaya göre muhtemelen daha az disk arama gerektirecektir.
4. Dizinler oluştururken belgelerimize bazı yapılar yüklemeye başlarız. (Bu, özellikle benzersiz dizinler durumunda geçerlidir.) Bu dizinler koleksiyon başına tanımlanır. Aynı koleksiyona sadece tek tipteki dokümanları koyarak, koleksiyonlarımızı daha verimli bir şekilde indeksleyebiliriz

Metin depolamalı veritabanları sorusundan sonra, MongoDB ve benzeri sistemlere göz attım.
Doğru anladıysam, kullanımı ve kurulumu daha kolay ve çok daha hızlı olmalıydı. Belki de SQL eksikliği SQL enjeksiyonunu engellediğinden daha güvenli ...
Görünüşe göre MongoDB çoğunlukla Web uygulamaları için kullanılıyor.
Temel olarak ve kendilerinin, bu veritabanlarının karmaşık sorgular, veri madenciliği vb. İçin uygun olmadığını belirtiyorlar. Ancak, çok sayıda düz veriyi hızla geri getirmede parlıyorlar.

1. MongoDB, alanlara göre aramayı, düzenli ifade aramalarını destekler. Kullanıcı tanımlı java komut dosyası işlevlerini içerir.
2. MongoDB, dosyaları depolamak için birden çok makinede yük dengeleme ve veri çoğaltma özelliklerinden yararlanarak bir dosya sistemi olarak kullanılabilir.