В сообществе баз данных не слишком принято индивидуально анализировать и прогнозировать направления исследований. На это отваживаются лишь немногие (одним из исключений является Джим Грей [1]). Обычно же подобная работа выполняется на сравнительно регулярных собраниях наиболее авторитетных представителей исследовательского сообщества, которые обмениваются мнениями и, по мере возможности, вырабатывают общую точку зрения. В результате таких собраний формулируется отчет, в котором фиксируется представление сообщества о путях развития исследований. Хорошо известны отчет собрания в Лагуна-Бич (1989 г.) [2] и Асиломарский отчет (1996 г.) [3]. Общий обзор этих материалов можно найти в моей статье "Направления исследований в области баз данных: десять лет спустя" [4]. Последнее подобное собрание состоялось в 2003 г. в г. Лоуэлл, штат Массачусетс. Лоуэллский отчет до сих пор официально не опубликован, хотя обсуждался на панельной дискуссии конференции SIGMOD в 2003 г. [5]. Однако предварительная версия отчета доступна в Internet [6], и я начну свою статью с его краткого обсуждения. Во второй части я приведу некоторые собственные рассуждения по поводу более практичных текущих потребностей, не претендуя на обобщения.

1. Лоуэллские прогнозы

В дискуссиях в Лоуэлл участвовали 29 ведущих исследователей в области данных, среди которых присутствовали такие известные ученые как Серж Абитебуль, Ракеш Агравал, Филипп Бернштейн, Стефано Чери, Дэвид Девитт, Гектор Гарсиа-Молина, Джим Грей, Лаура Хаас, Янис Ионнидис, Дэвид Мейер, Ханс Шек, Тимос Селлис, Ави Зильбершац, Майкл Стоунбрейкер, Рик Снодграсс, Джеффри Ульман, Герхард Вейкум, Дженифер Видом, Стэн Здоник и т.д. В течение двух дней участники отметили много новых приложений, технологических тенденций и точек соприкосновения с другими областями, влияющими на развитие области баз данных. Для решения имеющихся проблем требуется новая инфраструктура управления информацией, и в первой части отчета обозреваются компоненты этой инфраструктуры. Во второй части обсуждаются темы, вызвавшие разногласия, и отмечаются ближайшие шаги по направлению к созданию новой инфраструктуры.

По мере потребности, я буду комментировать положения отчета, которые (в моем изложении) выделяются курсивом.

1.1 Инфраструктура следующего поколения

• Интеграция текста, данных, кода и потоков

  В области СУБД основное внимание всегда уделялось организации, хранению, анализу и выборке структурированных данных. Развитие Web продемонстрировало важность более сложных типов данных: текстов, изображений, темпоральных, аудио- и видеоданных. Проблема состоит в том, что при добавлении соответствующих возможностей к существующим СУБД трудно сделать эти добавления "аккуратно". Имеется тенденция к тому, чтобы добиваться наиболее важных новых возможностей с применением минимума усилий. В результате расширения становятся "жителями второго сорта" СУБД в отличие от таких "жителей первого сорта" как целые числа и строки символов. Это тормозит и будет продолжать тормозить использование технологии баз данных в новых приложениях.

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

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

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

• Интеграция информации

  Типичным подходом к интеграции информации в масштабах предприятия является построение хранилищ (DataWarehouse) витрин (data mart) данных на основе извлечения операционных данных, их трансформации к единой схеме и загрузки данных в хранилище (процедура ETL - extraction, transfotamation, loading). Этот подход пригоден для использования на предприятии с несколькими десятками операционных баз данных, находящихся под единым контролем. В Internet парадигма ETL не приемлема. Теперь требуется производить интеграцию информации между несколькими предприятиями. Как правило, организации не позволят в массовом порядке извлекать данные из своих операционных баз данных, к ним можно будет адресовать лишь одиночные запросы.

  В результате потребуется интеграция, возможно, миллионов информационных источников "на лету". В связи с этим существует множество нерешенных проблем: семантическая неоднородность; неполнота и неточность данных; ограниченность доступа к конфиденциальным данным и т.д.

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

