İlişkisel veritabanı yerine ne zaman NoSQL veritabanı kullanmalıyım? Her ikisini de aynı sitede kullanmak uygun mudur?


141

NoSQL veritabanlarını kullanmanın avantajları nelerdir? Son zamanlarda onlar hakkında çok şey okudum, ama neden bir tane uygulamak istediğimden ve hangi koşullar altında kullanmak istediğimden hala emin değilim.

Yanıtlar:


84

İlişkisel veritabanları zorlar ASİT . Böylece, şema tabanlı işlem odaklı veri depolarınız olacaktır. Gerçek dünya uygulamalarının% 99'u için kanıtlanmış ve uygundur. İlişkisel veritabanlarıyla pratik olarak her şeyi yapabilirsiniz.

Ancak, devasa yüksek kullanılabilirlikli veri depoları söz konusu olduğunda hız ve ölçeklendirme konusunda sınırlamalar vardır. Örneğin, Google ve Amazon'un büyük veri merkezlerinde depolanmış terabayt verileri vardır. RDBM'lerin engelleme / şema / işlem yapısı nedeniyle sorgulama ve ekleme bu senaryolarda gerçekleştirilmez. Bu nedenle, büyük performans artışı ve ölçeklenebilirlik için kendi veritabanlarını (aslında anahtar / değer depoları) uygulamışlardır.

NoSQL veritabanları uzun zamandır var - sadece terim yeni. Bazı örnekler grafik, nesne, sütun, XML ve belge veritabanlarıdır.

2. sorunuz için: Her ikisini de aynı sitede kullanmak uygun mudur?

Neden olmasın? Her ikisi de farklı amaçlara hizmet ediyor değil mi?


1
ACID'nin ilişkisel veritabanlarına özel olduğunu düşünmüyorum. İlişkisel olmayan veritabanlarında dayanıklılık garantileri, işlemler, görünüm tutarlılığı sağlayabilirsiniz.
Thilo

@RamshVel, anahtar / değer deposu türü veritabanına bir örnek verebilir misiniz? Teşekkürler.
Rachael

1
@Rachael, bazı örnekler redis, leveldb ve riak .. etrafında ton vardır, google yapabilirsiniz
RameshVel

76

NoSQL çözümleri genellikle ilişkisel veritabanlarının uygun olmadığı, kullanımı çok pahalı olduğu (Oracle gibi) veya db'nizin ilişkisel doğasını bozan bir şey uygulamanızı gerektiren bir sorunu çözmeyi amaçlamaktadır.

Avantajları genellikle kullanımınıza özgüdür, ancak verilerinizi bir RDBMS'de modellerken bir tür sorun yoksa, NoSQL'i seçmeniz için hiçbir neden göremiyorum.

Ben kendim bir RDBMS geçerli bir çözüm olmadığı belirli sorunlar için MongoDB ve Riak kullanın, MySQL (veya test için SQLite) kullandığım diğer tüm şeyler için.

Genellikle bildiğiniz bir NoSQL db'ye ihtiyacınız varsa , olası nedenler:

  • müşteri yüksek trafikli bir sitede% 99,999 kullanılabilirlik istiyor.
  • verileriniz SQL'de bir anlam ifade etmez, bazı bilgilere erişmek için birden fazla JOIN sorgusu yaptığınızı görürsünüz.
  • ilişkisel modeli bozuyorsunuz, denormalize verileri depolayan CLOB'larınız var ve bu verileri aramak için harici dizinler oluşturuyorsunuz.

Bir NoSQL çözümüne ihtiyacınız yoksa, bu çözümlerin bir RDBMS'nin yerine geçmesi anlamına gelmediğini, ancak eski başarısız olan alternatifleri ve daha da önemlisi, nispeten yeni olduklarını ve hala çok fazla hataya sahip olduklarını unutmayın. eksik özellikler.

Oh, ve ikinci soru ile ilgili olarak herhangi bir teknolojiyi başka bir teknolojiyle birlikte kullanmak gayet iyi, bu yüzden deneyimlerimden eksiksiz olmak için MongoDB ve MySQL aynı makinede olmadıkları sürece birlikte iyi çalışıyor


