Наткнулся на интересную серию статей касательно традиционных RDBMS и их перспектив.
Развитие коммерческих RDBMS за последние 25 лет можно охараетеризовать одной фразой "One Size Fits All". Традиционная RDBMS архитектура (изначально заточенная под одработку бизнес данных) использовалась во множестве data-centric приложений с разными характеристиками и требованиями. Авторы утверждают, что такой подход более не применим. Рынок DB должен распасться на ряд отдельных направлений: data warehousing, stream processing, sensor networks, text search, scientific и т.д.
В первых двух частях:
“One Size Fits All”: An Idea Whose Time Has Come and Gone:
http://www.cs.brown.edu/~ugur/fits_all.pdf
One Size Fits All? – Part 2: Benchmarking Results:
http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p20.pdf
авторы показывают, что специализированные БД могут превосходить традиционные RDBMS в 10-100 раз по производительности в своих областях. И так же предлагают некоторые архитектурые идеи для нового поколения БД.
В третьей части:
The End of an Architectural Era (It’s Time for a Complete Rewrite):
http://web.mit.edu/dna/www/vldb07hstore.pdf
авторы показывают, что "на своём поле" (OLTP) традиционные RDBMS уступают новому поколению БД в 100 раз по производительности.
Основные принципы, на которых строятся традиционные RDBMS:
— Ориентированное на диски хранилище и структуры индексов
— Многопоточность для скрытия латентности
— Контроль параллелизма основанный на локинге
— Восстановление основанное на логах
Были разработаны в конце 70 — начале 80 годов, и полностью утратили свою актуальность. Тем не менее код основных RDBMS растёт из System R, разработанной более 30 лет назад. И так никогда и не переписывался заново.
Предлагаются следующие постулаты для OLTP БД нового поколения:
— Основная память! Любая БД меньше терабайта сейчас может легко влезать в основную память. Соотв. надо делать хранилище данных и структуру индексов рассчитанной на основную память.
— Транзакции короткие! Никто сейчас не делает запрос пользователю во время выполнения транзакции. Либо есть все необходимые данные для выполнения, либо транзакция не выполняется. Соотв., учитывая использование основной памяти, любая транзакция будет выполняться меньше 1 мс. Соотв. отпадает необходимость в многопоточности и локинге. Транзакцию просто проще сразу выполнить от начала и до конца максимально быстро.
— Распределенность! Любая мало-мальски серьёзная БД будет распределенной. Это надо вносить в ядро БД. И на это так же можно повесить ряд других задач. Например, отдельный сервер не обязан быть сверх надёжным — кластер это обработает.
— Redo логи — основной ботлнек современных БД. Он не нужен! Кластер это обработает.
— Undo лог тоже не нужен в большинстве случаев!
— После устранения всего этого основным ботлнеком станет интерфейс с БД, основанный на ODBC/JDBC и SQL. Интерфейс должен поддерживать только хранимые запросы. Это так же даёт много ценной дополнительной информации для анализа и оптимизации, т.к. известны *все* запросы, которые будут выполняться в БД.
Статьи будут интересны интересующимся новыми веяниями в архитектуре, и вообще архитектурой систем. Так же могут помочь с выбором БД под конкретную задачу. Даётся обширный список источников, включающий аналогичные исследования и множество специализированных БД.
