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

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

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

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

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

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

81
cassandra data-processing hadoop hbase nosql

3 ответов

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

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

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

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

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

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

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

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

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

  • все Кассандра RPC бережливость, HBase имеет бережливость, отдых и родной Java. Бережливость и отдых предлагают только подмножество общего клиентского API, но если вы хотите чистую скорость, есть собственный клиент Java.

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

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

89

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

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

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

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

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

113

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

22