3
Cevap için teşekkürler. NoSQL'in ne zaman kullanılacağına dair örnekleriniz en iyi ihtimalle belirsizdir. Verilerimden herhangi birinin daha iyi bir NoSQL veritabanında saklanıp saklanmayacağına karar verebilmem için daha spesifik bir kullanım durumu umuyordum.
smfoote

Aynı soruyu iki kez cevaplamamaya çalışıyorum, çok benzer bir soruya vermiş olduğum önceki cevaba bakıyorum stackoverflow.com/questions/3621415/…
Asaf

Asaf'ın büyük cevabına katılıyorum, RDBMS üzerinden NoSQL'e ihtiyacınız olduğunda gerçekten sadece birkaç senaryo var. Ben ana db daha bir yedek db veya "eklenti db" olarak NoSQL görüyorum. Çekirdek db'nin bir NoSQL olduğu iyi bir sistem görmedim.
Jo Smo

38

Martin Fowler, NoSQL veritabanlarının iyi bir açıklamasını veren mükemmel bir videoya sahiptir. Bağlantı doğrudan onları kullanma nedenlerine gidiyor, ancak tüm video iyi bilgiler içeriyor.

  1. Büyük miktarda verileriniz var - özellikle NoSQL iyi ölçeklendirilmek üzere tasarlandığından, hepsini tek bir fiziksel sunucuya sığdıramıyorsanız.

  2. Nesne-ilişkisel empedans uyuşmazlığı - Etki alanı nesneleriniz, göreli veritabanı şemasına iyi uymuyor. NoSQL, verilerinizi veri modelinize çok daha yakın eşleyebilecek belgeler (veya grafikler) olarak sürdürmenizi sağlar.


16

NoSQL, verinin belge (MongoDB), anahtar / değer çifti (MemCache, Redis), grafik yapı formu (Neo4J) şeklinde düzenlendiği veritabanı sistemidir.

Belki de "NoSQL ne zaman gidilir" için olası sorular ve cevaplar:

  1. Esnek şema mı istiyorsunuz yoksa ağaç benzeri veriler mi?
    Genel olarak, çevik geliştirmede, tüm gereksinimi bilmeden sistemi tasarlamaya başlarız, daha sonra geliştirme veritabanı sistemi boyunca MVP'yi (Minimal Viable ürün) sergileyen sık sık tasarım değişikliklerine ihtiyaç duyabilir. Veya doğası gereği dinamik olan veri şemasıyla uğraşıyorsunuz. Örneğin, Sistem günlükleri, çok kesin bir örnek AWS bulut saati günlükleridir.

  2. Veri seti muazzam / büyük mü?
    Evet NoSQL veritabanı, performanstan ödün vermeden milyonlarca hatta milyarlarca kaydı yönetmesi gereken uygulamalar için daha iyi bir adaydır.

  3. Tutarlılık üzerinde ölçeklendirme arasında
    değiş tokuş yapma RDMS'nin aksine, NoSQL veritabanı burada ve orada küçük veriler kaybedebilir (Not: olasılık% .x'dir), ancak performans açısından ölçeklendirilmesi kolaydır. Örnek: Bu, çevrimiçi olan kişileri anlık mesajlaşma uygulamasında, db'de jetonlar, web sitesi trafik istatistiklerini günlüğe kaydetmek için iyi olabilir.

  4. Coğrafi Konum İşlemleri Gerçekleştirme: GeoQuerying ve Coğrafi Konum operasyonları için MongoDB hash zengin desteği. MongoDB'nin bu özelliğini gerçekten çok sevdim.

Özetle, MongoDB dinamik yapılandırılmış verileri büyük ölçekte saklayabileceğiniz uygulamalar için mükemmeldir.


4
"NoSQL veritabanı burada ve orada küçük veri kaybedebilir" WTF !? Şimdi kim onların aklı başında bunu riske atmak ister ki? Bu yanlış olmalı.
Jay Q.

1
@JayQ. Evet, yanlış olabilir. Bu yüzden * dedim. Öyleyse neden NpSQL DB'lerini işlemsel işlemler için kullanamıyoruz?
Hrishikesh

