СУБД для сверхбольших объемов данных

О.С. Бартунов, Е.Б. Родичев.

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

Из планируемых научных экспериментов выделяются, в частности:

В каких направлениях идет развитие СУБД, чтобы отвечать новым требованиям?

Тем не менее, как считает видный участник DB-сообщества Майкл Стоунбрейкер, все это являются полумерами и требуется кардинальные изменения в технологии СУБД, а именно - изменение принципа хранения данных. Он считает, что эра обычных больших СУБД общего назначения прошла (см. One size fits all: A concept whose time has come and gone) и требуются совершенно новые подходы для создания современной БД, которая с самого начала будет ориентирована на распределенность, параллельное исполнение запросов, компрессию, ориентацию на хранение по атрибутам, высокую доступность, линейное масштабирование с использование кластеров независимых серверов.

Традиционные СУБД хранят данные в виде записей, которые содержать все атрибуты (колонки). При чтении с диска поднимается вся запись, даже если запрашивается только один атрибут. Подобных накладных расходов можно избежать при хранении атрибутов отдельно - атрибутно-ориентированное (column-oriented) хранение. Их-за одинаковой природы данных они очень хорошо сжимаются, следовательно занимают меньше места на диске и требуют меньшее количество операций ввода-вывода, которые очень медленны и "убивают" всю производительность. Несмотря на то, что соединения нескольких таблиц для такого хранения представляется очень сложным, оказывается, что можно использовать алгоритмы поиска по сжатым данным и откладывать материализацию записей как можно дальше, что приводит к лучшей производительности, чем при традиционном хранении. Пример - Vertica, распределенная (GRID), аналитическая БД с вертикальным хранилищем - коммерциализия C-store.

В 2007, 2008 годах прошли встречи преставителей нескольких наук (в основном тех, в которых наблюдается очень быстрый рост потока данных) и разработчиков, на которых принято решение о создания новой SciDB (confluence.slac.stanford.edu/display/XLDB/SciDB) для XLDB. Были выработаны основные требования к будущей базе данных для Большой Науки:

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

Почему выбрана СУБД PostgreSQL?

Кроме того, наша группа на протяжении почти 10 лет принимает активное участие в разработке PostgreSQL и использует его в разных проектах. В частности, мы занимаемся разработкой и поддержкой инфраструктуры расширяемости PostgreSQL (GiST, GIN), которая позволяет создавать пользовательские типы данных и запросы, нами разработан полнотекстовый поиск в PostgreSQL и некоторые другие расширения для эффективной работы с множествами.

Майк Стоунбрейкер в своем блоге про базы данных для Большой науки (www.databasecolumn.com/2007/11/databases-for-big-science.html) привел причины, по которым попытка использования PostgreSQL в начале 90-х годов (проект Sequoia 2000) для геофизических данных провалилась, из чего он сделал далеко идущий вывод, что никакие существующие СУБД (даже PostgreSQL) не могут предложить ничего для Большой науки, и призвал сообщество написать новую СУБД (SciDB) с нуля. Следует отметить, что с тех пор многое изменилось в PostgreSQL и, кстати, усилиями нашей группы были сильно улучшена инфраструктура расширяемости, введена поддержка массивов, иерархических данных. Кроме того, был разработан алгоритм индексации Q3C (q3c.sourceforge.net) очень больших данных со сферическими атрибутами (астрономические координаты, географические координаты), который активно используется в БД с миллиардами объектов.

Таким образом, не отрицая необходимость разработки новой БД для Большой науки, на что потребуется немалое количество лет, мы придерживаемся точки зрения, что необходимо проанализировать современный PostgreSQL для выявления возможных препятствий (bottleneck) в алгоритмах и структурах, изучить опыт сторонних компаний, которые добавили атрибутно-ориентированное хранилище (Yahoo Everest), параллельное исполнение запросов (Greenplum, AsterData). Мы планируем продолжать наши работы по системе расширяемости PostgreSQL, на основе которой будут реализованы новые расширения, тестирование и апробация которых предполагается на сайте Астронет, на котором есть возможность тестирования как на очень больших базах астрономических данных, так и на коллекции полнотекстовых документов. Результаты работ будут доложены на ежегодных конференциях разработчиков PostgreSQL и после дополнительного тестирования часть из них войдет в будущие версии PostgreSQL, тем самым они станут доступными большому количеству пользователей. Учитывая такие факторы, как широкое использование PostgreSQL в науке, его доступность, богатый набор возможностей, а также совместимость с коммерческими вариантами (для которых существует большое число научных приложений, т.е. должна обеспечиваться преемственность и возможность миграции), мы верим в его применимость как универсального хранилища для научных баз данных. В частности, мы планируем уже в рамках этого проекта начать работы по созданию сверхбольшого хранилища для космического проекта астрономического обзора неба совместно с РКК Энергия.


Comments and questions to Evgeny Rodichev, er@sai.msu.su
Last updated 19.04.2009.
Back to my home page