Тенденции развития универсальных коммерческих СУБД

Марк Ривкин

Назад Содержание

8. Умные механизмы сжатия и дедублирования

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

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

Традиционные алгоритмы сжатия позволяют сжать данные в 2-3 раза. Некоторые специфические виды сжатия позволяют увеличить эту степень сжатия на порядок, но при этом сильно замедляется выполнение операций DML с этими данными. Например, известно, что сжатие поколоночно хранимых и заранее отсортированных данных обеспечит очень высокий уровень сжатия (иногда в десятки раз). Однако попытки изменения таких таблиц в Oracle 11.2 показали, что время обновления данных значительно увеличивается. Но для хранилищ данных и исторических данных такой подход вполне приемлем.

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

9. Совершенствование методов защиты данных

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

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

Еще одно перспективное направление развития – изоляция DBA от данных. Сегодня администратор может видеть и изменять все данные в БД. Новые средства защиты (такие как Oracle Data Vault option) позволят DBA выполнять все операции по администрированию БД, не позволяя ему видеть и менять данные. Также администратору можно будет ограничить набор разрешенных к выполнению операций. Ограничение может быть привязано к имени DBA, времени, точке входа в систему.

10. In-memory СУБД реального времени как кэш для коммерческих СУБД

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

Сейчас наметилась тенденция использования таких быстрых in memory СУБД в качестве высокоскоростных кэшей к коммерческим дисковым СУБД. Oracle сегодня использует в таком качестве СУБД Times Ten, IBM приобрела СУБД SolidDB и начала ее интеграцию с DB2. Специальное ПО позволяет поднять или подкачивать данные в такой скоростной кэш и синхронизировать изменения в дисковой СУБД и в кэше. Приложения, требующие высокого быстродействия и малого гарантированного времени отклика, практически работают с таким кэшем в памяти, который уже сам синхронизируется с дисковой СУБД. Таких кэшей над дисковой СУБД можно подвесить несколько, давая возможность многим приложениям получать время отклика (особенно, при чтении и коротких обновлениях) в несколько микросекунд. При этом размеры основной БД могут быть очень большими (десятки и сотни терабайт), но кэшируется по определенной политике только часть данных. Важно, что для работы с использованием такого кэша не нужно специальное программирование, можно использовать стандартные протоколы (ODBC, JDBC), привычный язык дисковой СУБД.

11. Облачные вычисления (Cloud computing)

Сегодня бурно начинают развиваться так называемые облачные вычисления (Cloud computing). Эта технология очень привлекательна для пользователей, т.к. они легко и недорого могут запросить через Интернет и получить во временное пользование некоторый сервис для хранения и обработки данных. Например, можно заказать компьютер с заданным объемом памяти, дисков, количеством процессоров, с предустановленными ОС и СУБД или другими пакетами ПО и работать с ним из своего офиса, хотя физически и оборудование, и ПО располагаются и обслуживаются в удаленном чужом ЦОД. Можно заказать нужный дисковый ресурс и хранить на нем свои файлы.

Примерами Cloud Computing являются сервисы хранения (Amazon S3), вычислительные сервисы (Google App Engine, Amazon EC2) и сервисы данных (Amazon SimpleDB, Microsoft SQL Server Data Services, Google’s Datastore).

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

12. Машины баз данных

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

Обычно при росте объема БД узким местом становятся каналы передачи данных между сервером БД и устройствами хранения. Возможность увеличить количество и пропускную способность таких каналов, а также снизить объем передаваемых данных за счет выполнения части операций по просмотру и выборке данных на уровне ячеек хранения, позволяет снять проблему каналов передачи. Такая связка оборудования и специального ПО, называемая машина баз данных, давно описана в литературе [11, 12]. Примеры – Netezza, Datallegro, Teradata.

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

Oracle–HP Database Machine представляет из себя единый преднастроенный компьютер (с ячейками Exadata и кластером БД). Очень важна для таких архитектур сбалансированность компонент, т.е. размера памяти, дисков, числа процессоров, скорости каналов ввода/вывода и т.д.

В том же направлении сейчас движется Microsoft, которая купила DATAllegro и интегрирует ее с MS SQL Server. Машина баз данных не только ускоряет обработку, но и упрощает разработку хранилищ данных, так как многим вопросам настройки СУБД, требовавшим создания индексов, материализованных представлений, секционирования таблиц и индексов, кластеризации данных и настройки областей памяти, ввода/вывода и т.д., теперь можно уделять меньше внимания. За счет очень высокой скорости и распараллеливания выполнения самых тяжелых операций СУБД – full scan, проекция и join, даже не очень хорошо спроектированная БД работает очень быстро. Так что, очевидно, вскоре все коммерческие СУБД, работающие в области хранилищ данных, станут работать в архитектуре машин баз данных.

IV. Заключение

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

V. Литература

1. The Claremont Report on Database Research, 2008. Имеется перевод на русский язык С. Кузнецова: Клермонтский отчет об исследованиях в области баз данных
2. The Lowell Database Research Self-Assessment. CoRR cs.DB/0310006, 2003. Also in CACM 48(5): 111-118, 2005. Имеется пересказ на русском языке в обзоре C. Кузнецова: Крупные проблемы и текущие задачи исследований в области баз данных.
3. The Asilomar Report on Database Research. SIGMOD Record 27(4): 74-80, 1998. Имеется перевод на русский язык C. Кузнецова: Асиломарский отчет об исследованиях в области баз данных.
4. “Future Directions in DBMS Research – The Laguna Beach Participants”. SIGMOD Record 18(1): 17-26, 1989. Имеется пересказ на русском языке С. Кузнецова: Будущие направления исследований в области баз данных: десять лет спустя
5. A Conversation with Michael Stonebraker and Margo Seltzer, ACM Queue, Volume 5, Number 4, May/June 2007. Имеется пересказ на русском языке С. Кузнецова: Беседа Марго Зельцер с Майклом Стоунбрейкером
6. M. Stonebraker and U. Cetintemel. “One Size Fits All: An Idea Whose Time has Come and Gone. In Proceedings of the International Conference on Data Engineering (ICDE), 2005. Имеется перевод на русский язык C. Кузнецова: «Один размер пригоден для всех»: идея, время которой пришло и ушло.
7. Michael Stonebraker, Chuck Bear, Uğur Çetintemel, Mitch Cherniack, Tingjian Ge, Nabil Hachem, Stavros Harizopoulos, John Lifter, Jennie Rogers, and Stan Zdonik. One Size Fits All? – Part 2: Benchmarking Results, 3rd Biennial Conference on Innovative Data Systems Research (CIDR) January 7-10, 2007, Asilomar, California, USA. Имеется перевод на русский язык C. Кузнецова: Пригоден ли один размер для всех? Часть 2: результаты тестовых испытаний.
8. The End of an Architectural Era (It's Time for a Complete Rewrite). Proceedings of VLDB, 2007, Vienna, Austria. Имеется перевод на русский язык C. Кузнецова: Конец архитектурной эпохи, или Наступило время полностью переписывать системы управления данными.
9. С Кузнецов ” Универсальность и специализация: время разбивать камни?”, 2007, http://www.citforum.ru
10. М Ривкин “Платформа для коммерческих сред Grid” //Открытые системы, 2003, N 12
11. А. Александров. “Машины хранения данных” //Открытые системы, 2006, N 2
12. Э. Озкарахан “Машины баз данных”, М., Мир, 1989

Назад Содержание