• Сенсорные данные и сенсорные сети

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

  Идея использования сенсорной сети как распределенного компьютера с очень большим числом дешевых узлов приходит в голову не только специалистам в области баз данных. Но мне кажется, что эта здравая идея несколько противоречит требованию дешевизны сенсорного устройства. Сегодняшние сенсорные устройства обычно обладают не более 16 Кб памяти, и разработчики мечтают о времени, когда на всех таких устройствах будет доступно хотя бы 64 Кб. Я не уверен, что (а) на таких ресурсах можно сделать какое-либо достаточно интеллектуальное программное средство и что (б) когда-нибудь станет выгодно оснащать более мощными ресурсами одноразовые устройства (у сенсорных устройств не меняют батарейки).

  Интересно, что примерно за год до встречи в Лоэлле в университете Беркли начался проект TinyDB, одним из лидеров которого является Джозеф Хеллерштейн, принимавшей участие и в Лоэллском отчете. Результаты проекта [7] очень интересны: используется декларативный SQL-подобный язык запросов, применяются оригинальные методы оптимизации запросов, учитывающие энергопотребление и т.д. Но все же TinyDB не делает сенсорную сеть подобием машины баз данных - функции сенсорных устройств весьма тривиальны: передать в родительский узел результаты своих датчиков или транслировать запрос узлам-потомкам.

• Мультимедийные запросы

  Очевидно, что объем мультимедийных данных (изображения, аудио, видео и т.д.) значительно возрастает. Проблемой сообщества баз данных является создание простых способов анализа, обобщения, поиска и обозрения электронных подборок мультимедийной информации, относящейся к некоторому человеку.

  Понятно, что это тоже является одним из аспектов проблемы интеграции данных.

• Использование неточных данных

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

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

• Персонализация

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

• Data Mining

  Исторически направление data mining направлено на обеспечение эффективных способов обнаружения моделей существующих наборов данных. Эти модели должны раскрывать некоторые полезные аспекты данных, скрывая детали, не являющиеся полезными для приложения. В разных исследовательских сообществах разработаны алгоритмы классификации, кластеризации, выявления ассоциативных правил и обобщения.

  Проблемой data mining в области баз данных является разработка алгоритмов и структур данных для просеивания базы данных в поисках "жемчужин". Такая обработка должна вестись в фоновом режиме с потреблением остаточных системных ресурсов. Другой важной проблемой является интеграция data mining с подсистемой поддержки запросов, оптимизацией и другими средствами базы данных, такими как триггеры.

• Самоадаптация

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

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

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

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

  Это очень важное направление, в котором наиболее интересные результаты получены в исследовательских лабораториях компаний Microsoft (см., например, [7]) и IBM [8]. Мне кажется, что такого рода исследования более естественно вести в лабораториях больших компаний, в которых имеется неограниченный доступ к исходному коду развитых СУБД.

• Конфиденциальность

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

• Системы, заслуживающие доверия

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

• Новые пользовательские интерфейсы

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

  Тридцать лет исследований в области языков запросов сводятся к тому, что "мы двигаемся от SQL к XQuery". В лучшем случае мы переходим от одного декларативного языка к другому, обладающему примерно тем же уровнем выразительности. Конечные пользователи не знают SQL, это язык профессиональных программистов. В родственных сообществах имеются идеи, которые могли бы повлиять на исследования в области интерфейсов к базам данных. Например, в информационно-поисковых системах в течение многих лет используются запросы по ключевым словам, в ряде областей растет популярность браузеров.

  Возможно, наиболее интересные возможности связаны с исследованиями, ассоциируемыми с термином "semantic Web". Хотя смысл этого термина остается не вполне ясным, большая часть современных исследований сосредоточена на "онтологиях". Онтология характеризует предметную область путем определения концепций и связей между ними, обычно с использованием формального языка. Работа над онтологиями может позволить пользователям баз данных задавать запросы в собственной терминологии с использованием естественного языка. Нужно учитывать эти возможности при разработке будущих СУБД.

