Hangi veri boyutunda SQL'den NoSQL'e geçmenin faydası olur?

Bir ilişkisel veritabanı programcısı olarak (çoğu zaman), ilişkisel veritabanlarının nasıl ölçeklenemediği ve MongoDB gibi NoSQL çözümlerinin nasıl yapıldığına dair makaleler okudum. Şimdiye kadar geliştirdiğim veritabanlarının çoğu küçük ve orta ölçekli olduğu için, bazı indeksleme, sorgu optimizasyonu veya şema yeniden tasarımı ile çözülmemiş bir problemim olmadı.

Ne tür bir boyutta MySQL'in mücadele ettiğini görmeyi beklerdim. Kaç satır

(Bunun uygulamaya ve depolanacak veri türüne bağlı olacağını biliyorum. Bana bir şey getiren temelde genetik bir veri tabanıydı, yani 3 veya 4 arama tablosu olan bir ana tablo olacaktı. başka şeyler, bir kromozom referansı ve bir pozisyon koordinatı: Orada ne depolandığını görmek için, bir kromozomdaki iki iksir arasındaki bir kaç giriş için muhtemelen sorgulanacak).

Bir veri ne kadar büyük?

İki önemli eşik vardır:

1. tüm veriler RAM’e uyar
2. tüm dizin verileri RAM’e uyar

Hızlı SSD'lerde, trafik yoğunluğu olmadığı sürece ilk eşik bir sorundan daha az oldu.

asidite

RDBMS'leri ölçeklemeyle ilgili sorunlardan biri, tasarım gereği, ACID olduğu, yani işlemler ve satır düzeyi kilitleri (hatta bazı eski / daha basit RDBMS'lerde tablo düzeyi) anlamına gelir. Aynı anda çalışan birçok veriyi değiştiren çok sayıda sorunuz varsa, bu sınırlayıcı bir faktör olabilir. NoSQL çözümleri genellikle nihai tutarlılık modeli için geçerlidir.

RDBMS veri büyüklüğüne nasıl ölçeklenir?

RDBMS'nin veri boyutuna göre ölçeklendirilemediği doğru değildir, iki alternatif vardır: dikey bölümleme ve yatay bölümleme (aka sharding).

Dikey bölümleme temelde ilgisiz tabloları ayrı DB sunucularında tutar, böylece her birinin boyutunu yukarıda belirtilen eşik değerlerin altında tutar. Bu, düz SQL kullanarak daha az düz ileri ve daha az verimli olan bu tabloları birleştirir.

Paylaşma, belirli bir tabloya dayanarak verileri bir tablodan çeşitli sunucular arasında dağıtmak anlamına gelir. Bu, aramalar için, hangi anahtara göre hangi sunucuyu sorgulayacağınızı bildiğiniz anlamına gelir. Ancak, bu, sharding anahtarına bakmayan sorguları karmaşıklaştırır.

Her iki tür bölümleme durumunda, eğer aşırı uç noktalara giderseniz, temel olarak NoSQL veritabanlarıyla aynı durumla karşılaşırsınız.

Veri boyutunun tek faktör olduğunu sanmıyorum. "Veri modeli" de çok önemli bir kısımdır.

E-Ticaret katalog sayfaları (Solr, ElasticSearch), web analitik verileri (Riak, Cassandra), hisse senedi fiyatları (Redis), Sosyal Ağlardaki ilişkiler bağlantıları (Neo4J, FleetDB), bir NoSQL çözümü gerçekten parladığında sadece bazı örneklerdir.

IMHO, veri modeli, bir NoSQL çözümü veya RDBMS düşünülürken veri boyutundan daha önemli bir role sahiptir.

İlişkisel veritabanları ölçeklenmezse, hiçbir şey değişmez. Ölçeklendirme sorunları hakkında endişelenmeyin.

SQL bazı analiz türleriyle ilgili problemler yaşıyor, fakat problemi tetiklemek için fazla veri gerekli değil. Örneğin, benzersiz bir anahtara göre diğer satırlara başvuruda bulunan sütunlu tek bir tablo düşünün. Genellikle, bu bir ağaç yapısı oluşturmak için kullanılabilir. İlgili satıra başvuran hızlı SQL ifadeleri yazabilirsiniz. Veya ilgili satırın ilgili satır. Aslında, belirli sayıda atlama yapabilir. Ancak, her bir satır için, zincirdeki ilk ilgili satırda bazı kriterleri karşılayan bir alan seçmek istiyorsanız, o zaman karmaşıklaşır.

Her ofise başvurduğu ofise başvurarak ulus, il / ilçe, ilçe, kasaba ve köy seviyelerinde bir ofis yerleri tablosu düşünün. Orada hiçbir Her ofisin raporlama ofisi yalnızca bir seviye yukarı olduğunu garanti. Seçilen bir dizi ofis için, hepsi bir seviyede değil, her birinin ilişkili ulusal ofisini listelemek istersiniz. Bu, SQL statülerinin döngüsünü gerektirir ve bugün bile uzun zaman alacaktır. (30 ofis seçiminde 30 saniyem vardı ama bu çok uzun zaman önceydi - ve saklı işlemlere geçmek biraz yardımcı oldu.)

