Какое будущее ждет корпоративные высокопроизводительные системы хранения? По каким направлениям развиваются технологии? Эти вопросы волнуют сегодня многие компании. В основу статьи легла оценка рынка, высказанная Раулем Сринивасаном (Rahul Srinivasan), системным архитектором по ETL/ELT-системам в компании zData.
По его мнению, это направление будет продолжать динамично развиваться. Импульсом служит прогноз, что компаниям в будущем придется работать с огромными массивами разнообразных данных, поэтому задачи их надежного хранения и быстрого и эффективного извлечения будут играть большое значение.
На рынке в последнее время появилось множество разных СХД, выделяющихся теми или иными характеристиками. Одни из них обращают на себя внимание огромными резервами объема, исчисляемых петабайтами, другие — повышенной производительностью, третьи — эффективными средствами аналитической обработки данных, которые активно накапливаются сейчас в компаниях.
Сринивасана выделил три направления развития систем хранения, которые, по его мнению, представляют сегодня наибольший интерес. Это — файловые хранилища Hadoop, базы данных In-Memory и облачные СХД.
Распределенное файловое хранилище Hadoop (HDFS)
Система HDFS представляет собой кластерное хранилище, выстраиваемое из элементов двух типов: управляющего NameNоde-сервера и информационных DataNode-серверов, где хранятся непосредственно данные. Задача NameNode-сервера состоит в управлении пространством имен файловой системы и поддержкой доступа клиентов к данным. Сама передача данных производится напрямую, между клиентом и DataNode-сервером, что обеспечивает высокую эффективность и позволяет разгрузить управляющий NameNode-сервер.
Данные в HDFS хранятся в виде цепочек блоков фиксированного размера. Копии блоков, именуемые репликами, хранятся раздельно, в разных местах. По умолчанию в HDFS формируется три копии реплики: первая размещается на локальном ноде, вторая на другом ноде в той же серверной стойке, третья на ресурсах другой стойки. Ограничений на количество создаваемых реплик нет, что позволяет масштабировать хранилище, исходя из целей прикладной задачи. Такая гибкость обеспечивает возможность сохранения поистине огромных объемов информации. Они могут размещаться на многочисленных нодах, а количество копий реплик может исчисляться тысячами.
Для хранения данных в HDFS используется так называемая «архитектура без разделения ресурсов» (Shared Nothing Architecture). Благодаря ей в системе поддерживается единый образ базы данных при работе с несколькими вычислительными устройствами, каждое из которых работает под управлением собственной копии ОС.
Каждый узел системы использует собственную оперативную память и собственное хранилище на жестких дисках, доступ к ним не разделяется между отдельными узлами единой системы хранения. Разделяемым в ней является только общий коммуникационный канал между узлами. Это позволяет легко наращивать производительность путем добавления процессоров, дополнительных объемов оперативной и дисковой памяти в каждом узле, подключения новых узлов.
Модель целостности данных, реализованная в HDFS, не гарантирует идентичность сохраненных реплик. HDFS перекладывает проверку целостности на клиентов, которые при считывании файла запрашивают также контрольные суммы. В случае обнаружения несоответствия запрос переадресуется к выборке другой реплики.
Общим недостатком таких систем, который, впрочем, не ведет к возникновению критических ошибок, является отсутствие автоматического перезапуска нодов в случае сбоя. Если такой инцидент случается, то запрос переадресуется к считыванию другой реплики.
Для доступа к данным чаще всего применяется механизм MapReduce. Помимо него на рынке существует ряд других инструментов, применение которых делают доступ к данным в HDFS не сложней обращений к традиционным реляционным хранилищам.
Рекомендуемые области применения: большие данные для хранения огромных массивов структурированной, слабоструктурированной и разрозненной информации. Чаще всего HDFS применяют для хранения архивов постоянно накапливаемых данных и для записи массивов, из которых требуется периодически извлекать небольшие порции информации. Извлеченные данные используются для подготовки отчетов, причем имеется возможность быстро получить данные также за счет вызова встроенных функций отчетов HDFS.
Ограничения: невысокая скорость масштабирования хранилища; невозможность быстро получить отчеты на сравнительно небольших объемах данных.
Основные вендоры: Hortonworks, Cloudera, Pivotal.
Базы данных In-Memory (In-Memory Data Base, IMDB)
Если рассматривать хранилища этого типа упрощенно, то их можно представить как системы, использующие оперативную память в качестве основного хранилища. Благодаря такой архитектуре решения получают значительный прирост в быстродействии. Это принято считать главным достоинством систем хранения IMDB.
Хотя все данные в IMDB хранятся в оперативной памяти, эти системы все равно предусматривают наличие хранилища на жестких дисках. Каждая операция работы с данными не только работает с оперативной памятью, но вдобавок записывает соответствующую информацию в журнал транзакций, который располагается на жестком диске. Записи ведутся в режиме последовательного доступа, чем эти системы качественно отличаются от традиционных систем хранения на жестких дисках, где запись ведется в режиме произвольного доступа — значительно более медленного, чем последовательный.
При считывании данные берутся из быстрой оперативной памяти. Если в СУБД поступает запрос, не требующий внесения изменений в сами данные, то обращений к жесткому диску не происходит вообще.
Насколько база данных IMDB более производительна, можно судить по результатам сравнительного тестирования, опубликованным изданием iApplianceWeb. Для корректного сравнения они перенесли традиционную базу данных с физического на RAM-диск. Это позволило увеличить скорость чтения в четыре раза, а скорость обновления данных выросла в три раза. Затем они провели сравнение IMDB с этой традиционной СУБД, развернутой в оперативной памяти на RAM-диске. Результат: модель IMDB обеспечила
Хранилища IMDB, как и HDFS, используют «архитектуру без разделения ресурсов» (Shared Nothing Architecture). Это обеспечивает им отличную масштабируемость, быструю репликацию данных. Данные хранятся в оперативной памяти в ненормализуемом виде, что способствует дополнительному росту производительности при их извлечении.
Основная слабость IMDB — ее стоимость. Несмотря на то, что цены на оперативную память неуклонно падают, они по прежнему намного выше, чем у твердотельных систем. При установке систем IMDB приходится выбирать дорогостоящие инфраструктурные решения, способные обеспечить бесперебойное питание, и применять схемы регулярной репликации данных на твердые носители.
Рекомендуемые области применения: анализ данных; CEP-системы с быстрой реакцией на события; OLTP-системы для авторизации и проведения онлайн-транзакций; системы аналитики реального времени; электронная коммерция; JSON-системы для работы со слабоструктурированными данными.
Ограничения: Сверхбольшие данные (размер которых исчисляется петабайтами); модели хранения, требующие объединения и нормализации данных.
Основные вендоры: Aerospike, Cassandra, Couchbase, GridGain, MemSQL, Mongo DB, Oracle (TimesTen), Redis, SAP (HANA), Tarantool.
Облачное хранилище данных
Под облачным хранилищем понимают модель онлайн-хранения, при котором данные размещаются на многочисленных серверах, распределенных в сети и обслуживаемых специализированным провайдером; смысл его сервисной услуги состоит в предоставлении клиентам данных в пользование.
В отличие от хранения данных на собственных выделенных серверах, приобретаемых или арендуемых компаниями специально для этих целей, количество и внутренняя структура облачных серверов не видна клиенту. С его точки зрения хранение и обработка данных выглядят как работа большого виртуального сервера. Реальная же картина оказывается значительно сложней, причем физические серверы могут располагаться географически на большой удалении от клиента.
Главными достоинствами облачного хранения называют прежде всего сокращение затрат по сравнению с обслуживанием выделенного хранения данных, отличную масштабируемость и упрощение процесса управления данными.
Появление облачной модели хранения послужило импульсом для динамичного развития хранилищ с массивно-параллельной архитектурой обработки (massive parallel processing, MPP). Эти системы появились раньше, но сначала они размещались на выделенных корпоративных ресурсах. Сегодня появилась реальная возможность их переноса в облачную среду. Этим воспользовался ряд вендоров, которые, немного изменив названия своих продуктов, смогли благодаря облачной модели дополнить продукты новыми функциями (например, поддержкой слабоструктурированных данных) и получить обширные ресурсы для их масштабирования. В качестве примеров таких разработок можно назвать системы Teradata, Netezza и Greenplum.
Система Teradata была изначально разработана для непрерывной обработки больших объемов данных. В ее основе была использована модель массивно-параллельной обработки, реализованная на базе специализируемых, интегрированных аппаратно-программных систем поддержки принятия решений и создания собственных хранилищ данных. Облако сразу стало для Teradata средой для дальнейшего развития.
Решение IBM Netezza было построено для работы с хранилищами данных огромного размера, исчисляемого многими петабайтами. В них была решена задача высокопроизводительной обработки запросов и их анализа при минимальных затратах. Одна из особенностей: все аналитические процедуры с данными выполняются внутри хранилища, без перемещения данных, что обеспечило максимальную производительность.
В основу решения IBM Netezza легло применение архитектуры асимметричной массивной параллельной обработки данных (AMPP), где сочетается использование открытых блейд-серверов и дисковых хранилищ, а также фильтрация данных с помощью логических матриц, программируемых пользователем. Теперь это решение перешло в формат облачного.
Третье решение — Pivotal Greenplum. Оно представляет собой платформу для аналитики корпоративного класса, построенную на доработанной СУБД PostgreSQL, комбинированном использовании MPP-обработки реляционных баз и неструктурированных данных на базе кластеров Hadoop. Выбор архитектуры для Greenplum был нацелен на эффективную поддержку типовых операций аналитических БД: сортировка, агрегирование, объединение таблиц. Серверы сегментов ее данных способны эффективно обрабатывать запросы в режиме полного параллелизма, одновременно используя имеющиеся подключения к дискам и эффективное распределение потоков данных между сегментами. При этом каждый из узлов использует собственные ресурсы (память, дисковое пространство и т. д.) для выполнения задачи. Эта система теперь также получило статус облачной.
Главным препятствием на пути перехода компаний к облачной модели хранения всегда была безопасность. Под влиянием угроз многие до сих пор отказываются от рассмотрения даже в перспективе этого варианта построения корпоративного хранилища. Однако отрасль ответила на этот вызов созданием модели частного облака. Оно имеет сходные облачные характеристики, но обладает безопасным признаком — локальное размещение.
В последнее время идет процесс интенсивного развития средств безопасности для облачных хранилищ. Это позволяет сделать предположение, что в скором будущем многие компании могут пересмотреть свое негативное отношения к использованию облачных систем хранения.
Рекомендуемые области применения: Перевод традиционных баз данных в облачный формат обусловлен интересом наращивать объемы хранилища данных, добиваясь результата с наименьшими затратами.
Ограничения: Неструктурированные данные.
Основные вендоры: Snowflake, IBM Dash DB, Greenplum (Open Source).
