Комментарии 21
В рамках альтернативы: вы не сравнивали hbase и cassandra?
У меня не было опыта по эксплуатации cassandra в промышленности в промышленности, только теоретические знания. Во многом эти базы данных похожи, так cassandra как и hbase имеет column families и практически неограниченно масштибируется "вширь", имеет возможность быть источником записей для map-reduce job'ов.
Самое главное отличие с моей точки зрения заключается в том, что cassandra и hbase имеют разные классы в рамках cap-теоремы
cassandra имеет класс AP, то есть она имеет децентрализованную архитектуру и любая нода можнт выполнять любую операцию, это достигается ценой отказа от консистентности данных
hbase имеет класс CP, то есть данные в hbase гарантировано консистентны, но hbase-кластер ре имеет свойства availability, то есть если например от него отвалится кусок — ноды в отвалившемся куске не смогут функционировать корректно.
В этом смысле cassandra находится ближе к классическим key-value хранилищам, таким как redis, и зачастую используется именно для быстрого доступа к данным, а hbase чуть ближе к file-oriented хранилищам
Самое главное отличие с моей точки зрения заключается в том, что cassandra и hbase имеют разные классы в рамках cap-теоремы
cassandra имеет класс AP, то есть она имеет децентрализованную архитектуру и любая нода можнт выполнять любую операцию, это достигается ценой отказа от консистентности данных
hbase имеет класс CP, то есть данные в hbase гарантировано консистентны, но hbase-кластер ре имеет свойства availability, то есть если например от него отвалится кусок — ноды в отвалившемся куске не смогут функционировать корректно.
В этом смысле cassandra находится ближе к классическим key-value хранилищам, таким как redis, и зачастую используется именно для быстрого доступа к данным, а hbase чуть ближе к file-oriented хранилищам
В целом, мой вопрос практический. Мы сейчас, имея не большую компетенцию и ограниченные ресурсы (банально да?! :))) пытаемся понять, куда нам лучше сохранять наши данные.
На текущий момент считать что-то мы будем в Spark (опять же, предварительно), а ему не так принципиален источник данных.
На текущий момент считать что-то мы будем в Spark (опять же, предварительно), а ему не так принципиален источник данных.
Мое ощущение что HBase он как Hive — стабильный, работает, но немного уже устарел.
Смотрите на cassandra и параллельно следите за Scylladb. Datastax connector для spark оч неплох.
Будьте аккуратны со структурами данных в cassandra. Организация данных сильно влияет на производительность. Продумывайте какие запросы будете делать. Ну и думайте сколько чего нужно будет читать, сколько надо будет держать в кеше итд.
Смотрите на cassandra и параллельно следите за Scylladb. Datastax connector для spark оч неплох.
Будьте аккуратны со структурами данных в cassandra. Организация данных сильно влияет на производительность. Продумывайте какие запросы будете делать. Ну и думайте сколько чего нужно будет читать, сколько надо будет держать в кеше итд.
Позновательно.
А можете еще упомянуть в статьях как использовать HttpFS / Hoop (HDFS ocer HTTP)? Или может у читателей есть опыт работы с ним.
Можно ли на основе этого решения реализовать некий Distributed CDN?
Hoop + nginx кажется хорошим вариантом
А можете еще упомянуть в статьях как использовать HttpFS / Hoop (HDFS ocer HTTP)? Или может у читателей есть опыт работы с ним.
Можно ли на основе этого решения реализовать некий Distributed CDN?
Hoop + nginx кажется хорошим вариантом
Отдельно хотелось бы добавить:
Для этого запускаются отдельные сервера-сервисы которые выступают проксей на нативный API и может оказаться, что узким местом и является этот самый прокси. Плюсом у вас клиент всегда стучится на один явный api сервер, а не на размазанный кластер, что очень хорошо позволяет сделать ограничение доступа.
Такая проблема возникла, что работа клиента представляет собой цикл: подключились к мастеру => забрали метаданные => постучались на нужный регион сервер. Сам же клиент при необходимости и метаданные у себя обновляет при миграции регионов, должен же он знать куда стучать. Накладываем на это собственный бинарный протокол и получаем, что сделать REST прокси на java оказывается проще, чем делать поддержку клиентов для разных языков. Сейчас ситуация исправляется за счет того, что протокол поменяли на protobuf и остается закодить только логику работы с серверами метаданных-данных, а не логику+бинарный протокол (который еще и меняли периодически).
Отдельно стоит упомянуть сопроцессоры (coprocessor) которые можно использовать как:
Для работы из других языков программирования Hbase предоставляет Thrift API и Rest API.
Для этого запускаются отдельные сервера-сервисы которые выступают проксей на нативный API и может оказаться, что узким местом и является этот самый прокси. Плюсом у вас клиент всегда стучится на один явный api сервер, а не на размазанный кластер, что очень хорошо позволяет сделать ограничение доступа.
Такая проблема возникла, что работа клиента представляет собой цикл: подключились к мастеру => забрали метаданные => постучались на нужный регион сервер. Сам же клиент при необходимости и метаданные у себя обновляет при миграции регионов, должен же он знать куда стучать. Накладываем на это собственный бинарный протокол и получаем, что сделать REST прокси на java оказывается проще, чем делать поддержку клиентов для разных языков. Сейчас ситуация исправляется за счет того, что протокол поменяли на protobuf и остается закодить только логику работы с серверами метаданных-данных, а не логику+бинарный протокол (который еще и меняли периодически).
Отдельно стоит упомянуть сопроцессоры (coprocessor) которые можно использовать как:
- тригеры — вешаются на любом из действий (prePut, postPut, preGet, postGet, etc.) и через них можно сделать как индексацию дополнительную (на вставке данных дополнительно обновлять еще какую ячейку, например поле SUM), так и проверку доступов (acl и throttling через них и сделаны)
- хранимые процедуры — позволяют расширять функциональность, например разослать на все машинки запрос посчитать сумму, а потом в клиенте сделать только агрегацию результатов, вместо того чтобы через scan все тянуть на клиент. Но возможности конечно достаточно большие
НЛО прилетело и опубликовало эту надпись здесь
Одна физическая железка. Увеличить диск на сервере тоже не всегда можно, тогда будет момент когда упрешься в скорость по обработке данных (чтение, запись)
есть еще MPP системы. Когда HBase будет лучше, а когда хуже?
Есть ещё новый проект в нише между Parquet и HBase, созданный Cloudera, — Kudu. Он всё ещё Beta, но я собираюсь его попробовать в новом проекте. Есть ли у кого-нибудь быть с ним? Самый привлекательный момент в Kudu проекте для меня — отсутствие JVM, написан Kudu на С++.
по мне главный плюс и минус kudu в отказе от использования hdfs:
1) плюс — мы не зависим от еще одной абстракции, точно управляем локальностью данных
2) минус — вопросы отказоустойчивости изобретаем повторно
наличие или отсутствие jvm зачастую сильно не решает основные вопросы: что и как храним и какие запросы делаем по данным,
так как практика показывает, что говнокод можно написать на любом языке =) хотя согласен что проект интересный и если будет опыт использования, то ждем статью ;)
1) плюс — мы не зависим от еще одной абстракции, точно управляем локальностью данных
2) минус — вопросы отказоустойчивости изобретаем повторно
наличие или отсутствие jvm зачастую сильно не решает основные вопросы: что и как храним и какие запросы делаем по данным,
так как практика показывает, что говнокод можно написать на любом языке =) хотя согласен что проект интересный и если будет опыт использования, то ждем статью ;)
У вас такой хороший, практически идеальный RowKey — уникальный равномерный ID, зачем вам вообще HBase? Выглядит так, что вам идеально бы подошло Key-Value хранилище. В чем преимущество HBase в данном случае?
Отличная статья для стартового понимания, что есть HBase. Все четко и по полочкам. Автору большой респект.
И вам спасибо! Рад что даже через 5 лет статья все еще актуальна!
что-то на мое имхо hbase как-то не актуален.
1. Тут можно глянуть что есть сценарии, где hbase гораздо быстрее Casandr'u
habr.com/ru/company/sberbank/blog/484096
2. Бигдата проекты живут долго, поэтому если изначально удовлетворял требованиям — будет использоваться, пока не взорвется.
habr.com/ru/company/sberbank/blog/484096
2. Бигдата проекты живут долго, поэтому если изначально удовлетворял требованиям — будет использоваться, пока не взорвется.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Big Data от А до Я. Часть 4: Hbase