Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Обучение от Mail.Ru Group.
Онлайн-университет
для программистов с
гарантией трудоустройства.
Набор открыт!
2007 г.

Конец архитектурной эпохи, или Наступило время полностью переписывать системы управления данными

Майкл Стоунбрейкер, Сэмюэль Мэдден, Дэниэль Абади, Ставрос Харизопулос, Набил Хачем, Пат Хеллэнд

Пересказ: Сергей Кузнецов

Оригинал: Michael Stonebraker, Samuel Madden, Daniel J. Abadi, Stavros Harizopoulos, Nabil Hachem, Pat Helland. The End of an Architectural Era (It's Time for a Complete Rewrite). Proceedings of VLDB, 2007, Vienna, Austria

Аннотация

В статьях [SC05, SBC+07] некоторые авторы данной статьи предсказывали конец парадигмы «безразмерности» («one size fits all») коммерческих реляционных СУБД. В этих статьях показывалось, что производительность основных РСУБД в областях хранилищ данных, обработки потоков данных, обработки текстовых данных и научных баз данных может быть превзойдена специализированными программными средствами на один-два порядка величин.

В предположении, что специализированные программные средства будут со временем доминировать в перечисленных областях, для линий кода существующих реляционных СУБД оставались бы открытыми рынок обработки бизнес-данных (OLTP) и гибридные рынки, на которых одновременно требуется несколько возможностей. В настоящей статье демонстрируется, что специализированные программные средства могут превзойти почти на два порядка производительность существующих РСУБД и на рынке OLTP. Приводятся результаты сравнения производительности на эталонном транзакционном тестовом наборе TPC-C прототипа H-Store, разработанного в MIT, с производительностью популярной РСУБД.

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

Содержание

1. Введение
2. Архитектурные соображения по поводу СУБД, ориентированных на OLTP
2.1 Основная память
2.2 Многопотоковость и управление ресурсами
2.3 Grid-компьютинг и массивная модернизация (Fork-lift Upgrade)
2.4 Высокий уровень доступности
2.5 Никаких ручек управления
3. Предположения о транзакциях, обработке и среде
3.1 Характеристики транзакций и схем
4. Краткий обзор H-Store
4.1 Архитектура системы
4.2 Выполнение запросов
4.3 Дизайнер баз данных
4.4. Управление транзакциями, репликация и восстановление
5. Сравнение производительности
5.1 Классы запросов
5.2 Реализация
5.3 Результаты
6. Некоторые комментарии по поводу мира, в котором один размер не является пригодным для всех
6.1 Реляционная модель не обязательно является решением
6.2 SQL также не является решением
7. Резюме и планы на будущее
Ссылки

1. Введение

Все популярные реляционные СУБД берут свое начало от системы System R, разработанной в 70-е годы прошлого века. Например, СУБД DB2 является прямой наследницей System R, и на первый выпуск этой системы оказала сильнейшее влияние подсистема RDS System R. Аналогично, MS SQL Server – это непосредственный наследник Sybase System 5, на разработку которой очень сильно повлияла System R. Наконец, в первом выпуске Oracle был напрямую реализован пользовательский интерфейс System R.

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

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

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

Итак, существующие сегодня РСУБД разрабатывались в расчете на рынок обработки бизнес-данных в то время, когда имелись совсем другие интерфейсы пользователей, а аппаратура обладала совсем другими характеристиками. Эти РСУБД обладают рядом архитектурных черт, унаследованных от System R:

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

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

В статье [SBC+07] приводились результаты тестовых испытаний, в ходе которых основные РСУБД показали производительность, на два порядка уступающую производительности специализированных программных средств в нескольких прикладных областях:

  • в области управления текстовыми данными (специализированные программные средства от Google, Yahoo и т.д.);
  • в области хранилищ данных (системы с хранением данных по столбцам, такие как Vertica, Monet [Bon02] и т.д.);
  • в области обработки потоковых данных (системы обработки потоковых данных, такие как StreamBase и Coral8);
  • научные базы данных (системы хранения массивов данных, такие как MATLAB и ASAP [SBC+07]).

Эти результаты позволили одному из авторов (по всей видимости, Майклу Стоунбрейкеру) придти к следующим выводам:

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

В данной статье авторы дополняют результаты, представленные в [SBC+07], демонстрируя, что сегодняшние архитектуры РСУБД не подходят даже и для обработки бизнес-данных. Для этого используется методология, аналогичная той, которая применялась в [SBC+07]. Авторами разрабатывается новая СУБД H-Store, предназначенная для OLTP. H-Store уже работает достаточно устойчиво, чтобы позволить сравнить ее производительность с производительностью популярных РСУБД. Результаты экспериментов показывают, что H-Store на эталонном тестовом наборе TPC-C работает в 82 раза быстрее РСУБД.

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

Во втором разделе данной статьи обсуждаются архитектурные соображения, которые удалось использовать для достижения упомянутого показателя 82 на тестовом наборе TPC-C. В разд. 3 приводятся характеристики приложений, на поддержку которых ориентировано данное специализированное программное средство. В разд. 4 описываются некоторые детали разработки H-store. В разд. 5 содержатся экспериментальные данные, полученные при прогоне тестового набора TPC-C на H-Store и одной из популярных РСУБД. Наконец, в заключительном шестом разделе статьи приводятся некоторые радикальные предложения по поводу текущих исследовательских задач сообщества баз данных.

далее

Новости мира IT:

Архив новостей

Последние комментарии:

Релиз ядра Linux 4.14  (6)
Пятница 17.11, 16:12
Apple запустила Pay Cash (2)
Четверг 09.11, 21:15
Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...