NoSQL Veritabanlarının kullanımı, içeriğe göre arama yapmanız gereken büyük veri kümeleri için pratik değil midir?

Bir haftadır NoSQL Veritabanlarını öğreniyorum.

NoSQL Veritabanlarının avantajlarını ve çok kullandıkları kullanım durumlarını gerçekten anlıyorum.

Ancak çoğu zaman insanlar makalelerini NoSQL İlişkisel Veritabanlarının yerini alabilecekmiş gibi yazarlar . Ve kafamı bulamadığım nokta var:

NoSQL Veritabanları (genellikle) anahtar-değer depolarıdır.

Tabii ki mümkündür depolamak (JSON, XML, ne olursa olsun veriyi şifreleyerek) bir anahtar-değer deposuna şeyi, ama tek gördüğüm sorun gerektiğidir olsun birçok belirli bir kritere uyum bazı verilerin miktarını davaları kullan. NoSQL veritabanında etkin bir şekilde arayabileceğiniz tek bir kriter var - anahtar. İlişkisel Veritabanları, veri satırındaki herhangi bir değeri etkin bir şekilde aramak için optimize edilmiştir.

Bu yüzden NoSQL Veritabanları, içerikleri tarafından aranması gereken kalıcı veriler için gerçekten bir seçenek değildir. Yoksa bir şeyi yanlış mı anladım?

Bir örnek:

Bir web mağazası için kullanıcı verilerini saklamanız gerekir.

İlişkisel bir veritabanında her kullanıcıyı userstabloda bir satır olarak, bir kimliği, adı, ülkesi vb. İle birlikte saklarsınız.

