Büyük Veri sorununun ilişkisel veritabanlarının şu anda oluşturulmakta olan büyük miktarda veriyi işlemek için ölçeklenememeleri sık sık tekrarlanır.
Ancak Hadoop gibi Büyük Veri çözümlerinin bağlı olmadığı bu ölçeklenebilirlik sınırlamaları nelerdir? Oracle RAC veya MySQL parçalama veya Teradata (vb.) Gibi MPP RDBMS neden bu özellikleri elde edemiyor?
Teknik sınırlamalarla ilgileniyorum - RDBMS'yi kümelemenin finansal maliyetlerinin engelleyici olabileceğinin farkındayım.
Yanıtlar:
MS , Hollanda'da bu konuların bazılarını tartıştıkları bir teknoloji konuşması yaptı . Yavaşça başlar, ancak 20 dakikalık işaretin etrafında Hadoop etine girer.
Bunun özü "o bağlıdır". Eğer (en azından biraz) homojen bir veriyi bölümlere ayırmak için (en azından biraz) kolay anlaşılır bir şekilde düzenlenmişseniz, ne yaptığınıza bağlı olarak RDBMS ile bu yüksek veri hacimlerine ölçeklendirmek oldukça kolay olmalıdır. .
Hadoop ve MR, özellikle bu veriler mutlaka RDBMS dünyasında bulduğumuz kadar homojen veya yapılandırılmış olmadığında, büyük dağıtılmış veri taramalarına zorlandığınız durumlara daha uygun görünmektedir.
Büyük Veri çözümleri hangi sınırlamalara bağlı değildir? Bana göre, bağlı olmadıkları en büyük sınırlama vaktinden önce katı bir şema yapmak zorunda. Büyük Veri çözümleriyle, artık büyük miktarda veriyi "kutuya" aktarırsınız ve verilerin homojenliği ile başa çıkmak için daha sonra sorgularınıza mantık eklersiniz. Geliştiricinin bakış açısından, takas, projenin ön ucunda uygulama kolaylığı ve esneklik, sorgulamadaki karmaşıklık ve daha az veri tutarlılığıdır.
Veritabanı öncüsü ve araştırmacı Michael Stonebraker , geleneksel veritabanı mimarilerinin sınırlamalarını tartışan bir makale yazdı . Genellikle, daha pahalı donanımlarla ölçeklenirler, ancak paralel olarak daha fazla emtia donanımıyla ölçeklendirmede zorluk çekerler ve daha eski bir dönem için tasarlanmış eski yazılım mimarisi ile sınırlıdırlar. BigData döneminin, modern altyapıdan yararlanan ve belirli bir iş yükü için optimize edilen çok sayıda yeni veritabanı mimarisi gerektirdiğini iddia ediyor. Bunun örnekleri, Vertica Systems ticari veritabanına yol açan C-store projesi ve yüksek hızlı BigData iş yükleri için tasarlanmış bir bellek içi OLTP SQL veritabanı olan VoltDB'ye yol açan H-store projesidir. (Tam açıklama, VoltDB için çalışıyorum).
Bu web seminerini bu konuda ilginç bulabilirsiniz . NoSQL veritabanlarının başarısı ile ortaya çıkan bazı mitlere yanıt verir. Temel olarak, SQL'in sorun olmadığını, performans elde etmek için tutarlılık gibi geleneksel veritabanı özelliklerinden vazgeçmek gerekmediğini iddia ediyor.
RDBMS'nin ölçeklenemediği tamamen doğru değildir. Ancak, açıklamadaki kısmi gerçek mimariye bağlıdır. Verdiğiniz listede Oracle RAC diğerlerinden farklı (parçalanmış MySQL ve Teradata). En büyük fark paylaşılan disk vs paylaşılan hiçbir şey mimariler.
Oracle RAC gibi paylaşılan disk mimarileri ölçeklenmekten muzdariptir, çünkü bir noktada veya diğer tüm çalışan makineler verilerin bir kısmında senkronize edilmelidir. Örneğin, küresel kilit yemlik bir katildir. Bir dereceye kadar ince ayar yapmaya devam edebilirsiniz, ancak sonuçta bir duvara çarpacaksınız. Kolayca makine ekleyemiyorsanız, cebinizi yakabilecek daha az ama süper güçlü makinelere sahip olmalısınız. Hiçbir şeyin mimarileri (veya parçalanmış verileri) paylaşması durumunda, her makine bazı verilerin sahipliğini alır. Bazı verileri güncellemek istiyorsa diğer mahcines ile senkronize edilmesi gerekmez.
Sonra NoSQL veritabanlarının cinsi geliyor. Onlara geleneksel RDBMS veritabanlarının bir alt kümesini ele alırdım. Bu dünyadaki tüm uygulamaların RDBMS tarafından sunulan tüm işlevlere ihtiyacı yoktur. Veritabanını önbellek olarak kullanmak istersem, dayanıklılığı önemsemem. Bazı durumlarda tutarlılığı da önemsemem. Tüm veri aramam bir anahtara dayanıyorsa, aralık sorguları için desteğe ihtiyacım yok. İkincil dizinlere ihtiyacım olmayabilir. Tüm geleneksel veritabanlarına sahip tüm sorgu işleme / sorgu optimizasyon katmanı gerekmez.