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

Ограничения реляционной модели

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

Другим ограничением систем, основанных на реляционной модели, является отсутствие средств описания семантики системы. Иными словами, данные, которыми управляет СУБД, не «говорят сами за себя». К ним требуется дополнительная документация и описания.

NoSQL СУБД

Для некоторых систем от реляционной модели вообще выгоднее отказаться в пользу набирающих популярность Nosql СУБД.
В NoSQL базах нет регламентированной структуры или присутствует слабая типизация. В отдельную запись можно добавить произвольное поле без предварительного изменения структуры таблицы. Таким образом, для изменения структуры данных нужно просто внести изменения в код приложения. Это с одной стороны обеспечивает высокую гибкость, с другой возлагает дополнительные расходы на код и не позволяет использовать со стороны СУБД такие ограничения как not null, unicque, check сonstraint.

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

Слабые ACID свойства

ACID свойства – это правила по которым выполняются транзакции. К ним относятся:

• Атомарность (Atomicity);
• Согласованность (Consistency);
• Изолированность (Isolation);
• Надежность (Durability).

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

Самоуправление СУБД

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

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

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

Поддержка новых семантических форматов

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