Крупномасштабная обработка данных Hbase vs Cassandra

Ответ 1

Попытка определить, какая из них лучше для вас, действительно зависит от того, для чего вы собираетесь ее использовать, у каждого из них есть свои преимущества, и без каких-либо подробностей она становится скорее религиозной войной. Это сообщение, на которое вы ссылаетесь, также больше года, и с тех пор оба прошли множество изменений. Пожалуйста, имейте в виду, что я не знаком с более поздними событиями в Кассандре.

Сказав это, я перефразирую комбатанта HBase Andrew Purtell и добавлю некоторые из моих собственных переживаний:

• HBase находится в более крупных производственных средах (1000 узлов), хотя это все еще находится в шаге Cassandra ~ 400 node, поэтому его действительно незначительная разница.

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

• Если сильная согласованность - это то, что требуется вашему приложению, то HBase, скорее всего, лучше подходит. Он разработан с нуля, чтобы быть последовательным. Например, это позволяет упростить реализацию атомных счетчиков (я думаю, что Cassandra только что их получил), а также операции проверки и размещения.

• Запись производительности велика, из того, что я понимаю, это была одна из причин, по которой Facebook пошел с HBase для своего посланника.

• Я не уверен, что текущее состояние Cassandra заказало разделитель, но в прошлом ему требовалось ручное перебалансирование. HBase обрабатывает это для вас, если вы хотите. Заказываемый разделитель важен для обработки стиля Hadoop.

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

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

• All Cassandra RPC - это Thrift, у HBase есть Thrift, REST и родная Java. The Thrift и REST делают только предложение подмножества полного клиентского API, но если вы хотите получить чистую скорость, то есть собственный Java-клиент.

• Есть преимущества как для равноправных, так и для ведомых. Настройка master-slave обычно упрощает отладку и уменьшает сложность.

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

Ответ 2

Как разработчик Cassandra, мне лучше ответить на другую сторону вопроса:

• Кассандра лучше масштабируется. Известно, что Cassandra масштабируется до более 400 узлов в кластере; когда Facebook развернул Messaging поверх HBase, им пришлось обмануть его через 100- node подкластеры HBase.
• Cassandra поддерживает сотни, даже тысячи ColumnFamilies. " HBase в настоящее время не преуспевает ни с чем выше двух или трех семейств столбцов.
• Как полностью распределенная система без "специальных" узлов или процессов, Cassandra упростить настройку и работу, упростить устранение неполадок и повысить надежность.
• Поддержка Cassandra для репликации с несколькими мастерами означает, что вы не только получаете очевидную мощность нескольких центров обработки данных - географическую избыточность, локальные задержки - но вы также можете разделить оперативную и аналитическую нагрузку на отдельные группы с помощью в реальном времени, двунаправленная репликация между ними. Если вы не разделите эти нагрузки отдельно, они будут бороться эффектно.
• Поскольку каждая Cassandra node управляет собственным локальным хранилищем, Cassandra обладает существенным преимуществом производительности, которое вряд ли значительно сузится. (Например, стандартная практика заключается в том, чтобы поместить транзакцию Cassandra на отдельном устройстве, чтобы она могла делать свои последовательные записи беспрепятственными случайными вводами/выводами из запросов на чтение.)
• Cassandra позволяет вам выбирать, насколько сильно вы хотите, чтобы он требовал согласованности для каждой операции. Иногда это неправильно понимается, поскольку "Кассандра не дает вам сильной согласованности", но это неверно.
• Cassandra предлагает RandomPartitioner, а также более Bigtable-подобный OrderedPartitioner. RandomPartitioner гораздо менее подвержен воздействию горячих точек.
• Cassandra предлагает кеширование on-or или off-heap с производительностью, сопоставимой с memcached, но без проблем согласованности с кешем или сложности требующих дополнительных движущихся частей.
• Не-Java-клиенты не являются гражданами второго сорта.

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

Есть также некоторые вещи, которые не обязательно лучше или хуже, просто разные. HBase более строго придерживается модели данных Bigtable, где каждый столбец управляется версией неявно. Cassandra отключает управление версиями и вместо этого добавляет SuperColumns.

Надеюсь, что это поможет!

Ответ 3

Причина использования кластеров 100 node hBase заключается не в том, что HBase не масштабируется до больших размеров. Это связано с тем, что упростить обновление программного обеспечения hBase/HDFS можно быстро, не сводя на нет весь ваш сервис. Другая причина заключается в том, чтобы исключить одно имя NameNode для SPOF для всей службы. Кроме того, HBase используется для различных сервисов (а не только для сообщений FB), и разумно иметь подход к созданию cookie-cutter для создания множества кластеров HBase на основе подхода 100-w631 > pod. Число 100 является adhoc, мы не фокусируемся на том, является ли 100 оптимальным или нет.