• Столетнее хранение

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

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

• Оптимизация запросов

  Многие участники собрания расценивали оптимизацию запросов как важный элемент решения упомянутых выше проблем. Общий принцип состоит в том, что при наличии очень больших объемов данных мы склонны манипулировать этими данными стандартным образом. Эта стандартность позволяет успешно использовать в мире данных языки очень высокого уровня SQL и XQuery, но больше они почти нигде не применяются. Для языков очень высокого уровня требуются надлежащие оптимизаторы. Нужно продолжать работать в областях оптимизации средств интеграции информации, языков запросов полуструктурированных данных, таких как XQuery, процессоров потоков, сенсорных сетей и т.д.

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

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

1.2 Ближайшие шаги и спорные темы

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

Исследования в области интеграции информации следовало бы оснастить испытательным стендом и набором интеграционных задач. Это позволило бы обеспечить доступ к испытательной платформе для проверки любой новой интеграционной идеи. Испытательный стенд позволил бы сравнивать решения контролируемым образом, включая возможность получения права похвастаться, если одно из решений является в настоящее время наилучшим для некоторой интеграционной задачи. Это помогло бы поддерживать интерес к этой области исследований. В сообществе информационно-поисковых систем аналогичным целям служит TREC (Text REtrieval Conference).

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

