Большие хранилища для больших данных

До самого последнего времени информационные системы страдали очевидной однобокостью, выполняя только три основные функции: передачу, хранение и обработку данных. При этом основное внимание уделялось лишь последней, и, как следствие, все разнообразие корпоративных приложений сводилось к задачам обработки транзакций. Для их решения требовались в первую очередь серверы, а скромные по своим масштабам системы хранения занимали подчиненное место. В сфере программных продуктов большое развитие получили реляционные базы, оптимизированные только для транзакционной работы – выполнения большого числа одновременных изменений в базе и обращения к ограниченному количеству данных. В условиях, когда акцент делался именно на обработку, на рынке СУБД началась стагнация – он оказался почти полностью монополизирован несколькими крупными игроками, и казалось, что его перспективы сводятся лишь к конкуренции между Oracle, DB2 и др., правда, некоторое разнообразие вносила открытая СУБД MySQL.

Примерно с 2005 года под влиянием возрастающего интереса к данным и к работающим с ними аналитическим приложениям установившееся положение стало меняться. Возникла потребность во вместительных хранилищах и в технологиях, отражающих специфику аналитической работы, которые бы учитывали, что данные только читаются (read-only) или в основном читаются (mostly read), но при этом каждый запрос требует «перелопачивания» большого объема данных.

Удовлетворить новым требованиям можно, используя несколько подходов. Кто-то идет по пути физической оптимизации устройств, кто-то совершенствует размещение данных на диске, с тем чтобы уменьшить число обращений, или же переносит данные в оперативную память, еще кто-то отказывается от строчного хранения в пользу поколоночного. Можно вообще ничего радикально не менять, сохранив верность традиционным подходам, и ограничиться усовершенствованиями в деталях. Вполне естественно, что по последнему пути пошли производители реляционных СУБД, расширившие функциональность своих продуктов за счет добавления специального индексирования, ориентированного на режим read-only. Несмотря на избыточность, сложность и высокую стоимость традиционных решений, следует принимать во внимание их сильную сторону – наличие подготовленных специалистов, сложившуюся интеграцию хранилищс программным обеспечением для бизнес-аналитики и технологиями интеграции данных. За последние годы ведущие производители реляционных СУБД сделали ряд приобретений и сегодня могут предложить полнофункциональные интегрированные платформы, включающие все необходимые инструменты, что делает их предложения весьма привлекательными.

Вместе с тем появляются и специализированные решения, и, как всегда в подобных случаях, возникает инженерная дилемма, что лучше – проверенные универсальные продукты с их очевидной избыточностью или специализированные с узкой функциональностью, но с более высокими тактико-техническими характеристиками. Хронологически первой по пути создания специализированных технологий для аналитических систем пошла компания Teradata, с 1984 года выпускавшая компьютеры MPP-архитектуры (massively parallel processing) для систем поддержки принятия решений и хранилищ данных. Более десяти лет компания не имела прямых конкурентов, но в последние годы открылась возможность для создания близких по возможностям систем из имеющихся на рынке стандартных продуктов, прежде всего из серверов-лезвий. Идеологически наиболее близкое решение – Netezza Performance Server (NPS), в нем стандартные лезвия сочетаются со специализированными лезвиями Snippet Processing Unit (SPU).

Компании Oracle и IBM пошли по тому же пути, подготовив свои технологии для кластеризации СУБД. Сначала Oracle выпустила совместное с HP решение Exadata на базе серверов Proliant, но после покупки Sun сменила его на систему Exadata V2 на базе Sun FlashFire. У IBM есть технология pureScale, близкая к Exadata по масштабируемости, скорости и цене, созданная на серверах Power 550 и 595. У HP тоже имеется собственная кластерная платформа хранилищ данных HP NeoView, построенная на MPP-архитектуре и серверах HP Itanium Integrity

Несколько компаний предлагают чисто программные решения на MPP-конфигурациях, собранных из стандартных серверов, среди них Greenplum, Aster Data, Kognitio. Более известна Greenplum, уникальность полиморфного решения Polymorphic Data Storage, предложенного этой компанией, состоит в том, что для отдельно взятого раздела базы данных могут быть заданы собственные параметры хранения, выполнения и компрессии, которые обеспечивают сосуществование трех различных моделей: традиционной строчной, оптимизированной для чтения/записи; строчной, но оптимизированной для чтения; поколоночной, оптимизированной для чтения. Решения Greenplum не привязаны к определенной аппаратной конфигурации, что оказалось их преимуществом при переходе к облакам, и, добавив расширение MapReduce, компания смогла выпустить платформу Enterprise Data Cloud.

