NoSQL neden SQL'den daha hızlı?

Son zamanlarda bana istendi:

NoSQL neden SQL'den daha hızlı?

Sorunun öncülüne katılmamıştım ... şahsen benim için saçma. SQL yerine NoSQL kullanarak performans artışı göremiyorum. Belki NoSQL üzerinden SQL, evet ama bu şekilde değil.

NoSQL hakkında bir şey eksik mi?

42
X her zaman X kadar hızlı olduğundan, X X'ten daha hızlı olamaz, bu nedenle "SQL'ten daha hızlı SQL yoktur. Tüm SQL'ler kadar hızlıdır."
katma yazar Bloodhound, kaynak
Neden arabalar kamyonlardan daha hızlı? Eh, tüm arabalar tüm kamyonlardan daha hızlı değildir. Bu aptalca bir soru. Doğru cevap, öncül soruyu derhal sorgulamak ve daha sonra şirketin neden bu kadar karmaşık olmayan bir veritabanına sahip bir kişiye programcılarla röportaj yapma izni verdiğini merak ediyor.
katma yazar Daniel McPherson, kaynak
Geleneksel bir ACID etkin ilişkisel veritabanına kolayca eşlenemeyen bazı iş akışları (ve veri yapıları) vardır. Bunlar için bir NoSQL veritabanı kullanarak çok büyük performans artışı olduğunu görebilirsiniz. Bununla birlikte, basitçe mevcut (iyi tasarlanmış) bir SQL DB kullanır ve onu bir NoSQL Veritabanına koyarsanız, performansınız kesinlikle olacaktır.
katma yazar MikeJ-UK, kaynak
Cevap: Daha hızlı kuruldu mu? Ve ne içinde daha hızlı? Gelişme zamanı? Okuma zamanı? Zaman yaz Hangi yazı tipi? Neyle karşılaştırıyoruz? Çok masalı sorgular? Katıldı?
katma yazar Rolf, kaynak
Performans artışı göremiyorsanız, söylediğiniz şey budur. İşin aslı, NoSQL çözümlerinin çoğunun ilişkisel bir veritabanının ACID özelliklerinden birini (veya daha fazlasını) gerektirmesidir, bu yüzden daha az yaparlar.
katma yazar Codes with Hammer, kaynak

8 cevap

Her birinin kendine özgü güçlü ve zayıf yönleri olan birçok NoSQL çözümü vardır, bu nedenle aşağıdakilerin bir tuz tuzu ile alınması gerekir.

Fakat aslında, birçok NoSQL veritabanının yaptığı şey denormalizasyona dayanmaktır ve denormalize edilmiş durum için optimize etmeye çalışmaktadır. Örneğin, bir blog gönderisini, yorumlarıyla birlikte belge odaklı bir veritabanında okuduğunuzu varsayalım. Çoğu zaman, yorumlar gönderinin kendisi ile birlikte kaydedilir. Bu, aynı yerde depolandıkları için hepsini bir araya getirmenin daha hızlı olacağı ve bir birleşme gerçekleştirmeniz gerekmediği anlamına gelir.

Elbette, aynı şeyi SQL'de de yapabilirsiniz ve denormalizasyon, performansa ihtiyaç duyulduğunda yaygın bir uygulamadır. Sadece birçok NoSQL çözümü her zaman bu şekilde kullanılacak şekilde tasarlandı. Daha sonra olağan takaslar elde edersiniz: örneğin yukarıdaki örnekte bir yorum eklemek daha yavaş olacaktır çünkü tüm belgeyi onunla birlikte kaydetmeniz gerekir. Ve bir kez normalize edildikten sonra, başvurunuzdaki veri bütünlüğünü korumaya özen göstermelisiniz.

Ayrıca, birçok NoSQL çözümünde, isteğe bağlı katılımlar, dolayısıyla isteğe bağlı sorgular yapmak mümkün değildir. CouchDB gibi bazı veritabanları, ihtiyaç duyacağınız sorguları önceden düşünmenizi ve bunları DB içinde hazırlamanızı gerektirir.

Sonuç olarak, bu denormalize bir şema beklemek ve bu durum için okumaları optimize etmekle kaynaşıyor ve bu, ilişkisel olmayan ve yazdıklarından çok daha fazla okuma gerektiren veriler için iyi çalışıyor.

