Колоночные

Записаться

Следующий большой тип баз - это колоночные базы. Мы тоже их упоминали, мы их противопоставляли реляционным базам тем, что реляционные базы оперируют строками, а колоночные базы, можно себе представить, что они оперируют столбцами. Есть еще одна абстракция, которая хорошо объясняет, зачем эти базы были придуманы и почему именно колоночный подход реализован. Это абстракция очень большой таблицы. Во-первых, внутри ячейки хранения у нас хранятся структурированные данные, мы можем получить доступ к множеству атрибутов этих данных. Далее, наши атрибуты могут быть представлены колонками в абстракции табличного хранения, эти колонки могут быть сгруппированы в семейства логические и предоставлять некоторую локализацию по атрибутам. Колонки сгруппированы заранее, но внутри семейства или группы колонок поддерживаются изменения, то есть можно добавлять колонки в процессе уже накоплений наших данных, работы с ними. Масштабирование использует репликацию, также есть автоматический шардинг, то есть автоматическое добавление, удаление серверов для хранения. Данные системы оптимизированы для записи, чтение у нас происходит медленнее, отсюда следует приложение, которое часть реализовывают на данных базах - это высокие потоки данных, лента активности и очередь сообщений, кеширование, веб-логи всей системы, которая требует глубокого, но не быстрого анализа, аналитические системы, системы поисковой индексации и так далее.

Самым ярким представителем является HBase, я думаю, наравне с ним может быть больше известна Google BigTable, который возник ранее, но был внутренним продуктом Google для решения их собственных задач, конкретно для хранения результатов поисковой системы. HBase - это часть проекта Hadoop. Apache, которые честно признаются, что по статьям и публикациям Google делали клон, и впоследствии Google запатентовала, передала Apache права на использование данной схемы, это NoSQL, в первую очередь, хранилище.

Итак, что такое абстракция большой таблицы? Это абстракция, которая подразумевает, что у нас не только миллиарды строк, но у нас и миллионы столбцов, когда у нас нет ограничений на количество столбцов, и это понятно, когда мы пытаемся сконструировать, спроектировать приложение, которое получает или объединяет данные из разных источников. Предполагается, что из одного источника мы можем получать данные в объект с одними атрибутами, из других источников можем получать данные от тех же объектов с другими атрибутами, если мы будем укладывать их в базу, то у нас получится очень много пустых ячеек такая база называется Sparse или разреженная, данный механизм исключает хранение пустых ячеек, мы при указании атрибутов данных объектов просто не указываем те, которых у него нет, и они не занимают место. Таким образом мы как раз и переходим на хранение колонок, а не записей. Мы можем хранить еще и тысячи версией ячеек, и хранить наши данные на тысячах серверов, вплоть до петабайтов по размеру.

Здесь слайд для тех, кто впервые сталкивается с NoSQL базой данных, переходит со стандартной реляционной базы данных, и нужно сразу отказаться части своего опыта и части понимания, представления о базе данных. В первую очередь нужно отказаться от того, что HBase, в частности, в NoSQL в общем и колоночные базы в части этого общего не всегда является заменой вашей реляционной базе данных. Возможно, ваша задача полностью решается и лучше всего решать с реляционными базами данных, и здесь как раз граница проходит по тому, насколько ваши данные структурированные. Если они у вас структурированные и структура не меняется или меняется совсем-совсем незначительно, то нет никакого смысла переезжать с реляционных баз данных. Если ваши данные критичны к потере, у вас есть транзакции, вам нужно в любой момент времени иметь сильную согласованность данных, то вам тоже не стоит приезжать с ваших реляционных баз данных.

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

Как реализовано хранение неструктурированных данных, к тому же еще и с поддержкой версии? Реализуется эта абстракция следующим образом: составляются наборы — таблица, ключ строки или записи, семейство колонок, колонка, временная метка и значение. В значении может быть все, что угодно, в том числе документ любой структуры сложности, но то, что вынесено явно, атрибут, вынесенный, обозначеный как колонки и сгруппированный в семейство колонок, будет проиндексировано и, поэтому, можно делать выборки, обращаться в селектах. То, что лежит внутри самой ячейки вашего значения, то не индексируется. Ключи строк являются обыкновенными строковыми значениями, они таким образом индексируется, могут даже каким-то нетривиальным способом проиндексированы быть, то есть несколько индексов. Дальше у нас есть атрибуты, которые мы хотим индексировать, называем их колонками. Они могут быть сгруппированы в семейства по какому-то логическому признаку, например, все данные из одного источника всегда имеют этот набор атрибутов, и тогда мы называем это семейством атрибутов, нам это удобно. Все данные из другого источника всегда обладают другим набором атрибутов, и есть еще какой-то набор атрибутов, который очень случайный и меняется от объекта к объекту. Скорее всего, такую изменяющуюся структуру мы отнесем внутрь нашего значения ячейки. Плюс мы добавляем версионность, то есть каждая ячейка может хранить очень много значений, и простейший способ обозначить версию — это, как вы видели ранее, добавление временной метки в наш набор, по которому индексируются данные. То есть, если данные обновляются, и обновляются часто, они просто складываются в хранилище, эта же временная метка позволяет нам разрешать конфликты при распределении хранения или синхронизации значений, или в случае восстановления после сбоев. Количество версий конкретно в реализации базы данных HBase - это устанавливаемый параметр, мы можем сами для себя определять, сколько версий значений мы хотим хранить.

Наборы строк в совокупности с семействами колонок могут образовать так называемые регионы данных, это единица сохранения. Эти регионы данных мапируются на файлы в файловой системе, в данном случае Hadoop HDFS, и это уже конкретные блоки, которые размещаются в файловой системе. Соответственно, чтение, в том числе параллельная обработка с используемым механизмом MapReduce используется целиком такой блок-регион для обработки, и это нужно понимать, когда вы определяете размер региона и адаптируете его под свою задачу. Здесь приведен пример кода на Java, это элементарные операции, мы тоже видим объектный подход, сами операции put и get являются объектами, остальное достаточно прозрачно.

Сравнение HBase с обычной реляционной базой данных - это как раз для тех случаев, когда вы действительно принимаете решение, пережать или не переезжать с реляционной базы данных на NoSQL базу. В реляционной базе данных вы оперируете строками и колонками, в HBase вы оперируете разреженной и очень большой матрицей с незафиксированными колонками и типами данных. Транзакции в реляционной базе поддерживаются, в HBase поддерживаются только на уровне единичной записи, на уровне единичной записи даже реализуются эти требования. Язык запросов в реляционной базе SQL с достаточно гибкими возможностями, в случае HBase это простые get, put, scan (scan — это какой-то аналог find или select, таких операций), есть технология Hive, которая тоже является частью платформы Hadoop, но не является частью HBase. То есть это отдельный продукт, который может работать с теми же самыми данными, но используя Query Language, язык запросов и парадигму этого языка запросов, и абстракции таблицы данных. Индексы в реляционной базе данных возможны самые разные, в HBase только по ключам строк и по столбцам, но зато производительность и объем данных у HBase значительно превосходят из-за горизонтального масштабирования и автоматического шардинга, и непосредственно распределенных операций, производимых данными при помощи MapReduce, встроенного в платформу Hadoop.

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