Büyük ölçekli veri işleme Hbase - Cassandra [kapalı]

Büyük ölçekli veri depolama çözümleri üzerine yaptığım araştırmanın ardından neredeyse Cassandra'ya iniyordum. Ancak genel olarak Hbase'in büyük ölçekli veri işleme ve analizi için daha iyi bir çözüm olduğu söylenir.

Her ikisi de aynı anahtar / değer depolaması olmasına ve her ikisi de çalışabilir / çalıştırılabilir (yakın zamanda Cassandra) Hadoop katmanı, büyük veriler üzerinde işleme / analiz gerektiğinde Hadoop'u daha iyi bir aday yapan şeydir.

Ayrıca, http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/ adresinde her ikisi hakkında da iyi ayrıntılar buldum.

ama yine de Hbase'in somut avantajlarını arıyorum.

Cassandra hakkında daha çok ikna oldum çünkü düğüm ekleme ve sorunsuz çoğaltma ve hata noktası olmayan özellikler için basitliği. Ve aynı zamanda ikincil indeks özelliğini de korur, bu yüzden iyi bir artı.

Hangisinin sizin için en iyisi olduğunu belirlemeye çalışmak, onu ne için kullanacağınıza bağlıdır, her birinin kendi avantajları vardır ve daha fazla ayrıntı olmadan, daha çok dini bir savaş haline gelir. Referans verdiğiniz bu gönderi de bir yıldan daha eski ve o zamandan beri her ikisi de birçok değişikliğe uğradı. Lütfen daha yeni Cassandra gelişmelerine aşina olmadığımı da unutmayın.

Bunu söyledikten sonra, HBase görevlisi Andrew Purtell'i başka sözlerle açıklayacağım ve kendi deneyimlerimden bazılarını ekleyeceğim:

• HBase, daha büyük üretim ortamlarında (1000 düğüm), ancak bu hala Cassandra'nın ~ 400 düğüm kurulumlarının temelindedir, bu nedenle gerçekten marjinal bir farktır.

• HBase ve Cassandra, kümeler / veri merkezleri arasında çoğaltmayı destekler. HBase'nin kullanıcıya daha fazla ifşa ettiğine inanıyorum, bu yüzden daha karmaşık görünebilir, ancak o zaman daha fazla esneklik elde edersiniz.

