Что такое очень большие базы данных ? Следует различать базы данных как хранилища метаданных, которые содержат очень большое количество записей с активным доступом и базы данных, ориентированных на архивное хранение очень больших бинарных объектов.

На сегодня официально анонсирована самая большая в мире база данных с активным доступом - Yahoo Everest, которая на май 2008 года имела хранилище размером более 2 Pb, несколько триллионов записей, с ежедневным поступлением около 24 млрд событий и более 1/2 миллиарда пользователей в месяц. Ожидается в 2009 году рост базы данных до 5Pb. Интересно отметить, что Yahoo Everest - это свободная СУБД PostgreSQL с распределенным вертикально-ориентированным хранилищем и поддержкой кластеризации.

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

• Большой Адронный Коллайдер (LHC), который ежегодно будет производить около 15 Pb данных, распределенное хранилище будет состоять из примерно 200 центров данных по всему миру.
• Большой телескоп для обзора неба (LSST), с диаметром зеркала 8.4 метра и приемником в виде мозаики CCD-матриц общим размером 3.2 Гп (гига-пикселей). Ожидается наполнение БД в 49 миллиардов объектов (256 атрибутов), 2.8 триллиона источников (56 атрибутов). К 2025 году ожидается накопить 14 Pb данных!

Гигантские объемы данных полностью исключили традиционный раннее способ работы - загрузка данных на сервер для обработки. Причем, основная проблема состоит даже не в стоимости хранилища, а в стоимости каналов связи.

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

Совершенно очевидно, что старый подход, когда необходимые данные просто скачивались тем или иным способом на компьютер для обработки, совершенно непригоден. Требуется новая технология, которая позволяет передавать программы в центры данных, там их исполнять и предоставлять пользователю только результаты. Новый подход требует соглашений о том, как находить ресурсы (центры данных), каким образом и в каком виде эти данные надо передавать, какие программные интерфейсы необходимы для написания программ и какова политика использования ресурсов.

Для организации процесса обработки данных (pipeline), который может быть очень трудоемким и для поисковых задач требуется доступ к GRID центрам, что также требует определенных соглашений (см. проект GRIST).

Возникла парадоксальная ситуация, когда есть много данных, которыми практически трудно воспользоваться из-за разнобоя в описаниях, единицах измерений, протоколов хранения и передачи данных и т.д. Такая картина наблюдается как в науках (например, физика высоких энергий, биология, метеорология), так и в бизнесе, развитие которого опирается на бизнес-процессы, реализуемые, в частности, с помощью информационных технологий.

Отметим, что требуется обеcпечить прежде всего не интерактивную работу с данными, а программный доступ к ним, чтобы можно было автоматизировать рутинные работы обработки наблюдений, поиска данных.

Кроме того, помимо необходимости разработки новых программных компонентов, существует большое количество старых программ и систем, которые обслуживают существующие информационные ресурсы и требуется найти способ их интеграции. Очевидно, что это возможно только при абстрагировании от конкретного устройства компонент, протоколов связи между ними и формата данных, которыми они обмениваются. В противном случае, подключение новых компонентов к системе требует больших финансовых и временных затрат (большинство существующих распределенных информационных систем связаны именно таким способом). Такая архитектура получила название сервисно-ориентированной архитектуры (SOA) и развивается по спецификациям W3C (www.w3.org/2002/ws/) и OASIS (www.oasis-open.org).

Использование SOA в науках, развитие которых связано с ростом данных, идет по одному сценарию - общие спецификации W3C дополняются специфическими рекомендациями, что позволяет использовать общепринятые технологии. Так, в астрономии, еще в конце 90-х крупные центры астрономических данных (CDS (Франция), CaDC (Канада), STScI (США), и т.д.) предложили начать разработку стандартов для доступа к астрономическим данным. Основная цель - оптимизировать доступ, обработку и анализ данных с целью получения максимальной научной отдачи. В 2002-м году был образован Международный Альянс Виртуальной Обсерватории (IVOA, International Virtual Observatory Alliance), объединивший национальные и международные ВО проекты. Главная миссия IVOA - разработка, утверждение и распространение стандартов для всех типов астрономических данных и средств их обработки и анализа. Основным результатом для общественности является появление десятков архивов, предоставляющих доступ к данным через стандартные интерфейсы, например центр астрономических данных в Страсбурге (cdsweb.u-strasbg.fr), Национальная Американская Виртуальная Обсерватория (www.us-vo.org/projects/dataserv.cfm). В России недавно появился пилотный проект Российской Виртуальной Обсерватории (vo.astronet.ru), нацеленный на предоставление доступа к данным для России и стран СНГ, а также на исследование технологий сервисно-ориентированной архитектуры.

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

В рамках Виртуальной Обсерватории организована сеть реестров ресурсов, которая используется для поиска данных как исследователем, так и программными агентами. Доля человеческого участия постепенно будет уменьшаться с развитием технологий семантического Веба (www.w3.org/2002/ws). Уже сейчас идет работа по созданию онтологии астрономических объектов, обозначений астрономических величин (www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/IvoaSemantics).

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

Какие хранилища используются для хранения научных данных? В чем специфика научных БД?

Специфика научных баз данных:

