noSQL veritabanları neden SQL'den daha fazla ölçeklenebilir?

Son zamanlarda noSQL DBMS'leri hakkında çok şey okudum. CAP teoremini , ACID kurallarını, BASE kurallarını ve temel teoriyi anlıyorum . Ancak, noSQL'in neden RDBMS'den daha kolay ölçeklendirilebildiğine dair herhangi bir kaynak bulamadınız mı (örneğin, çok sayıda DB sunucusu gerektiren bir sistem durumunda)?

Kısıtlamalar ve yabancı anahtarların saklanmasının kaynak maliyeti olduğunu ve bir DBMS dağıtıldığı zaman, bunun çok daha karmaşık olduğunu tahmin ediyorum. Ama bence bundan daha fazlası var.

Birisi lütfen noSQL / SQL'in ölçeklenebilirliği nasıl etkilediğini açıklayabilir mi?

noSQL veritabanları, bir SQL veritabanının size doğası gereği sağladığı büyük işlevsellikten vazgeçmektedir.

Referans bütünlüğünün otomatik olarak uygulanması, işlemler, vs. Atomik işlem tabloları ve farklı sunucularda!).

noSQL veritabanları hepsine sahip değil. O şeye ihtiyacın olursa, kendin yapmalısın, ama ihtiyacın yoksa (ve yapmayan pek çok uygulama var), o zaman çocuk nasılsın şansın. DB bu karmaşık işlemlerin hepsini yapmak ve veri setinin çoğunu kilitlemek zorunda değildir, bu yüzden bir şeyi birçok sunucu / disk / bölüme ayırmak gerçekten kolay ve gerçekten hızlı bir şekilde çalışmasını sağlamak.

NoSQL vs SQL hakkında değil, BASE vs ACID hakkında.

Ölçeklenebilir bileşenlere ayrılmalıdır:

• Okuma ölçeklendirmesi = daha yüksek okuma işlemleriyle uğraş
• Yazma ölçeklendirmesi = yüksek hacimli yazma işlemleriyle uğraşmak