7

Soruyu cevaplamak için bazı temel bilgiler eksik: Veri tabanı hangi kullanım durumlarını kapsamalıdır? Mevcut verilerden ( OLAP ) karmaşık analizler yapılmalı mı yoksa uygulama birçok işlemi ( OLTP) işleyebilmeli mi? ) mu? Veri yapısı nedir? Bu soru zamanının sonundan uzak.

Bana göre, teknoloji kararlarını, arkasında tam olarak ne olduğunu tam olarak bilmeden, cesur terimlerle belirlemek yanlıştır. NoSQL genellikle ölçeklenebilirliği nedeniyle övülür. Ancak, yatay ölçeklendirmenin (birkaç düğüm üzerinde) de fiyatının olduğunu ve ücretsiz olmadığını bilmelisiniz. Ardından, nihai tutarlılık gibi sorunlarla uğraşmanız ve veritabanı düzeyinde çözülemezlerse veri çakışmalarının nasıl çözüleceğini tanımlamanız gerekir. Ancak, bu tüm dağıtılmış veritabanı sistemleri için geçerlidir.

NoSQL'de "şema az" kelimesi ile geliştiricilerin sevinci de başlangıçta çok büyük. Bu terim, teknik analizden sonra hızlı bir şekilde dezenfekte edilir, çünkü yazarken doğru bir şema gerektirmez, ancak okuma sırasında devreye girer. Bu yüzden doğru bir şekilde "okunduğunda şema" olmalıdır. Verileri kendi takdirine bağlı olarak yazabilmek cazip gelebilir. Ancak mevcut veriler varsa ancak uygulamanın yeni sürümü farklı bir şema beklerse durumla nasıl başa çıkabilirim?

