Широкомасштабна обробка даних Hbase проти Кассандри [закрито]


84

Після мого дослідження масштабних рішень для зберігання даних я ледь не потрапив у Кассандру. Але загалом кажуть, що Hbase є кращим рішенням для широкомасштабної обробки та аналізу даних.

Хоча обидва є однаковим сховищем ключа / значення, і обидва вони / можуть працювати (Cassandra нещодавно) рівень Hadoop, тоді що робить Hadoop кращим кандидатом при обробці / аналізі великих даних.

Я також знайшов хороші подробиці про обидва на http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/

але я все ще шукаю конкретні переваги Hbase.

Хоча я більше впевнений у Кассандрі, оскільки її простота додавання вузлів та безшовна реплікація та відсутність особливостей відмови. І він також зберігає функцію вторинного індексу, що є хорошим плюсом.

Відповіді:


91

Намагання визначити, що найкраще для вас, насправді залежить від того, для чого ви його будете використовувати, кожен із них має свої переваги, і без жодних деталей це стає більше релігійною війною. Цій публікації, на яку ви посилалися, також більше року, і з тих пір обидва вони зазнали багатьох змін. Будь ласка, майте на увазі, я не знайомий з останніми розробками Кассандри.

Сказавши це, я перефразую комбінатара HBase Ендрю Пертелла і додам кілька власних вражень:

  • HBase знаходиться у великих виробничих середовищах (1000 вузлів), хоча це все ще знаходиться в основі встановлення ~ 400 вузлів Кассандри, так що це справді незначна різниця.

  • HBase і Cassandra підтримують реплікацію між кластерами / центрами обробки даних. Я вважаю, що HBase більше піддається користувачеві, тому це здається складнішим, але тоді ви також отримуєте більшу гнучкість.

  • Якщо вашій програмі потрібна сильна узгодженість, то HBase, швидше за все, краще підходить. Він розроблений з нуля, щоб бути послідовним. Наприклад, це дозволяє простішу реалізацію атомних лічильників (я думаю, що Кассандра щойно їх отримала), а також операції Check and Put.

  • Ефективність написання чудова, наскільки я розумію, це була одна з причин, чому Facebook погодився з HBase для свого месенджера.

  • Я не впевнений у поточному стані замовленого секціонера Кассандри, але раніше він вимагав ручного перебалансування. HBase обробляє це для вас, якщо хочете. Впорядкований розділ важливий для обробки стилю Hadoop.

  • Кассандра і HBase є складними, Кассандра просто краще приховує це. HBase виставляє це більше, використовуючи HDFS для його зберігання, якщо поглянути на кодову базу Кассандра така ж шарувата. Якщо порівняти документи "Динамо" та "Бігтабл", то можна побачити, що теорія дії Кассандри насправді є більш складною.

  • HBase має більше модульних тестів FWIW.

  • Весь Cassandra RPC є економним, HBase має Thrift, REST та рідну Java. Thrift та REST пропонують лише підмножину загального клієнтського API, але якщо ви хочете мати чисту швидкість, рідний клієнт Java є.

  • Є переваги як для однолітків, так і для господарів-рабів. Налаштування master - slave загалом полегшує налагодження та значно ускладнює.

  • HBase не прив'язаний лише до традиційного HDFS, ви можете змінити основне сховище залежно від ваших потреб. MapR виглядає досить цікаво, і я чув хороші речі, хоча сам не користувався ним.


117