58
katma
Cevapta söylediğim gibi, SQL'de aynı şey yapılabilir; sadece istisnalar yerine kural olunca, NoSQL veritabanları genellikle daha hızlı ve daha doğaldır. Teoride, SQL kullanılabilecek en iyi modeldir, ancak veriler belirli bir boyutta büyüdüğü zaman, sadece bazı modellere uyum sağlayamaz ve veri çoğaltmanın nedenleri hızlı ve kolay olur.
katma yazar Andrea, kaynak
@morg - "İlişkisel model, NoSQL'de yapabileceğiniz her şeyi ve daha fazlasını içerir." Gerçekten değil, hayır. Verileri içine zorlayan büyük verimsizlikle sonuçlanan ilişkisel modele bu kadar kötü gelen birçok veri örneği örneği vardır. Örnek: Bir çevrimiçi oyunda oyuncuların envanterini depolamak için bir tesis bulunur. Oyuncular, her biri belirli bir tipte bir veya daha fazla eşya saklayabilen sınırlı sayıda numaralandırılmış slot setine sahiptir. Her biri 4-6 ilişkili özelliğe sahip, bazıları çakışan yaklaşık 50 farklı öğe türü vardır, bu yüzden yaklaşık 80 olası özellik vardır ...
katma yazar Jules, kaynak
... herhangi bir öğenin sahip olabileceği. Bu özelliklerden bazıları veri tabanındaki belirli varlıklara yapılan referanslardır (örneğin, ürünü yapan usta, bunun için özel bir arayış, vb.), Bazıları ise veri değerleridir (birkaç türden). Veritabanının verilerin bütünlüğünü sağlaması yararlı olacaktır, bu nedenle atanmış bir anlama sahip olmayan sütunları kullanamayız ve müşterinin düzenlemesine izin verelim. Bunu, verilerin boyutunu (örneğin) sütun deposu veya nesne veritabanları tarafından kullanılan gösterimler üzerinde 4 veya daha fazla bir faktörle şişirmeyen bir ilişki olarak uygulamanın hiçbir yolu olmadığını biliyorum.
katma yazar Jules, kaynak
Bu arada, tüm SQL iyiliğinden faydalanırken, basitleştirilmiş bir görünüme ya da bir önbellek katmanına sahip olarak gerçekleştirilebilir. Düzgün bir şekilde modellenen herhangi bir şey ilişkiseldir ve mantıksal veri çoğaltılması bir çözüm değildir (mat. Görünüm bir çoğaltmadır, ancak mantıksal bir çoğaltma değildir, çünkü başka bir şeyin görüntüsüdür).
katma yazar M Conrad, kaynak
Bu boğa. İlişkisel model NoSQL'de yapabileceğiniz her şeyi ve daha fazlasını içerir. NoSQL'in tek avantajı, ölçeklendirmeye basit ve tutarsız bir yaklaşımın dahil edilmiş ve kullanımı kolaydır. SQL ile ilgisi yok ve ACID özelliklerini önemsememekle ilgisi yok. NoSQL mağazalarının sahip olduğu tamamen aynı (çok kötü) ölçeklendirme ve tutarlılık özelliklerine sahip olacak olan bağımsız SQL düğümleri arasında eşitleme işleri yapabilirsiniz. Fark, eğer isterseniz SQL düğümlerinin ALSO’nun tutarlılığı olabilir.
katma yazar M Conrad, kaynak
Peki ya 5.000.000 milyon veri satırınız varsa ve bir şartla hepsinden yorum almak istiyorsanız. SQL ile tablonun yorum alanında bir indeks olsaydı daha hızlı olmaz mıydı? Tam Metin indekslemesi bunu daha da iyileştirirdi.
katma yazar jwize, kaynak

NoSQL hakkında kaçırdığınız şey, NoSQl'nin SQL ile hiçbir şekilde karşılaştırılamayacağıdır. NoSQL, SQL olmayan tüm kalıcılık teknolojilerinin adıdır. Belge DB'leri, Anahtar Değer DB'leri, Olay DB'leri hepsi NoSQL'dir. Neredeyse her yönden hepsi farklıdır; kaydedilen verinin yapısı, sorgulama, performans ve kullanılabilir araçlar.

Öyleyse eğer biri size röportajda böyle bir soru sorarsa, cevap bu olmalıdır.

23
katma
Soruyu duyduğumda hissettiğim bu, ancak cevabınızın görüşmeci tarafından beklenilen şey olmadığını düşünüyorum. Sorun, kendimi bilmediğim şekilde inşa ettiğim, bilmediğim bazı NoSQL "katil özelliği" ...
katma yazar Johan Moreau, kaynak
NoSQL'in bir katil özelliği varsa, bunun ölçeklenebilirlik olduğunu söyleyebilirim. Bu yüzden Facebook ve Googles onu kullanıyor. Verilerin devasa hacmi nedeniyle. NoSQL: muazzam miktarda Veri ile uğraşmak zorunda olduğunuzda.
katma yazar xirt, kaynak

'NoSQL' (ya da daha doğrusu: ilişkisel olmayan) veritabanları hız için geleneksel veritabanlarının bazı özelliklerinden vazgeçer, daha da önemlisi yatay ölçeklenebilirlik için.

Eksik özellikler, beton ürüne, genel olarak tam ACID özelliklerine ve hatta birleştirme işlemlerine dayanır. Artan performansın bedeli budur.

15
katma
NoSQL'i ilişkisel olmayan olarak tanımlamak daha kesin değildir. NoSQL kategorisine girmeyen diğer eski ilişkisel olmayan DB'ler var. NoSQL, ilişkisel olmayan ilişkiden çok daha fazlasını ifade eder. Daha fazla bilgi için bunu okuyun: martinfowler.com/bliki/NosqlDefinition.html
katma yazar Drew, kaynak

