Перспективы развития современных СУБД

Alan
Сообщения: 14
Зарегистрирован: Вт апр 08, 2008 9:26 am

Перспективы развития современных СУБД

Сообщение Alan » Вт апр 08, 2008 9:54 am

Перспективы развития современных СУБД
Никитин М.В.
(по материалам citforum.ru, С. Кузнецов Первые шаги к управлению всемирной информацией, За пределами реляционных баз данных)

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

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

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

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

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

Хранилища данных.Данная прикладная область характеризуется наличием огромных таблиц (десятки и даже сотни терабайт), запросов, обращающихся только к нескольким из многочисленных столбцов таблицы и потребности в просмотре таблицы в различных порядках сортировки. Хранилища данных в основном используется для чтения: она обновляется массовым образом путем периодического добавления в коллекцию новых транзакций, но над ней часто выполняются операции выборки, когда аналитик отбирает данные, извлекая из базы данных полезные «лакомые кусочки».

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

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

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

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

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

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

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

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

Что будет означать модульность для проектировщика систем баз данных?

Во-первых, это будет означать возможность гибко подстраиваться под сложность задачи. Для несложных задач бывает достаточно простых индексируемых таблиц с возможностью выборки и модификации. В более сложном случае возможно потребуется поддержка транзакций. При необходимости, можно добавить возможности по реагрегации и объединения данных. И так далее. Зельцер: «Таким образом, вы преобразуете SQL из монолитного языка в семейство языков с последовательно увеличивающейся мощностью, причем каждый из этих языков представляется как некоторый компонент, удовлетворяющий потребности достаточно большого числа прикладных областей. Для любого конкретного приложения выбираются те компоненты, которые для него требуются. Эта идея компонентной архитектуры может быть расширена для включения других аспектов архитектуры систем баз данных: управления параллелизмом, транзакций, журнализации и обеспечения высокого уровня доступности.»

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

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

И Зельцер, и Селинжер говорят о необходимости более гибкого использования механизмов запросов данных. Если нет необходимости использовать высокоуровневых запросов SQL, XPath, XQuery и т.п. – этого необходимо избегать.

Зельцер: «Например, если данные приложений являются, по сути, не реляционными (например, содержат многозначные атрибуты или большие порции неструктурированных данных), то насильственное их приведение к реляционной форме только для обеспечения доступа на основе SQL приведет к появлению накладных расходов на эти преобразования и вряд ли позволит извлечь выгоду из реляционного хранения данных. Аналогично, если бы данные приложения были по своей сути реляционными, то насильственное приведение их к другому формату (например, XML или объектно-ориентированное представление) привело бы только к новым накладным расходам без получения каких-либо преимуществ.»

Селинжер: «Одна из работ, на которую мы тратим много времени, – это UIMA (unstructured information management architecture, архитектура управления неструктурированной информацией)… По существу, это платформа, к которой можно подключать, например, средства анализа текстов и поиска в онтологиях, где вы можете получить информацию и проаннотировать ее – это имя президента, это название университета, а затем обобщить эту информацию на основе классификаторов, семантики и онтологии и быть в состоянии отвечать на вопросы обо всем этом. Например, производитель автомобилей мог бы спросить: «Что говорят люди, которые звонят с жалобой на проблему с тормозами в таком-то и таком-то автомобиле?», «Как мы с этим справляемся?», «Можем ли мы улучшить качество работы с клиентами на основе этих результатов?»

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

Вопросов пока больше, чем ответов. Радует то, что разработчики начинают постепенно консолидироваться для их решения, проблемы постоянно обсуждаются, ищутся варианты решения. Также необходимо отметить, что все большая роль в поиске решений отдается разработкам Open Source. У столпов мировой индустрии баз данных уже имеются несколько неплохих конкурентов из данной сферы.

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

kak
Сообщения: 359
Зарегистрирован: Вт мар 17, 2009 10:30 am
Откуда: Вологда
Контактная информация:

Re: Перспективы развития современных СУБД

Сообщение kak » Пт дек 11, 2009 9:43 am

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

kak
Сообщения: 359
Зарегистрирован: Вт мар 17, 2009 10:30 am
Откуда: Вологда
Контактная информация:

Re: Перспективы развития современных СУБД

Сообщение kak » Ср янв 12, 2011 10:43 am

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

kak
Сообщения: 359
Зарегистрирован: Вт мар 17, 2009 10:30 am
Откуда: Вологда
Контактная информация:

Re: Перспективы развития современных СУБД

Сообщение kak » Пн фев 21, 2011 6:21 pm

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