Belge modeli (örneğin MongoDB'de olduğu gibi) uygun değil veriler arasında birçok ilişkinin olduğu veri modelleri için . Eklemeler uygulama düzeyinde yapılmalıdır, bu da ek bir çaba ve neden veritabanının yapması gereken şeyleri programlamalıyım.

Geleneksel RDBMS artık veri taşını işleyemediği için Google ve Amazon'un kendi veritabanlarını geliştirdiklerini iddia ederseniz, yalnızca şunu söyleyebilirsiniz: Google ve Amazon değilsiniz. Bu şirketler, geleneksel veritabanlarının artık uygun olmadığı senaryoların yaklaşık% 0,01'i mızrak ucu, ancak dünyanın geri kalanı için.

Önemsiz olmayan: SQL 40 yılı aşkın bir süredir var ve milyonlarca saatlik geliştirme Oracle veya Microsoft SQL gibi büyük sistemlere girdi. Bu, bazı yeni veritabanları tarafından gerçekleştirilmelidir. Bazen bir SQL yöneticisi bulmak da MongoDB için birinden daha kolaydır. Bu da bizi bakım ve yönetim sorununa getiriyor. Tam olarak seksi olmayan, ancak bu teknoloji kararının bir parçası olan bir konu.


1
doğru görünüyor ama ben de herkesin tüm uygulamalarında montaj dilini kullanacaktı olsaydı ne kadar zaman harcadığını karşılaştırmak için düşünmüyorum daha ziyade her zaman uygulama ve
usecase

3

RDBMS tasarımından sapmak için ikna edici zemin ararken bu soruya rastladım.

Dağıtılmış sistemlerin kısıtlamalarına ışık tutan Julian Brown'un harika bir yazısı var . Konsepte Brewer'ın CAP Teoremi denir ve bu özetle:

Dağıtılmış sistemlerin üç gereksinimi şunlardır: Tutarlılık, Kullanılabilirlik ve Bölüm toleransı (kısaca CAP). Ama aynı anda sadece ikisine sahip olabilirsiniz.

Ve ben bunu şöyle özetledim:

Tutarlılıktan ödün verdiğiniz şey ise NoSQL için daha iyi olur.


0

NoSQL veritabanlarıyla çözümler tasarladım ve uyguladım ve işte SQL veya belge odaklı NoSQL ile çalışmaya karar vermek için kontrol noktası listem .

YAPILMAYACAKLAR

SQL kullanılmıyor ve bazı durumlarda daha iyi bir araç olmaya devam ediyor. Aşağıdaki durumlarda belge odaklı bir NoSQL kullanımını haklı çıkarmak zordur

  • OLAP / OLTP'ye ihtiyacınız var
  • Küçük bir proje / basit DB yapısı
  • Özel sorgular gerekli
  • Anında tutarlılığı önleyemiyorum
  • Belirsiz gereksinimler
  • Deneyimli geliştiricilerin eksikliği

Yapılması

Bu koşullara sahip değilseniz veya bunları hafifletebiliyorsanız, NoSQL'den yararlanabileceğiniz 2 neden:

  • Ölçekli olarak çalıştırılması gerekiyor
  • Geliştirme kolaylığı (teknoloji yığınınızla daha iyi entegrasyon, ORM'ye gerek yok, vb.)

Daha fazla bilgi

Blog gönderilerimde nedenleri daha ayrıntılı olarak açıklarım:

Not: Yukarıdakiler yalnızca belgeye yönelik NoSQL için geçerlidir. Başka hususlar gerektiren başka NoSQL türleri de vardır .


0

Çok Sayıda Okuma Yazma İşlemi Yapma

Hızlı ölçeklendirmeniz gerektiğinde NoSQL veritabanlarına bakın. Ve genellikle ne zaman hızlı ölçeklendirmeniz gerekir?

Web sitenizde çok sayıda okuma-yazma işlemi olduğunda ve büyük miktarda veriyle uğraşırken, NoSQL veritabanları bu senaryolara en iyi şekilde uyar. Anında düğüm ekleme yeteneğine sahip olduklarından, daha fazla eş zamanlı trafiği ve büyük miktarda veriyi minimum gecikme ile işleyebilirler.

Veri Modelleme ile Esneklik

İkinci ipucu, veri modeli, veritabanı tasarımı, işlerin hızlı bir şekilde değişmesi beklendiğinden, gelişimin ilk aşamalarındadır. NoSQL veritabanları bize daha fazla esneklik sunuyor.

Güçlü Tutarlılık Üzerine Sonunda Tutarlılık

Güçlü tutarlılıktan vazgeçmemizin iyi olduğu ve işlem gerektirmediğimizde NoSQL veritabanlarını seçmek tercih edilir.

Buna iyi bir örnek Twitter gibi bir sosyal ağ sitesidir. Bir ünlünün tweet'i patladığında ve herkes onu dünyanın dört bir yanından beğenip yeniden tweetlediğinde. Beğenilerin sayısının kısa bir süre için biraz yukarı veya aşağı gitmesi önemli mi?

Ünlü, gerçek 5 milyon 500 beğeni yerine, sistem kısa bir süre için benzer sayımı 5 milyon 250 olarak gösteriyorsa kesinlikle umursamaz.

Tüm dünyaya yayılmış yüzlerce sunucuya büyük bir uygulama dağıtıldığında, coğrafi olarak dağıtılmış düğümlerin küresel bir konsensüse ulaşması biraz zaman alır.

Bir konsensüse ulaşıncaya kadar, işletmenin değeri tutarsızdır. Kısa bir süre sonra varlığın değeri eninde sonunda tutarlı hale gelir. Nihai Tutarlılık budur.

Rağmen tutarsızlık herhangi bir veri kaybı olduğu anlamına gelmez. Bu, küresel bir fikir birliğine varmak ve tutarlı olmak için verinin okyanusun altındaki internet kabloları aracılığıyla dünyayı dolaşmak için kısa bir süre aldığı anlamına gelir.

Bu davranışı her zaman yaşarız. Özellikle YouTube'da. Genellikle 10 görüntüleme ve 15 beğenme içeren bir video görürsünüz. Bu nasıl mümkün olabilir?

Değil. Gerçek görüntüler zaten beğenilerden daha fazla. Sadece görüntüleme sayısı tutarsız ve güncellenmesi biraz zaman alıyor.

Veri Analizini Çalıştırma

NoSQL veritabanları, büyük miktarda veri akışı ile uğraşmamız gereken veri analizi kullanım durumları için de en uygun olanıdır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.