ACID uyumlu veritabanları (geleneksel RDBMS'ler gibi) okuyabilir. Bunlar, doğal olarak NoSQL veritabanlarından daha az verimli değildir, çünkü (olası) performans darboğazları, NoSQL (bazen) eksik (şeyler gibi) ve kullanmayacağınız kısıtlamalar gibi şeylerden kaynaklanır. Kümelenmiş SQL RDBMS'ler, kümeye ek düğümler ekleyerek okumaları ölçeklendirebilir. Okuma işlemlerinin ne kadar ölçeklenebileceğine ilişkin kısıtlamalar vardır, ancak bunlar kümeye daha fazla düğüm girdikçe, ölçeklendirmenin yazma zorluğundan kaynaklanmaktadır.

Yazma ölçeklendirme, işlerin tüylendiği yerdir. Sonunda tutarlı (BASE) mimarilerde göremediğiniz ACID ilkesinin uyguladığı çeşitli kısıtlamalar vardır:

• Atomiklik, işlemlerin bir bütün olarak tamamlanması veya başarısız olması gerektiği anlamına gelir, bu yüzden bunu garanti etmek için perde arkasında çok fazla defter tutma yapılması gerekir.
• Tutarlılık kısıtlamaları, kümedeki tüm düğümlerin aynı olması gerektiği anlamına gelir. Bir düğüme yazıyorsanız, istemciye bir yanıt döndürmeden önce bu yazının diğer tüm düğümlere kopyalanması gerekir. Bu, geleneksel bir RDBMS kümesinin ölçeklenmesini zorlaştırır.
• Dayanıklılık kısıtlamaları, bir yazmayı asla kaybetmemek için istemciye bir yanıt gelmeden önce yazının diske atıldığından emin olmanız gerektiği anlamına gelir.

Bir kümedeki yazma işlemlerini veya düğüm sayısını belirli bir noktadan daha fazla büyütmek için, ACID gereksinimlerinin bazılarını gevşetmeniz gerekir:

• Atomicity'i bırakmak, tabloların (veri kümelerinin) kilitlenme süresini kısaltır. Örnek: MongoDB, CouchDB.
• Bırakma Tutarlılığı, küme düğümleri arasındaki yazıları ölçeklendirmenizi sağlar. Örnekler: riak, cassandra.
• Düşürme Dayanıklılığı, diske yıkamadan yazma komutlarına yanıt vermenizi sağlar. Örnekler: memcache, redis.

NoSQL veritabanları genellikle ACID modeli yerine BASE modelini izler. A, C ve / veya D gerekliliklerinden vazgeçerler ve karşılığında ölçeklenebilirliği geliştirirler. Bazıları Cassandra gibi, ihtiyaç duyduğunuzda ACID'in garantilerini almanıza izin verir. Ancak, tüm NoSQL veritabanları her zaman daha fazla ölçeklenebilir değildir.

SQL API, ACID'nin gereksinimlerinin rahat olduğu sorguları tanımlayan bir mekanizmaya sahip değildir. Bu nedenle BASE veritabanlarının tümü NoSQL'dir.

Kişisel not: yapmak istediğim son bir nokta, NoSQL'in şu anda performansı artırmak için kullanıldığı durumlarda, uygun bir RDBMS'de, uygun indekslere sahip doğru bir normalleştirilmiş şema kullanarak bir çözümün mümkün olacağı yönünde. Bu site tarafından kanıtlandığı gibi (MS SQL Server tarafından desteklenmektedir) RDBMS'ler, uygun şekilde kullanırsanız yüksek iş yüklerine ölçeklenebilir. RDBMS'lerin nasıl optimize edileceğini anlamayan insanlar, NoSQL'den uzak durmalıdır, çünkü verilerinde hangi riskleri aldıklarını anlamamaktadır.

Güncelleme (2019-09-17):

Veritabanlarının peyzajı bu cevabı gönderdiğinden beri gelişmiştir. RDBMS ACID dünyası ile NoSQL BASE dünyası arasında hala ikilik olmasına rağmen, çizgi daha da bulanıklaştı. NoSQL veritabanları, SQL API'ler ve işlem desteği gibi RDBMS dünyasından özellikler ekliyor. Artık Google Cloud Spanner, YugabyteDB veya CockroachDB gibi SQL, ACID vaat eden ve ölçeklendirme yazan veritabanları bile var . Tipik olarak şeytan ayrıntıda yer almaktadır, ancak çoğu durumda bunlar "Yeterince" dir. Veri tabanı teknolojisine daha derin bir dalış yapmak ve bunun nasıl geliştiğini görmek için bu slayt güvertesine bir göz atabilirsiniz (slayt notlarında beraberinde gelen açıklama vardır).

NoSQL veritabanlarının (MongoDB, Redis, Riak, Memcached, vs.) yabancı anahtar kısıtlamaları korumadığı ve atomik işlemlerin daha açık bir şekilde belirtilmesi gerektiği doğrudur. Ayrıca, SQL veritabanlarının (SQL Server, Oracle, PostgreSQL vb.) Mevsimsel DBA'lar tarafından çok büyük performans gereksinimlerini karşılayacak şekilde ölçeklendirilebileceği de doğrudur.

NoSQL veritabanları, yarış koşullarının ve atomik işlemlerin iyi farkında olan deneyimli programcıların, yalnızca bugünün web uygulama kodunun küçük bir yüzdesinde gereken büyük miktarda işlemden vazgeçmesine izin verir. NoSQL veritabanları kesinlikle atomik işlemlere sahiptir ve SQL veritabanlarında bulunan tüm işlem gereksinimlerinin çoğu NoSQL veritabanlarından da elde edilebilir. Fark soyutlamanın seviyesidir. NoSQL veritabanları, uygulama programcısı için daha yüksek soyutlama seviyelerini ve elde etme yeteneğini ortadan kaldırır; bu nedenle sonuçta, deneyimsiz programcılar tarafından veri bozulma ihtimalinin artmasıyla sonuçta daha hızlı kod elde edilir.

Sonuç olarak, geliştirme süresi ve performansın çok önemli olduğu web uygulama alanında NoSQL veritabanlarının giderek daha yoğun kullanıldığını görme ihtimalimiz çok daha yüksek. Finansal ve kurumsal yazılımların SQL mirası korunma olasılığı yüksektir, çünkü donanım performansı nispeten ucuzdur, DBA'ları elinizde bulundurmaktadırlar ve deneyimsiz programcıların neden olduğu artmış risk memnuniyet verici değildir.

IBM developerWorks'ten: NoSQL veritabanlarıyla bulut düzeyinde veri ölçeklenebilirliği sağlayın

Ölçeklenebilirlik , çok düşük gecikmeyle çok yüksek talep oranlarına sahip çok büyük veritabanlarını destekleyebilecek sistemdir.

NoSQL sistemleri ortak olarak birçok tasarım özelliğine sahiptir:

• Birçok sunucu üzerinden verimi yatay olarak ölçeklendirme yeteneği.
• Basit bir arama seviyesi arayüzü veya protokolü (SQL bağlamanın aksine).
• Çoğu geleneksel RDBMS'deki ACID işlemlerinden daha zayıf tutarlılık modelleri için destek.
• Veri depolama için dağıtılmış dizinlerin ve RAM'in verimli kullanımı.
• Yeni özellikleri veya veri şemasını dinamik olarak tanımlama yeteneği.

İlişkisel veritabanları, Ölçeklendirme için neden uygun olmayabilir?

Genel olarak, ilişkisel veri tabanı yönetim sistemleri, on yıllardır "veri kalıcılığı ve alımı için tek boyutlu bir çözüm" olarak değerlendirilmiştir. Kapsamlı araştırma ve geliştirme çabalarının ardından olgunlaştı ve farklı iş alanlarında büyük bir pazar ve çözümler yarattı.

Her geçen gün artan ölçeklenebilirlik ve yeni uygulama gereksinimleri, bazı web ölçekli uygulamalarda bu tek bedene uyan her yaklaşımdan memnuniyetsizliği de içeren geleneksel RDBMS için yeni zorluklar yarattı. Bunun cevabı, ilişkisel veritabanı yönetim sistemlerinin hakimiyetini zorlamak için tasarlanmış yeni nesil bir düşük maliyetli, yüksek performanslı veritabanı yazılımı olmuştur. NoSQL hareketinin büyük bir nedeni, web, kurumsal ve bulut bilgi işlem uygulamalarının farklı uygulamalarının veritabanlarının farklı gereksinimlerine sahip olmasıdır - örneğin her uygulama katı veri tutarlılığı gerektirmez.

Başka bir örnek: eBay, Amazon, Twitter veya Facebook gibi yüksek hacimli web siteleri için ölçeklenebilirlik ve yüksek kullanılabilirlik ödün vermeyen önemli gereksinimlerdir. Bu uygulamalar için, en ufak bir kesinti bile önemli finansal sonuçlar doğurabilir ve müşteri güvenini etkileyebilir.

Üzerinde DBA.SE: Yatay ölçeklendirme ne anlama geliyor?

Yatay Ölçekleme, esasen yukarı yerine oluşturuluyor. Daha büyük bir beefier sunucusu satın almazsınız ve tüm yükünüzü onun üzerine taşırsınız, bunun yerine 1+ ek sunucu satın alır ve yükünüzü kendilerine dağıtırsınız.

Yatay ölçekleme, sunucularda aynı anda birden fazla örnek çalıştırma yeteneğiniz olduğunda kullanılır. Genellikle 1 sunucudan 2 sunucuya gitmek daha zordur, sonra 2'den 5'e, 10, 50'den vb.

Paralel örneklerin çalıştırılması sorununu çözdükten sonra, talep üzerine talep ederek örnekleri yukarı ve aşağıya çekebileceğiniz gibi, sunucu gücü için ödeme yapma gereksinimini azaltan Amazon EC2, Rackspace Bulut Hizmeti, GoGrid vb. Gibi ortamlardan büyük ölçüde yararlanabilirsiniz. Sadece bu pik yükleri karşılamak için kullanmıyorsun.

İlişkisel Veritabanları paralel olarak tam okuma / yazma yapmak için en zor maddelerden biridir.