Обработка крупномасштабных данных Hbase vs Cassandra [закрыто]

Я чуть не приземлился на Кассандре после исследования крупномасштабных решений для хранения данных. Но в целом говорят, что Hbase - лучшее решение для крупномасштабной обработки и анализа данных.

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

Я также нашел хорошие сведения об обоих на http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/

но я все еще ищу конкретные преимущества Hbase.

Хотя я больше убежден в Cassandra, потому что это простота добавления узлов и бесшовной репликации, а также отсутствие функций точки отказа. И он также сохраняет функцию вторичного индекса, так что это хороший плюс.

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

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

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

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

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

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

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

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

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

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

• Есть преимущества как для однорангового узла, так и для ведущего ведомого. Настройка «ведущий-ведомый» обычно упрощает отладку и значительно снижает сложность.

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

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

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

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

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

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

Причина использования 100 узловых кластеров hBase не в том, что HBase не масштабируется до больших размеров. Это связано с тем, что проще выполнять обновления программного обеспечения hBase / HDFS непрерывно, не прерывая работу всего сервиса. Другая причина состоит в том, чтобы не допустить, чтобы один NameNode был SPOF для всей службы. Кроме того, HBase используется для различных служб (а не только для сообщений FB), и разумно использовать метод «вырезки cookie» для настройки многочисленных кластеров HBase на основе подхода из 100 узлов. Число 100 является специальным, мы не зацикливались на том, является ли 100 оптимальным или нет.