• Сверхбольшие БД - сотни петабайт в ближайшие 10 лет
• Научные данные часто хранятся в двух видах - метаданные в БД и данные где-то в файловой системе, требуется поддерживать их непротиворечивость. Современные БД не приспособлены для эффективной работы с терабайтами бинарных данных
• Научные данные, особенно "сырые" данные, практически не меняются
• OLAP запросы преобладают над OLTP
• Очень много разных требований в разных науках - трехмерные объекты, временные ряды, треки элементарных частиц и т.д
• Версионность данных - важно для науки, иначе нет воспроизводимости результатов.
• Распределенность - данные хранятся в разных научных центрах для локализации трафика, по физическим причинам, резервирование данных, масштабирование нагрузок

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

• Добавляются новые расширения на основе встроенных средств расширяемости. Например, PostgreSQL имеет GiST, GIN, с помощью которых сильно улучшена работа со множествами, реализован полнотекстовый поиск.
• Создаются специализированные СУБД, ориентированные на специфические типы данных, специфические условия. Например, в связи с появлением дешевых сенсоров возникла необходимость в работе с потоками данных, когда сами данные не важны, а интересны только агрегаты, такие как средняя температура, и т.д. Традиционные СУБД имеют большие накладные нагрузки (транзакционность, хранение на диске,..). Пример потоковых i данных - StreamBase. Другой пример - встроенные (embedded) СУБД (sqlite, tinyDB) используются в специализированных приборах. Появились XML базы данных для хранения слабо-структурированных данных (en.wikipedia.org/wiki/XML_database).
• СУБД используют в кластерах для масштабирования. Современная тенденция - это использование полностью независимых дешевых компьютеров. Промежуточный слой (middleware) между приложением и кластером отвечает за маршрутизацию запросов и результатов. Такая схема позволяет легко масштабировать и следить за сохранностью данных. Пример Sequoia (http://community.continuent.com/community/sequoia), uni/cluster для PostgreSQL, MySQL (http://www.continuent.com/). Другой подход - это использование технологии Cloud Computing для масштабирование как по хранилищу, так и по числу процессоров, например PostgreSQL Plus компании EnterpriseDB.
• Специализированные сервера с использование сопроцессоров (FPGA), например XtreemeData http://www.xtremedatainc.com/, модифицированный PostgreSQL, интегрированный в FPGA, для аналитических систем (OLAP)
• Модифицируется ядро СУБД для поддержки параллелизма (AsterData, GreenPlum), что позволяет один запрос выполнять на нескольких компьютерах. Приложение - аналитические базы данных (OLAP).
• СУБД упрощаются до поддержки типа данных (ключ,значение), результаты передаются приложению, где и происходит окончательные вычисления. Язык SQL здесь не нужен. Примеры - Google BigTable (http://labs.google.com/papers/bigtable.html), Amazon SimpleDB (http://www.amazon.com/SimpleDB-AWS-Service-Pricing/b?ie=UTF8&node=342335011), HyperTable (http://hypertable.org/). Намеренная простота таких БД компенсируется великолепной масштабированностью как по дисковому хранилищу, так и по процессорам.

Тем не менее, как считает видный участник DB-сообщества Майкл Стоунбрейкер, все это являются полумерами и требуется кардинальные изменения в технологии СУБД, а именно - изменение принципа хранения данных. Он считает, что эра обычных больших СУБД общего назначения прошла (http://www.databasecolumn.com/2007/09/one-size-fits-all.html) и требуется совершенно новые подходы для создания современной БД, которая с самого начала будет ориентирована на распределенность, параллельное исполнение запросов, компрессию, ориентацию на хранение по атрибутам, высокую доступность, линейное масштабирование с использование кластеров независимых серверов.

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

Более того, научное сообщество и разработчики СУБД решили взаимодействовать для создания новой SciDB (confluence.slac.stanford.edu/display/XLDB/SciDB) для XLDB. Несколько совещаний:

• 1st Workshop on Extremely Large Databases, SLAC, Oct. 2007
• SciDB Meeting, Asilomar, Apr. 2008

Были выработаны основные требования к будущей базе данных для Большой Науки:

• открытая модель развития гарантирует независимость от вендора и защиту инвестиций, а также способствует привлечению разработчиков.
• отказ от строгого соблюдения ACID, хранилище оптимизированное в основном на чтение, загрузка данных только большими порциями (bulk load), многомерные массивы как основная структура данных
• масштабируемость на сотни петабайт, при этом SciDB должна работать как на ноутбуке, так и на кластере в тысячи серверов. Минимизация административных затрат на поддержание работоспособности кластера.
• интерфейсы к научным приложениям, таким как R, MATLAB, IDL, к языкам программирования (C++, Python)
• Поддержка версионности данных, отслеживание источников данных, поддержка данных с ошибками

Отметим, что эти требования в основном относятся к "сырым" данным, в то время как для очень многих задач по прежнему важны принципы ACID, на которых базируются классические СУБД. Кроме того, на разработку новой СУБД с нуля, тестирование и отладку уйдет как минимум 3-5 лет, поэтому с практической точки зрения разработчикам СУБД стоит уделить внимание механизмам расширяемости и масштабируемости.

Концепция развития информационной системы Астронет, предлагаемая в данном проекте, отвечает самым современным тенденциям развития научных информационных систем в сторону увеличения степени интеграции данных, максимального использования новейших алгоритмов поиска информации многих различных типов, и постепенного сдвига в сторону сервис-ориентированных архитектур.