К настоящему времени эта работа выполнена. Испытательный стенд создан на базе University of Florida, USA (http://www.cise.ufl.edu/project/thalia.html). THALIA (Test Harness for the Assessment of Legacy information Integration Approaches) является публично доступным испытательным стендом и набором эталонных тестов для тестирования и сравнения технологий интеграции. Web-сайт обеспечивает исследователей и практиков набором из 40 скачиваемых источников данных, представляющих каталоги курсов факультетов Computer Science со всего мира. Данные испытательного стенда синтаксически и семантически неоднородны, и их интеграция представляет серьезную техническую проблему для исследовательского сообщества. Кроме того, на сайте имеется набор из 14 эталонных запросов, а также средство количественной оценки производительности системы интеграции. В [7] представлен первый публичный отчет о проекте.

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

Также обсуждался уровень, на котором следует производить интеграцию информации. Хотя многие участники полагали, что наилучшим местом для этого является СУБД, другие считали, что более естественным и распространенным является уровень приложения (например, на основе Web-сервисов). Обсуждалась возможность использования Web-сервисов для решения проблем семантической интероперабельности. Одни участники выражали надежду на то, что для таких сервисов появятся стандарты де-факто, а другие возражали, что в мире электронных компонентов (Rosetta Net) стандартизация набора сервисов ведется на протяжении многих лет с очень ограниченным успехом.

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

2. Российские потребности и возможности

Начнем с того очевидного факта, что российская часть мирового сообщества баз данных (а) очень малочисленна и (б) слабо интегрирована с остальным миром. Думаю, что причины очевидны и на них не стоит останавливаться. В России существуют несколько сравнительно активно действующих исследовательских групп. Я не буду их перечислять или как-то оценивать результаты, потому что могу что-нибудь опустить или оценить недостаточно объективно. Замечу только, что одна из таких групп, в которой участвую я сам, функционирует в Институте системного программирования РАН. Приводимые ниже субъективные соображения отражают позицию этой группы.

Группа MODIS уже шесть лет в основном занимается исследованиями и разработками, относящимися к области управления XML-данными. Мы начали с проекта системы интеграции источников реляционных и XML-данных на основе модели данных XQuery [10]. В этой системе глобальная схема интегрированных данных представлялась на языках DTD или XML Schema, сами интегрированные данные представлялись в формате XML и могли запрашиваться на языке XQuery. Последние два года группа выполняет проект Sedna, "прирожденной" XML-ориентированной СУБД, опирающейся на собственную подсистему хранения XML-данных и язык запросов XQuery [11]. В этом проекте "с нуля" создается полнофункциональная XML-СУБД, но он интересен еще и тем, что является одним из немногих (если не единственным) инициированным в России проектом СУБД с открытыми исходными текстами (об этом мы еще поговорим позже).

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

Еще раз подчеркну, что в области баз данных (как и во многих других областях Computer Science) единственным достоверным критерием истинности исследовательских результатов является успешное использование этих результатов при разработке эффективно функционирующей программной системы. В данной области системы (системы интеграции, СУБД и т.д.), как правило, бывают большими и сложными. Разработка таких систем занимает годы. На Западе (в особенности в США) на основе результатов перспективных проектов часто образуются "начинающие" (startup) компании, финансируемые различными инновационными организациями, которые доводят результаты проекта до коммерческого продукта и выходят с ним на рынок. Компании вступают в конкурентную борьбу на рынке и либо завоевывают себе право на существование (что случается крайне редко), либо приобретаются более крупными компаниями (это происходит тоже нечасто), либо (что происходит гораздо чаще) погибают.

Но даже этот не слишком надежный путь недоступен для российских исследователей. Снова причины очевидны и я не буду их разъяснять. Как нам кажется, единственным выходом в обозримом будущем является участие в движении open source. Сегодня российские разработчики активно участвуют во всех известных проектах СУБД с открытыми исходными текстами: MySQL, PostgreSQL, Interbase, Firebird. Это очень важно, поскольку проекты уже являются достаточно зрелыми, и молодые исследователи получают возможность использовать на практике имеющиеся у них знания, оставаясь на родине и одновременно сближаясь с широким международным сообществом. Мне кажется очень важным и упоминавшийся выше проект Sedna, основанный в России, вокруг которого постепенно складывается сообщество.

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

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

Например, одним из наиболее известных решений, пригодных для использования на кластерной архитектуре, является Real Application Cluster (RAC) компании Oracle. Но для эффективной работы этой системы требуется мощная дисковая подсистема, быстрый доступ к которой должен обеспечиваться для всех узлов кластера. Затраты на приобретение требуемой дисковой подсистемы практически удваивают стоимость кластера, а требуемая дополнительная кабельная система существенно усложняет конструкцию. К тому же при наличии общей дисковой системы возможности масштабирования СУБД при наращивании числа узлов кластера ограничены.

У компании IBM имеется кластерное решение DB2 Database Partitioning Feature (DPF), ранее обеспечивавшееся продуктом DB2 Parallel Edition. По своей организации DB2 c DPF очень хорошо соответствует кластерной архитектуре: для работы системы не требуется общая основная или дисковая память, при оптимизации запросов минимизируется передача данных между узлами, система практически неограниченно масштабируется. Но проблема состоит в том, что компания решительно рекомендует использовать систему на кластерах своего собственного производства, хотя и допускается использование ОС Linux. Имеется (пока что не до конца проверенное) подозрение, что систему очень нелегко установить на произвольный кластер и тем более трудно добиться желаемой производительности.

В России имеется исследовательская группа, которая специализировалась в области параллельных СУБД [13], но результаты выполненного проекта далеки от получения работоспособной системы.

Единственным выходом из положения является разработка параллельной СУБД с открытыми исходными текстами. К настоящему времени имеется кластерный вариант СУБД MySQL [14], но в системе не поддерживается параллельное выполнение запросов. Проект, в котором исследуются возможности распараллеливания запросов в кластерном варианте MySQL, ведется в Копенгагенском университете в Дании [15], однако практических результатов пока не видно. По моему мнению, российским специалистам следует присоединиться к этой работе или начать свой собственный проект.