Близкое по смыслу решение предлагает британская компания Kognitio, ее продукт WX2 – аналог продуктов Greenplum. Более сильным конкурентом Greenplum является компания Aster Data, в ее СУБД nCluster реализована технология, сочетающая в себе SQL и MapReduce. Компания Kickfire использует технологию программируемых логических матриц (FPGA) в сочетании с поколоночным хранением. Построенные на FPGA модули запросов QPM (Query Processor Module) подключаются по шине PCI-X к стандартному серверу Linux. Таким образом реализуется реконфигурируемая архитектура, адаптированная к выполнению запросов на SQL.

Очередной этап развития собственно CУБД связан с новыми базами, размещающими данные по колонкам. Они лишь недавно стали предметом всеобщего внимания, однако еще в начале 90-х существовало несколько компаний, в том числе Red Brick и Expressway, которые раньше других предложили базы данных типа read-only. Изначальной целью проектировщиков СУБД IQ Expressway было обеспечение высокой производительности при выполнении запросов, адресованных к очень большим таблицам в среде реляционных СУБД, и возможности инкапсулирования новых записей в проиндексированную таблицу. В 1993 году компания была куплена Sybase, и вскоре ее продукт Analytics Server был выпущен под названием IQ Accelerator, а затем переименован в Sybase IQ. Отличительная особенность Sybase IQ состоит в объединении индекса и данных – каждая колонка представляет собой индекс, дополненный для ускорения специализированными индексами, отражающими разнообразие значений в колонке.

Пионером в области высокопроизводительных СУБД для узкоспециальных приложений была компания Computer Corporation of America, перешедшая в апреле 2010 года в собственность компании Rocket Software. В силу специфических особенностей своей клиентской базы CCA мало известна и никогда не стремилась к публичности, но при этом всегда оставалась мощным исследовательским учреждением. Здесь были разработаны технологии хеширования и побитного индексирования (bitmapped indexing), первые онлайновые и распределенные СУБД и многое другое. Эти новации были реализованы в СУБД под названием Model 204, поставлявшейся для мэйнфреймов начиная с 1972 года. Model 204 соответствует требованиям работы со сверхбольшими базами данных и имеет высочайшие показатели производительности. Обновленная версия для современных многопроцессорных систем называется MP/204 или Multiprocessor/204 и отличается, в частности, наличием функции параллельных запросов Parallel Query Option. В ней есть язык и среда интуитивно понятного программирования User Language, поддерживается протокол WebSphere MQ для обмена сообщениями, но аналитические функции обеспечивает пакет CCA Analytics, созданный много лет назад.

Из колоночных СУБД нового поколения наибольшую известность приобрели ParAccel и Vertica, меньшей популярностью пользуются Kalido Dynamic Information Warehouse, SAP BW и Wherescape, EXASOL Illuminate и Infobright. Для этой группы характерна ориентация как на глобальные облака типа Amazon, так и на частные, а также на системы с массовым параллелизмом. Два года назад, отмечая значение успеха перечисленных компаний, Билл Инман сказал, что их преимущество заключается в более эффективном использовании оборудования и, следовательно, меньшей затратности, а также в существенно меньшей сложности. По его мнению, в мире насчитывается ограниченное число специалистов, действительно знающих и понимающих работу реляционных СУБД, оно измеряется десятками, в лучшем случае сотнями человек.

Канадская компания Infobright основана в 2005 году, а с 2008 года ее продукция стала свободной. Продукт Infobright Enterprise Edition интегрирован с MySQL, в нем реализована двухступенчатая схема, используемая также в СУБД Vertica. В данном случае MySQL выполняет функции первого уровня, то есть записываемого хранилища (Writeable Store, WS), далее формируется читаемое хранилище (Read-Optimized Store, RS), для чего таблица разбивается на столбцы, а столбцы – на хранимые по отдельности пакеты, при этом осуществляется компрессия данных. Параллельно формируется база метаданных Database Knowledge Grid, хранящая соответствие пакетов с традиционными индексами.

Производитель продукта Kalido Dynamic Information Warehouse, массачусетская компания Kalido, существует с 2003 года. Ее создал Энди Хэйлер на основании опыта разработок, выполненных в Royal Dutch Shell. Хранилище Kalido DIW построено на принципах моделирования данных, которые в оригинале называются generic data modeling¹. Суть этого подхода в отказе от физических структур для хранения данных и в использовании собственных, присущих данным закономерностей.

Небольшая компания illuminate Solutions, созданная Джозефом Фоли, возможно, единственная развивает направление, именуемое корреляционными базами данных (correlation database). Фоли разработал собственный оригинальный, не строчный и не колоночный, метод хранения Value-Based Storage (VBS) – архитектуру, где каждое значение хранится независимо, за счет чего база чрезвычайно компактна.

