Документ обсуждает архитектуру HBase как распределенной, колоночной базы данных, способной обрабатывать огромные объемы данных с помощью технологий Big Data. Он также описывает функции и возможности HBase, включая поддержку версионности данных, агрегацию и репликацию, а также вопросы, связанные с распределением нагрузки и управлением метаданными. Документ подчеркивает важность новых подходов к обработке больших данных и предлагает сравнение HBase с другими NoSQL решениями.

1. BigData inside
Архитектурные изыскания в HBase
Анатолий Никулин

2. BigData
● Технологии позволяющие обработать такие объемы данных, которые ранее считались
недостижимыми. Данных так много, и скорость их обработки настолько велика, что
необходим совершенно другой подход, к обработке таких данных.
● Сотни миллионов и миллиарды записей
● Петабайты данных
● Распределенная архитектура
● Volume, Velocity, Variety (3V)
Объем
Скорость
Разнообразие
Вперед к рекордам:
1 ТБайт был обработан за 209 сек. на Hadoop кластере из 910 узлов
В апреле 2008 года

3. HBase
Распределенная, Column Oriented база данных.
В качестве хранилища, использует HDFS, поэтому физически
распологается на Hadoop кластере. Позволяет хранить данные в упорядоченном,
отсортированном виде
Возможности:
● Random access, к любой записи за O(1)
● В качестве выборок можно использовать различные варианты Scan + фильтры
● Поддержка версионности данных
● Schemaless. Все данные хранятся как массивы байт*
● Широкие возможности агрегации (в том числе JOIN), за счет фреймворка Hadoop MapReduce
● Репликация
● Шардинг
● Остсутствие Single point of failure, начиная с версии 0.92
● Write ones read more. Не возможны, модификации данных (классический Update)

4. Table: UsersTable
INFO HISTORY

5. Table: UsersTable 3D

6. У каждой ячейки, свой независимый от
других набор версий

7. ... только с боку

8. Физически, объекты каждой ColumnFamily хранятся в отдельном бинаном файле.

9. Chain

10. Chain + Chain = Region

11. Region + Region = RegionServer

12. Read

13. Write

14. Вид сверху

17. Казалось бы, при чём здесь
Zookeeper ?

18. Ходоки у Ленина

19. Длятех,ктоничегонепонял

20. Master Server (MS)
Это демон, ответственный за реорганизацию (split) регионов и мониторинг всех
RegionServer в кластере. Так же он является входной точкой, для изменения всех
метаданных. Обычно, MS физически распологается там же где и NameNode
Single point of failure
Что будет, если отвалится Master ?
В виду того, что клиенты общаются напрямую с SegionServer, система продолжит
функционировать. Такой режим называется "steady state" (устойчивое состояние), но
регионы при этом не смогут разделяться (split), и не получится изменять метаданные
Multi-Master
Есть возможность настроить режим multi-master. Создать несколько мастеров,
следовательно при падении одного, управление переходит к другому
LoadBalancer
Переодически, включается в работу балансировщик нагрузки, который перераспределяет
регионы, для лучшего баланса кластера
Вопросы которые не дают покоя

21. ● Не равномерное распределение ключей (rowKey) приведет к излишней нагрузке на
одну ноду, и idle всех остальных ? (hash - наше всё*)
● Какое максимальное количество колонок (Column Qualifier) можно создавать ?
● Что лучше 1 row и 1 000 000 колонок, или
1 000 000 rows с одной колонкой ?
● Какое максимально количество Column Family может быть ?
● HBase vs Cassandra ?

22. Еще вопросы ?
A vendor-independent comparison of NoSQL databases: Cassandra, HBase, MongoDB, Riak
http://www.networkworld.com/cgi-bin/mailto/x.cgi?pagetosend=/news/tech/2012/102212-nosql-263595.
html&pagename=/news/tech/2012/102212-nosql-263595.html&pageurl=http://www.networkworld.
com/news/tech/2012/102212-nosql-263595.html&site=printpage&nsdr=n
электропочта: 2anikulin at gmail.com