• Uygulamanızın ihtiyacı olan şey güçlü tutarlılıksa, HBase muhtemelen daha iyi bir uyumdur. Baştan sona tutarlı olacak şekilde tasarlanmıştır. Örneğin, atomik sayaçların (Cassandra'nın yeni aldığını düşünüyorum) ve Check and Put işlemlerinin daha basit uygulanmasına izin verir.

• Yazma performansı harika, anladığım kadarıyla Facebook'un habercileri için HBase ile gitmesinin nedenlerinden biri buydu.

• Cassandra'nın sipariş edilen bölümleyicisinin şu anki durumundan emin değilim, ancak geçmişte manuel yeniden dengeleme gerektiriyordu. HBase, isterseniz bunu sizin için halleder. Sıralı bölümleyici, Hadoop tarzı işleme için önemlidir.

• Cassandra ve HBase'nin ikisi de karmaşıktır, Cassandra onu daha iyi gizler. HBase, depolaması için HDFS kullanarak bunu daha fazla açığa çıkarır, eğer kod tabanına bakarsanız Cassandra'nın katmanlı olduğu gibi. Dynamo ve Bigtable makalelerini karşılaştırırsanız, Cassandra'nın çalışma teorisinin aslında daha karmaşık olduğunu görebilirsiniz.

• HBase'de daha fazla birim testi FWIW var.

• Tüm Cassandra RPC'leri Thrift'tir, HBase'de Thrift, REST ve yerel Java bulunur. Thrift ve REST yalnızca toplam istemci API'sinin bir alt kümesini sunar, ancak saf hız istiyorsanız yerel Java istemcisi oradadır.

• Hem eşler arası hem de efendiden köleye avantajları vardır. Master - slave kurulumu genellikle hata ayıklamayı kolaylaştırır ve karmaşıklığı biraz azaltır.

• HBase yalnızca geleneksel HDFS'ye bağlı değildir, ihtiyaçlarınıza göre temel depolamanızı değiştirebilirsiniz. MapR oldukça ilginç görünüyor ve kendim kullanmadığım halde güzel şeyler duydum.

Cassandra geliştiricisi olarak, sorunun diğer tarafını yanıtlamakta daha iyiyim:

• Cassandra daha iyi ölçekleniyor. Cassandra'nın bir kümede 400'den fazla düğüme ölçeklendiği bilinmektedir ; Facebook, Mesajlaşma'yı HBase'in üzerine yerleştirdiğinde, onu 100 düğümlü HBase alt kümelerinde parçalamak zorunda kaldılar .
• Cassandra yüzlerce, hatta binlerce Sütun Ailesi'ni destekler. " HBase şu anda iki veya üç sütun ailesinin üzerindeki hiçbir şeyle iyi sonuç vermiyor ."
• "Özel" düğümler veya süreçler içermeyen tamamen dağıtılmış bir sistem olarak Cassandra'nın kurulumu ve çalıştırması daha kolaydır, sorun gidermesi daha kolaydır ve daha sağlamdır.
• Cassandra'nın çoklu ana makineli çoğaltma desteği, yalnızca birden çok veri merkezinin (coğrafi artıklık, yerel gecikmeler) bariz gücünü elde etmekle kalmaz, aynı zamanda gerçek zamanlı ve analitik iş yüklerini aralarında gerçek zamanlı, çift yönlü çoğaltma ile ayrı gruplara ayırabileceğiniz anlamına gelir . Bu iş yüklerini birbirinden ayırmazsanız, muhteşem bir şekilde mücadele edecekler.
• Her Cassandra düğümü kendi yerel depolamasını yönettiği için, Cassandra'nın önemli bir performans avantajı vardır ve bu avantajın önemli ölçüde daraltılması olası değildir. (Örneğin, Cassandra commitlog'unu ayrı bir cihaza koymak standart bir uygulamadır, böylece okuma isteklerinden gelen rastgele i / o ile sıralı yazma işlemlerini engellemeden yapabilir.)
• Cassandra, her işlem için tutarlılık gerektirmesini istediğiniz kadar güçlü seçmenize olanak tanır. Bazen bu "Cassandra size güçlü bir tutarlılık sağlamaz" şeklinde yanlış anlaşılır, ancak bu yanlıştır.
• Cassandra RandomPartitioner'ın yanı sıra daha Bigtable benzeri OrderedPartitioner'ı sunar. RandomPartitioner, sıcak noktalara çok daha az eğilimlidir.
• Cassandra, memcached ile karşılaştırılabilir bir performansla yığın içi veya yığın dışı önbelleğe alma sunar, ancak önbellek tutarlılığı sorunları veya ekstra hareketli parçalar gerektirme karmaşıklığı olmadan
• Java dışı istemciler ikinci sınıf vatandaş değildir

Bildiğim kadarıyla, HBase'nin şu anda sahip olduğu temel avantaj (HBase 0.90.4 ve Cassandra 0.8.4) Cassandra'nın şeffaf veri sıkıştırmayı henüz desteklemiyor olmasıdır. (Bu, Ekim ayı başlarında olması nedeniyle Cassandra 1.0 için eklenmiştir , ancak bugün bu HBase için gerçek bir avantajdır.) HBase, Hadoop toplu işleme tarafından yapılan aralık taramaları türleri için daha iyi optimize edilebilir.

Daha iyi veya daha kötü olmayan, sadece farklı olan bazı şeyler de vardır. HBase, her bir sütunun örtük olarak sürümlendirildiği Bigtable veri modeline daha sıkı bir şekilde bağlıdır. Cassandra sürüm oluşturmayı bırakır ve bunun yerine SuperColumns ekler.

Umarım yardımcı olur!

100 düğüm hBase kümelerini kullanmanın nedeni, HBase'nin daha büyük boyutlara ölçeklenmemesi değildir. Bunun nedeni, tüm hizmetinizi kesintiye uğratmadan hBase / HDFS yazılım yükseltmelerini sürekli olarak yapmak daha kolaydır. Diğer bir neden, tek bir NameNode'un tüm hizmet için bir SPOF olmasını engellemektir. Ayrıca HBase, çeşitli hizmetler için (sadece FB mesajları değil) kullanılıyor ve 100 düğümlü kapsül yaklaşımına dayalı çok sayıda HBase kümesi kurmak için bir çerez kesici yaklaşıma sahip olmak akıllıca olacaktır. 100 sayısı anlıktır, 100'ün optimal olup olmadığına odaklanmadık.