К свободе от проблемы Больших Данных

Сергей Кузнецов

Пока исследователи и разработчики умудряются справиться с вчерашними «большими данными», появляются новые Большие Данные новых видов, с которыми совладать по-прежнему невозможно. В этой связи сегодняшний всплеск ажиотажа вокруг Больших Данных во многом является искусственным. Вечность и призрачность проблемы вряд ли позволяют рассчитывать на ее полное и окончательное решение. Это плохо для пользователей и разработчиков приложений, но гарантирует постоянную занятость исследователей и разработчиков СУБД. Конечно, их деятельность напоминает попытки моряков доплыть до миража, навеянного фата-морганой, но сами эти попытки увлекательны и полезны, поскольку поддерживают само развитие человечества.

Большие Данные и перспективные СУБД

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

Проблема Больших Данных знакома обеим этим категориям. Объемы транзакционных баз растут из-за развития оперативных потребностей пользователей, бизнеса или науки. Например, транзакционные базы интернет-магазинов сильно увеличиваются в объеме при персонализации услуг. Объемы аналитических баз увеличиваются в силу своей природы — данные в них всегда только накапливаются и не уничтожаются. Другой серьезной причиной роста объема аналитических баз является потребность бизнес-аналитиков в привлечении новых источников данных, например черпаемых из открытых ресурсов Сети.

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

В первом десятилетии нового века исследователям во главе с Майклом Стоунбрейкером удалось нащупать пути решений обоих частных случаев, взяв за основу следующие общие принципы:

перенос вычислений как можно ближе к данным;

использование архитектуры без совместно используемых ресурсов (sharing nothing);

эффективное разделение данных по узлам системы с возможностью их репликации в нескольких узлах.

Первый принцип означает, что СУБД и приложения организуются таким образом, чтобы минимизировались пересылки данных между узлами системы. Очевидно, что важность этого принципа растет при росте объема данных. Следствием принципа является потребность в переносе приложений баз данных на сторону сервера.

Второй принцип говорит о возможности реального распараллеливания работы СУБД и приложений, поскольку при отсутствии общих ресурсов между узлами вычислительной системы (фактически при использовании кластерной архитектуры) уменьшается вероятность конфликтов.

Третий принцип обеспечивает эффективную параллельную обработку транзакций или эффективную поддержку оперативной аналитической обработки данных.

Все три принципа далеко не новы и датированы 80-ми годами прошлого века. Например, на принципах sharing nothing основывается популярная и эффективная параллельная СУБД Teradata, успешно используемая уже на протяжении нескольких десятков лет. Однако именно сегодня все три принципа удалось успешно применить при создании реально масштабируемых параллельных транзакционных и аналитических СУБД.

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

Пути решения проблемы больших транзакционных и аналитических данных намечены, но это не означает, что решены даже частные виды проблем. Например, транзакционные параллельные СУБД эффективно работают только при таком разделении данных, которое минимизирует число распределенных транзакций в имеющейся рабочей нагрузке, а при изменении рабочей нагрузки требуется перераспределять данные. Аналитические параллельные СУБД справляются со сложными аналитическими запросами только в тех случаях, когда разделение данных соответствует специфике запросов. Другими словами, время от времени приходится перераспределять данные громадного объема (в том числе и при горизонтальном масш