Наиболее популярным представителем колоночных СУБД является Vertica. Впервые эта СУБД была предложена в 2005 году, и тогда она называлась C-Store (Column-Store). Авторитет Майкла Стоунбрейкера, создателя компании Vertica и одного из основных авторов одноименной СУБД, по-видимому, стал главной причиной того, что использованный в этой базе принцип поколоночного хранения чаще всего связывают именно с Vertica, хотя с исторической точки зрения это не так. Ее предшественниками можно считать хорошо известную базу данных Sybase IQ, а также менее известные – СУБД Kdb+, выпускаемую с 1993 года компанией Kx Systems, и СУБД Addamark (теперь выпускавшая ее компания называется Sensage).

При создании аналитической СУБД Vertica авторы исходили из трех основных предпосылок. Первая – хранилища данных, как следует из названия, призваны хранить, следовательно, они наполняются такими данными, которые главным образом предназначены для последующего чтения, то есть, будучи единожды записаны, они редко изменяются, поэтому архитектура СУБД должна быть ориентирована прежде всего на оптимизацию операций чтения. Вторая предпосылка следует из формата строк. Данные, обрабатываемые в бизнес-аналитике, в основном состоят из широких строк – на одну строку приходится много атрибутов, но в типичных для BI запросах обычно используется всего несколько колонок, причем не из всех строк одновременно, а из некоторого их подмножества, входящего в состав базы. Третья предпосылка: при создании перспективных СУБД необходимо учитывать общую для всей индустрии тенденцию – использование общераспространенного оборудования, коммодитизацию. Следовательно, такая СУБД должна обеспечивать высокие показатели производительности и надежности, работая на относительно ненадежном и простом оборудовании. Из этих предпосылок следуют основные архитектурные принципы: поколоночная организация хранения, эффективные методы компрессии данных и разделение базы данных на две части (см. схему).

Первичная процедура записи осуществляется в хранилище WS (Writeable Store), приспособленное для записи, а затем сохраненные данные оптимальным образом переформатируются, упаковываются и перезаписываются в RS-хранилище (Read-optimized Store). Процессом перемещения из одного хранилища в другое управляет модуль, который изначально назывался Tuple Mover – «переносчик кортежей», а в последующем его переименовали в DB Designer. Каждое из двух названий по-своему отражает его функцию, этот модуль физически перемещает записи, но при этом одновременно осуществляет физическое проектирование RS, пользователь же освобожден от этой процедуры, и с его стороны достаточно выполнить логическое проектирование.

В Vertica данные каждой колонки хранятся в последовательно расположенных блоках на диске, независимо от других колонок. Колонки связаны в строки неявно, на основе относительного расположения атрибутов в колонке. Переход к поколоночному хранению не следует представлять упрощенно (если, мол, раньше таблицу нарезали по строкам, то теперь то же самое, но по колонкам) – хранимые колонки не являются вертикальными срезами, каждая из них хранит данные только из подмножества строк. Колонки одного формата записываются в область, называемую проекцией, проекции создаются по принципам общности входящих в них данных, с тем чтобы обеспечить максимальную скорость доступа к данным. Для ускорения работы с проекциями они дополняются индексами. Один и тот же фрагмент данных может попасть в несколько проекций.

В Vertica DB Designer реализовано множество способов компрессии:

• кодирование длин серий (Run-Length Encoding) или кодирование повторов – алгоритм сжатия, в котором строка одинаковых символов заменяется строкой, содержащей сам повторяющийся символ и количество его повторов;
• дельта-кодирование (Delta Value Encoding) – замена самих данных разницей между последовательными данными;
• алгоритм Лампеля – Зива – Велча (Lempel-Ziv-Welch, LZW) – универсальный алгоритм сжатия данных без потерь;
• специальные приемы работы с целочисленными и символьными данными.

Средствами DB Designer каждому фрагменту данных подбирается тот алгоритм, который ему лучше соответствует. Компрессия выполняется для уменьшения количества передаваемых данных, а потребность в ней вызвана тем, что в системах, собранных из общераспространенных компонентов, пропускная способность каналов ввода/вывода по определению не может быть высокой, ее можно полнее использовать, если возложить на процессоры функции декомпрессии.

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

Новая версия Vertica Analytic Database for the Cloud адаптирована для работы в облаке Amazon Elastic Compute Cloud. Наиболее близкими конкурентами Vertica являются СУБД Exasol и ParAccel. Если Vertica в большей степени ориентирована на размещение данных на диске, то эти две более активно используют оперативную память.