Як розробник Cassandra, я краще відповім на іншу сторону питання:

  • Кассандра краще лущиться. Відомо, що Кассандра масштабується до понад 400 вузлів у кластері ; коли Facebook розгорнув обмін повідомленнями поверх HBase, їм довелося розбивати їх на 100-вузлові підкластери HBase .
  • Кассандра підтримує сотні, навіть тисячі сімей Стовпців. " HBase в даний час погано справляється з будь-чим із двох-трьох сімейств колонок ."
  • Як повністю розподілена система без "спеціальних" вузлів або процесів , Кассандра простіша в налаштуванні та експлуатації , простіша для усунення несправностей і більш надійна.
  • Підтримка Кассандри мульти-майстер-реплікації означає, що ви не тільки отримуєте очевидну потужність декількох центрів обробки даних - географічну надмірність, локальні затримки - але ви також можете розділити навантаження в режимі реального часу та аналітичні роботи на окремі групи з двосторонньою реплікацією в режимі реального часу . Якщо ви не розділите ці робочі навантаження на частини, вони змагатимуться ефектно.
  • Оскільки кожен вузол Кассандри управляє власним локальним сховищем, Кассандра має значну перевагу в продуктивності, яка навряд чи суттєво звузиться. (Наприклад, це стандартна практика розміщувати журнал комітів Cassandra на окремому пристрої, щоб він міг робити свої послідовні записи безперешкодно випадковим введенням-виведенням із запитів на читання.)
  • Кассандра дозволяє вибирати, наскільки сильно ви хочете, щоб вона вимагала послідовності для кожної операції. Іноді це неправильно розуміють як "Кассандра не дає тобі сильної послідовності", але це неправильно.
  • Кассандра пропонує RandomPartitioner, а також більш упорядкований Partitioner, схожий на Bigtable. RandomPartitioner набагато менше схильний до гарячих точок.
  • Кассандра пропонує кешування в купі або поза купою з продуктивністю, порівнянною з memcached, але без проблем узгодженості кешу або складності вимагання додаткових рухомих частин
  • Клієнти, які не є Java, не є громадянами другого сорту

Наскільки мені відомо, основною перевагою HBase зараз (HBase 0.90.4 та Cassandra 0.8.4) є те, що Cassandra ще не підтримує прозоре стиснення даних. (Це було додано для Cassandra 1.0 , що має відбутися на початку жовтня, але сьогодні це справжня перевага для HBase.) HBase також може бути краще оптимізовано для видів сканування діапазону, зроблених за допомогою пакетної обробки Hadoop.

Є також речі, які не обов’язково кращі чи гірші, просто різні. HBase суворіше дотримується моделі даних Bigtable, де кожен стовпець має неявні версії. Кассандра відмовляється від версій і замість них додає SuperColumns.

Сподіваюся, це допоможе!


13
Я майже впевнений, що Facebook розбиває кластери на 100 вузлових кластерів HBAse з інших причин, пов'язаних з їх модульним стеком програмного забезпечення. На нещодавній розмові Тодд Ліпкон із Cloudera згадував 1PT 1000 вузол кластерів HBase, і я бачив, як згадується 700+ вузол кластерів HBase.
cftarnas

1
Гарна думка. Це може бути і щось, що залежить від навантаження.
jbellis

1
Стільки переваг Кассандри вище. Але чому Facebook врешті вибрав HBase замість Кассандри !?
Іван Ворошилін

5
Сукупність (а) людей у ​​групі обміну повідомленнями, які вже знайомі з Hadoop та HBase, (b) погане розуміння моделі послідовності Кассандри та (c) не звернення до спільноти Apache Cassandra за допомогою (b). Зовсім недавно, Facebook підрозділи , такі як Instagram і синтаксичного аналізу вибрали Cassandra: planetcassandra.org/blog/post / ... planetcassandra.org/blog/post / ...
jbellis

23

Причина використання кластерів 100 вузлів hBase полягає не в тому, що HBase не масштабується до більших розмірів. Це тому, що простіше постійно оновлювати програмне забезпечення hBase / HDFS, не збиваючи всю службу. Іншою причиною є запобігання тому, щоб один NameNode був SPOF для всієї служби. Крім того, HBase використовується для різних служб (а не лише для повідомлень FB), і розумно мати підхід до вирізання файлів cookie для створення численних кластерів HBase на основі підходу з 100 вузлами. Число 100 є adhoc, ми не зосереджувались на тому, чи є 100 оптимальним чи ні.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.