Comments 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 все тянуть на клиент. Но возможности конечно достаточно большие
UFO just landed and posted this here
Одна физическая железка. Увеличить диск на сервере тоже не всегда можно, тогда будет момент когда упрешься в скорость по обработке данных (чтение, запись)
есть еще 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. Бигдата проекты живут долго, поэтому если изначально удовлетворял требованиям — будет использоваться, пока не взорвется.
Sign up to leave a comment.
Big Data от А до Я. Часть 4: Hbase