Bu nedenle alternatif, tüm yapıyı büyük bir veri bloğuna koymak, etiketlemek ve saklamaktır. Verileri analiz etmek istediğinizde hepsini tek seferde belleğe okuyun, yapıyı izlemek için işaretçiler oluşturun ve birkaç milyon ofisi bir göz açıp kapayıncaya kadar işleyebilirsiniz.

Bunların hiçbiri veri miktarı ile ilgisi yoktur. Anahtar, veri organizasyonunun niteliğidir. İlişkisel bir düzen yardımcı olursa, bir RDBMS istediğiniz şeydir. Olmazsa, bir tür toplu depolama biraz daha katrilyon kat daha hızlı bir şey olacak.

Bu veri kümelerinden birinin belleğe sığmayacak kadar büyük olursa, SQL olmayan veritabanınızın artık çalışmadığını unutmayın. Diğer bir problem, bir defada birden fazla bloktan veriye ihtiyacınız olduğunda; Bunu yapmadan eğer ve sadece eğer, tüm blokları aynı anda bellekte uygun. Ve siz onları yüklerken kullanıcının beklemesi gerekiyor.

İlişkisel veritabanınız size sorun çıkaracaksa, içine çok fazla veri girmeden önce bunu yapacak. Sahip olabileceğiniz tek ölçeklendirme sorunu, nosql DB için bir araya getirdiğiniz veri bloğu - eğer bir tane kullanmak zorundaysanız - bunun için çok büyük olduğu zaman programınızla ilgilidir. (Bellek yetersiz hatalarını okuyun. Yeni diller bazen bellekte tuhaf şeyler yapar.)

Bir NoSQL veya Distributed çözümüne gitmenin ilk sebebinin tüm verilerin boyutu değil, tabloların boyutu olduğunu düşünüyorum. Dağıtılmış çözümlerin iyi yaptığı, tabloları farklı düğümlere ayırmaktır; o zaman tabloları sorgulamanız gerektiğinde, her düğüm kendi tablonun parçasını işler.

RDBMS'ler bunu yapabilir, ancak yeni NoSQL veritabanı dalgası bunu yapmak için oluşturulmuştur. Oracle, MSSQL, MySQL merkezileştirilmiş modellerini aldı ve dağınık bir ortamda çalışması için değiştirdi. Ancak, yine de katı ACID kurallarına uyurken, yeni veritabanlarının bazıları nihai tutarlılığı kullanmak gibi katı kurallara uymuyor.

Birini diğerinden seçmeniz gereken belirli bir veri miktarı yok. Dikkate alınması gereken, veritabanının ihtiyaçları ve aldığı kullanım miktarıdır. NoSQL veritabanları daha büyük veri kümelerini daha hızlı işleyebilirken ilişkisel veritabanları ACID ilkeleriyle verilerinizin doğru olduğuna güvenmenizi sağlar.

Veri modelinizin şeyler üzerinde büyük bir etkiye sahip olduğunu belirtmekte fayda olabilir. Kendinizi bir tür ağaç yapısı oluşturmaya ihtiyaç duyarsanız (diğer bir deyişle birleşik birincil anahtarda söz konusu yabancı anahtarı içeren bir tabloda kendinden referans alan bir yabancı anahtarınız varsa), bunu büyük olasılıkla bunları kullanan bir veritabanı biçiminde yapmaya bakmalısınız. gerçekten iyi veri türleri (mongodb veya couchdb gibi).

Diğer insanların söylediği gibi, başvurunuzda neler olduğunu da göz önünde bulundurmalısınız. eğer birden fazla tabloda gerçekten ACID'ye ihtiyacınız varsa, o zaman gerçekten bir RDBMS'ye bağlı kalmanız gerekir, ancak biraz eski baya verilere sahip olabileceğiniz bir şeye sahipseniz ve bir NoSQL şemasının esnekliğine ihtiyacınız varsa (isterseniz şemaya bakın) hala bazı kapalı şema biçimlerine sahiptir) o zaman bir NoSQL mağazasını almayı düşünebilirsiniz ( http://www.10gen.com/customers/craigslist burada craigslist'in neden değiştiğine bir örnek ... ama kuşkusuz ~ 10TB arşivliyorlar. Bildiğim veriler küçük ve orta büyüklükteki veri tabanı boyutunuza uymuyor. Ancak kullanım durumu faydalı olabilir).

RDMS'lerin yerini almak için NoSQL sistemlerinin mutlaka bulunmadığını unutmayın, ancak birçok durumda RDBMS'nizi Polyglot Kalıcılık fikriyle tamamlayabilirsiniz ve verilerinizin çoğunu RDBMS'de saklayabilirsiniz, ancak belirli niş durumlarda bazı verilerinizi boşaltabilirsiniz. NoSQL deposunun bir formuna veri.

Mongobirkaç bilgisayar / düğüm üzerine kurulabilir. citus çevresinde olduğu PostgreSQLhalde, sharding için yerleşik bir araç sağlamaz .

MongoDB , 64 terabayta kadar veritabanlarını destekler ve belge boyutu 16 megabayttır.

MySQL'in veritabanı sınırı 256 terabayt, 64 terabayt bir masa için maksimum büyüklük ve 4 gigabaytlık kayıt sınırına sahiptir

PostgreSQL'in veritabanı üzerinde bir sınırı yoktur (test için bir yerde 4 terabayt vardır) ve bir tablodaki herhangi bir alanın boyutu için 1 gigabayt ve yine bir tablo için maksimum büyüklüğü 64 terabayt sınırına sahiptir.