Bir NoSQL Veritabanında, her bir kullanıcıyı anahtarı olarak kimliğini ve tüm verilerini (JSON'da kodlanmış vb.) Değer olarak saklarsınız.

Bu nedenle, tüm kullanıcıları belirli bir ülkeden almanız gerekiyorsa (bazı nedenlerden dolayı pazarlamacıların onlar hakkında bir şeyler bilmesi gerekir), İlişkisel Veritabanında bunu yapmak kolaydır, ancak NoSQL Veritabanında çok etkili değildir, çünkü olsun her kullanıcıyı ayrıştırmak tüm veri ve filtre.

Ben öyle demiyorum imkansız , ama çok daha zor alır ve sana NoSQL girişlerinin verilerinde aramak istiyorsanız o kadar etkili değildir sanırım.

Bu ülkede yaşayan her kullanıcının anahtarını depolayan her ülke için bir anahtar oluşturabilir ve bu ülke için anahtarda bırakılan tüm anahtarları alarak belirli bir ülkenin kullanıcılarını alabilirsiniz. Ancak bu tekniğin karmaşık bir veri kümesini daha da karmaşık hale getirdiğini düşünüyorum - bir SQL Veritabanını sorgulamak kadar etkili değil, uygulanması daha zordur. Bu yüzden üretimde kullanmanın bir yolu olmadığını düşünüyorum. Yoksa öyle mi?

Bir şeyi yanlış anladığımdan ya da bu gibi kullanım durumlarını ele almak için bazı kavramları ya da en iyi uygulamaları göz ardı ettiğimden emin değilim. Belki ifadelerimi düzeltip sorularıma cevap verebilirsin.

NoSQL'in tüm veritabanı sıkıntıları için her derde deva olmadığına dair fikrinizle aynı fikirdeyim, sanırım bir anahtar noktayı yanlış anladınız.

NoSQL veritabanında etkili bir şekilde arama yapabileceğiniz tek bir kriter var - anahtar.

Bu açıkça doğru değil.

Örneğin, MongoDB endeksleri desteklemektedir. ( https://docs.mongodb.org/v3.0/core/indexes-introduction/ adresinden )

Endeksler, MongoDB'de sorguların etkin bir şekilde yürütülmesini destekler. Dizinler olmadan, MongoDB bir sorgu taraması yapmalı, yani sorgu ifadesine uyan dokümanları seçmek için koleksiyondaki her dokümanı taramalıdır. Bir sorgu için uygun bir dizin varsa, MongoDB incelemesi gereken belge sayısını sınırlamak için dizini kullanabilir.

İndeksler, koleksiyonun veri setinin küçük bir bölümünü geçişi kolay bir formda saklayan özel veri yapılarıdır [1]. Dizin, alanın değerine göre sıralanan belirli bir alanın veya alan kümesinin değerini depolar. Dizin girişlerinin sıralaması, verimli eşitlik eşleşmelerini ve aralık tabanlı sorgu işlemlerini destekler. Ek olarak, MongoDB dizindeki sıralamayı kullanarak sıralanmış sonuçları döndürür.

Couchbase'de olduğu gibi ( http://docs.couchbase.com/admin/admin/Views/views-intro.html adresinden )

Couchbase görünümleri, verilerin endekslenmesini ve sorgulanmasını sağlar.

Bir görünüm, tanımlanan format ve yapıya göre veriler üzerinde bir dizin oluşturur. Görünüm, Couchbase'deki nesnelerden çıkarılan belirli alanlardan ve bilgilerden oluşur.

Aslında , bir anahtar-değer deposu yerine kendisini NoSQL veritabanı olarak adlandıran herhangi bir şey, bir tür indeksleme düzenini gerçekten desteklemelidir.

Aslında, genellikle NoSQL'in parlamasını sağlayan bu endeks planlarının esnekliğidir. Kanımca, NoSQL endekslerini tanımlamak için kullanılan dil genellikle SQL'den daha anlamlı veya doğaldır ve genellikle tablonun dışında yaşadığından, tablo şemalarınızı desteklemek için değiştirmenize gerek yoktur. (SQL'de benzer şeyler yapamayacağınızı söylememekle birlikte, bana göre daha çok çembere atlıyor gibi görünüyor).

Genel olarak konuşursak, iş akışınız ilişkisel veritabanı sorguları için mükemmel bir eşleşme ise, ilişkisel veritabanlarını en verimli yaklaşım olarak bulacaksınız. Bu tür bir tautolojik, ama gerçek.

Birçok NoSQL savunucusunun yapacağı iddiası, birçok iş akışının aslında ilişkisel bir formda toplandığı ve böyle bir masajdan önce daha etkili olacağı yönündedir. Bu iddianın geçerliliği, kesinleşmek için karmaşıktır. Açıkçası, SQL sorguları tarafından çok iyi tarif edilen işler var. Bu benim deneyimlerinden söyleyebiliriz benim özellikle ilişkisel programlama görevleri daha değilse, verimlilik neredeyse aynı seviyede NoSQL kullanılarak yapılabilirdi. Ancak, bu, dar deneyime dayanan çok öznel bir ifadedir.

NoSQL yaklaşımının satışının büyük veritabanları varsayımından kaynaklandığını hissediyorum. Veritabanı ne kadar büyük olursa, büyük veri kümelerini desteklemek için iş akışınızı o kadar fazla düzenlemelisiniz. NoSQL, bu bakım çabalarını desteklemekte daha iyi görünüyor. Bu nedenle, veritabanı ne kadar büyükse, NoSQL'in özellikleri de o kadar önemli olabilir.

Örneği kullanmak için, SQL'in ülkeye göre sorgulaması, SQL'e userstabloyu ülkeye göre dizine eklemesini söylemediğiniz sürece, tüm kullanıcıların NoSQL taraması kadar yavaş . NoSQL de aynısını yapabilir; burada endeks olan sıralı bir anahtar-değer koleksiyonu yaratırsınız (tıpkı SQL'in başlık altında yaptığı gibi) ve bakımını yapar.

Fark? SQL motorları yerleşik tabloyu indeksleme konseptine sahipti. Bu, daha az iş yapmanız gerektiği anlamına gelir (tek yapmanız gereken tabloya bir dizin eklemek). Ancak, aynı zamanda daha az kontrol sahibi olduğunuz anlamına gelir. Çoğu durumda, sizin için işi yapan SQL motoru karşılığında bu kontrol kaybı kabul edilebilir. Ancak, büyük veri kümelerinde, tipik SQL ACID modelinden farklı bir tutarlılık modeli isteyebilirsiniz. Sonunda tutarlılığı destekleyen BASE modelini kullanmak isteyebilirsiniz. Bu, SQL'de çok zor olabilir, çünkü SQL motoru işi sizin için yapıyor, bu yüzden SQL motorunun kuralları tarafından yapılması gerekiyor. NoSQL'de, bu katmanlar tipik olarak ortaya çıkar ve onlara çarpmalarını sağlar.

NoSQL oldukça belirsiz bir terimdir, çünkü temelde ilişkisel olmayan tüm veritabanı sistemlerini kapsar.

Tanımladığınız şey, bir anahtar bloğunun bir anahtarın altında depolandığı ve anahtarı biliyorsanız, hızlı bir şekilde aranabilen bir tür veritabanı olan anahtar-değer deposudur . Eğer tam anahtarı biliyorsanız, bu veritabanları cayır cayır yanan hızlıdır, ancak kendinizin dediği gibi, veriler üzerinde birden fazla özellik aramanız veya filtrelemeniz gerekirse, yavaş ve zahmetli olacaktır.

Aklı başında hiç kimse anahtar-değer depolarının genel olarak ilişkisel veritabanlarının yerini alamayacağını iddia edemez. Bununla birlikte, anahtar-değer deposunun uygun olduğu bazı özel durumlar olabilir. Anahtar-değer depoları genellikle önbellekleme için kullanılır, çünkü öğeleri genellikle kimliğe göre önbelleğe alırsınız, ancak önbellek üzerinde geçici sorgular gerçekleştirmenize gerek yoktur. Örneğin, Stackoverflow sitesinin kendisi Redis'i (bir anahtar-değer db) yoğun olarak kullanıyor , ancak yalnızca çıktı önbelleğe almak için. Temel kanonik veriler ilişkisel bir veritabanında hala devam etmektedir.

Bu nedenle cevap oldukça açıktır: Yalnızca tek bir anahtar kullanarak kaydetmeniz ve aramanız gerekirse, bir anahtar / değer deposu kullanın. Aksi halde farklı türde bir veritabanı kullanın. Şüpheniz varsa, ilişkisel bir veritabanı kullanın, çünkü bu en çok yönlü veritabanı türüdür, NoSQL veritabanları çoğu zaman belirli kullanım durumlarına göre optimize edilmiştir.

İlişkisel veritabanlarıyla ilgili iddialarınız tamamen doğrudur, o kadar çok veriye sahip olduğunuza kadar, artık bir kopyasına tek bir sunucuya sığamayacaksınız. Sonra her türlü ilginç sorunla karşılaşmaya başlarsınız. Sorgularınızın çoğunun tek bir sunucuda çalışabilmesi için tablolarınızı nasıl bölersiniz? Verilerin kaç kopyasını alıyorsunuz? Bu kopyalar arasındaki tutarsızlıklarla nasıl başa çıkıyorsunuz? Bir kullanıcının verilerini, kendisine coğrafi olarak nispeten yakın bir veri merkezinde nasıl tutarsınız?

Bu hedefler genellikle birbiriyle çatışır. Birçok twitter kullanıcısı dünyanın her yerinden insanları takip ediyor. Twitter veritabanı tweet okumak veya tweet yazmak için coğrafi olarak optimize edilmeli mi?

Bu tür bir ölçekle ilgilendiğinizde ortaya çıkıyor, çözümler bulmaya, artıklıklar eklemeye ve NoSQL veritabanına çok benzeyen kısıtlamalar getirmeye başlıyorsunuz. Tüm verilerinizi bir kutuya sığdırabiliyorsanız, yalnızca kısıtlamaları alıyorsunuz ve faydalara gerek kalmıyor.

NoSQL veritabanlarının “ No SQL” ile ilgisi çok azdır .

Onlar , her zaman tutarlı olan ve karmaşık işlemleri destekleyen ve dayanıklılığı olan bir ölçekte ölçeğe sahip olamayacağınızı kabul etmekle ilgilidir .

Normal bir ilişkisel veritabanında, tüm endeksler bir işlem kapsamında otomatik olarak güncellenir, böylece herhangi bir sorgu için kullanılabilir.

Bir NoSQL veritabanında programcı endekslerin çoğunun korunmasından sorumludur ve endekslerin daima güncel olamayacağı varsayılmıştır.

Örneğin:

• Vergi numarasına göre bir kişi endeksi, vergi için hiçbir zaman kayıt işlemini tamamlamayan bazı insanlar içerebilir.
• Bu nedenle endeksi kullanan kodun, eksik vergi kaydıyla başa çıkabilmesi gerekir.
• Diğer bir seçenek ise, vergi için kayıtlı bir kişinin endekste olmadığı zamanlarda zamana sahip olmaktır. (Dolayısıyla, tasarımınızın tutarlı veriye sahip olmamasıyla başa çıkması ve verilerin nasıl tutarlı olmayacağına karar vermesi gerekir.)

Gerçek bir örnek olarak Amazon, 106 bilgisayarın doğru kilidin alındığını onaylamasını bekleyerek web sayfasının görüntülenmesini geciktirmektense, bir kitabın güncel olmayan açıklamasını gösterir.

Bu nedenle .....

Tek bir normal ilişkisel veritabanı tüm verilerinizi tutabilir ve kilitlemenin sisteminizin faydalı bir iş yapmasını engellememesi için her işlemi yeterince hızlı bir şekilde gerçekleştirebilirse, ilişkisel bir veritabanı en iyi seçenektir.

Ancak birden fazla ilişkisel veritabanı kullanmayı düşünmeye başlamanız veya kilitleme hatalarını önlemek için işlemleri bölmeniz gerektiğinde, “NoSQL” veritabanlarını kullanırken elde ettiğiniz türlerle başa çıkmak zorunda kalabilirsiniz.

“NoSQL” veritabanları bu sorunları gizlemediğinden, bir sistemi ölçeklendirdiğinizde en iyi seçenek olabilirler. Ancak Stackoverflow'un, önbellekleme katmanında NoSQL'in sınırlı kullanımıyla tüm verilerini depolamak için hala ilişkisel bir veritabanı kullandığını unutmayın - bu nedenle verilerinizi depolamak için NoSQL kullanmaya zorlamadan ÇOK büyük olmalısınız.

İlişkisel Veritabanları, veri alanındaki herhangi bir değeri etkin bir şekilde aramak için optimize edilmiştir.

Bir satırdaki "herhangi bir" değeri arama yeteneğini, bir satırdaki "her" değeri ile karıştırmayın. Bunu yapmanın en etkili yolu, bir veya daha fazla endeks gerektirir. Dizinlerin tüm alanları içermesini sağlayabilirsiniz, ancak daha sonra dizini değiştirmeyi gerektiren değişiklikler yapmayı engellediğinizi (ekler, güncellemeler, siler) engellediniz. Siz (veya DBA'nız) verileri, kullanımı, darboğazları vb. Anlamanız gerekir.

Zaten birçok cevap var, fakat sadece özetimi eklemek istedim.

Açıkçası NoSQL kavramı, verileri diskte, bellekte ve sorgu diliyle göstermede çeşitli yaklaşımları kapsar (bazıları SQL benzeri!). Bana göre güç bu sistem çeşitliliğinden geliyor, böylece iş için en iyi aracı seçebilirsiniz. Ama yine de umarım bir düzine farklı ihtiyacı sadece birkaç farklı çözümle karşılayabilirsin, bir düzine farklı sistemi yönetmek istemezsin.

İlişkisel veritabanları sizi çok uzağa götürebilir ve kanıtlanmış bir teknolojidir, ancak veritabanı gibi, her projenin ihtiyaçlarına göre programlama dilini seçmek isteyebilirsiniz (ancak ekibin deneyimini de dikkate alarak).

İki senedir couchdb kullanıyorum. Çoğunlukla içerik yönetimi ve konfigürasyonu için kullanılır.

Çünkü hiyerarşik ilişkileri, onları ne zaman görselleştirebileceğinizi yönetmek çok daha kolaydır. Çoğunlukla okunan veriler için, JSON'u düzenlemek, çoğu durumda bir UPDATE ifadesi yazmaktan daha kolaydır. Aslında, JSON'u düzenlemek için programcı kullanmaz. SQL, daha sonra bir tür nesne yapısına yerleştirmeniz gereken satırları ve sütunları verir.

Ayrıca karmaşık sorgularda 10-20 masaya katılmayacağınız için performans artışı elde edersiniz. Couchdb görünümleri çok hızlıdır, çünkü temel aldığı javascript sorgu zamanında çalıştırılmaz.

Programcıların çoğu Javascript'i anlar ve programcıların çoğu zaman zaman SQL ile mücadele eder.

Couchdb'de, bir görünüm bir JSON belgesinin özeti olarak düşünülebilir. Görünüm verilerinin nasıl yapılandırıldığı size bağlıdır (orijinal hiyerarşi tarafından kısıtlanmamıştır).

Couchdb'yi yüksek işlemsel veriler için kullanmazdım, ancak parça patlaması türünde bir yapıya sahip yarı statik veriler için SQL ile çalışmak çok daha kolay.

Bununla birlikte, uygulanabilecek net bir “normalleşme” olmadığını (verilerin tekrarlanmasından kaçınılmasına rağmen, değerli bir hedeftir) ve iyimser kilitlemeye benzer temelde ve “iyimser” güncelleme stratejisinin bulunduğunu unutmayın.