Haklısın, bunu bir battaniye ifadesinde belirtmek saçma olur. Muhtemelen bütün mesele budur; Tek bir cevap yerine, görüşmeci muhtemelen sorunun bağlamının ne olduğunu (ne tür veriler, ne kadarının, hangi işletim ortamında vb.) ve belirli NoSQL çözümünü belirlemenize yardımcı olacak sorularla cevap vermenizi beklemektedir. . Problemleri nasıl analiz ettiğinizi bulmaya çalışacaklar ve bu süreçte ortaya çıkan farklı çözümler hakkında ne kadar bilginiz olduğu hakkında bir fikir edinecekler.

8
katma
Evet, bu bir battaniye ifadesidir ve doğru olduğunu kabul edersek, sorunun cevabı şudur: bağlıdır.
katma yazar Rolf, kaynak

NoSQL veritabanları normalde yalnızca verilerinizi etraflarında tasarlarsanız mantıklı olur.

Bunları yalnızca bir RDBMS yedeği olarak kullanmak istiyorsanız, o zaman özellikle de yüksek miktarda RAM içeren sunucular için ödeme yapmak için yeterli bütçeniz yoksa, daha çok performans elde edersiniz.

Look at this article which compares MySQL disk space usage with that of MongoDB: http://blog.trackerbird.com/content/mysql-vs-mongodb-disk-space-usage

4
katma

Veritabanlarının etrafındaki teoriyi unutun .... asıl sorgunuzu anladığınızda, nosql veritabanlarındaki verileri uygulamanızın gerçekte kullanıldığı şekilde kaydedebilirsiniz.

Örneğin, bu örneği ele alalım, çok sayıda sipariş ve her bir siparişle ilişkili birçok üründen oluşan bir müşteri modeliniz var, o zaman daha sonra satın alımlar için çok sayıda kaydedilmiş öğelere sahip olacaksınız ... eğer büyük bir e-ticaret mağazasıysanız, 10 milyon müşteri ve 50 milyon emir. Ve bu müşteri, bu kesin verileri görüntüleyen gösterge tablosuna giriş yapar, müşteriyi bulmak, siparişlere katılmak ve her satır öğesine ve kaydedilmiş öğelere katılmak için gerekecek bir sql veri tabanının ne kadar işe yaradığını gösterir. Bir sql veritabanında tüm bu verilerin bir şekilde birleştirilmesi gerekebilir ... veya ur veritabanında usercache adlı bir koleksiyon oluşturabilir ve bu verileri gerçek hayatta nasıl kullanacağınızı kaydedebilirsiniz. Bu nedenle, bu verilerin tümünü geri almak için bu, tek bir alanda [id] gerçekten tek bir sorgu olabilir. Bunun da ötesinde, nosql veritabanının, sadece veriye sahip olanları elde etmek için sorguyu 40 veritabanı sunucusunun tümüne göndermesi gerekmez.

Bir sql db, nosql'den daha hızlı değilse tek bir Id alanını sorgulayabilir mi? Evet, ancak bir sql veritabanı ihtiyacınız olan tüm verileri bir tabloyu ve bir alanı sorgulayarak döndürebilir mi? Hayır, Json'daki verileri büyük bir metin alanına kaydetmek gibi bir şey yapmazsanız. Ancak şimdi bu veriler gelecekteki potansiyel kullanım için sorgulanabilir durumda değildir.

3
katma

Hangi NoSQL veritabanı? Hangi SQL veritabanı? Birisi size NoSQL'in SQL'den daha hızlı olduğunu söylerse o zaman uzaklaşmalısınız. Ya da daha iyisi bu videoyu izleyin:

http://www.youtube.com/watch?v=b2F-DItXtZs

NoSQL hakkında iddia edilen şeylerin yarısının yanlış olduğunu söylemeyeceğim, ancak orada gerçekten çok iyi anlamayan insanlardan çok fazla NoSQL fanatiği olduğunu söyleyeceğim.

SQL'in sınırları var (elbette) ama aynı zamanda çok iyi bilinen bir teknolojidir, iyi anlaşılmıştır ve nasıl iyi kullanılacağını bilen büyük bir geliştirici havuzuna sahiptir. NoSQL'in tüm formları için aynı şeyi söyleyemem.

2
katma

NoSql, RDBMS'nin satır tabanlı veritabanı olduğu sütun odaklı veritabanları tarafından desteklenir ... Örneğin, örneğin, Ad, Yaş, Salery, Adres, Çalışan vb. İçeren bir Çalışan tablomuz var. (NoSQL desteği). Bir müşteri/müşteri 1Lakh çalışan kayıtlarından ortalama Yaş veya Salery detaylarını almak için bir sorgu yazarsa ... ne olur?

In RDBMS it will go around each row and collects the value and sum & divide for resulting. When it comes to Columnar database no need to worry about all one lakh row iterations. But deal with only one Row which is faster to compute. So this way sometimes NoSQL is faster than SQL. This case NoSQL don't care about ACID complaints are worth!

2
katma
Şekillendirmeyi biraz düzelttim, ancak ikisi arasında ne yapmaya çalıştığınızdan emin değilim. Ve ACID de her zaman RDBMS tarafından desteklenmiyor.
katma yazar user40980, kaynak