Наткнулся на интересную серию статей касательно традиционных RDBMS и их перспектив.
Развитие коммерческих RDBMS за последние 25 лет можно охараетеризовать одной фразой "One Size Fits All". Традиционная RDBMS архитектура (изначально заточенная под одработку бизнес данных) использовалась во множестве data-centric приложений с разными характеристиками и требованиями. Авторы утверждают, что такой подход более не применим. Рынок DB должен распасться на ряд отдельных направлений: data warehousing, stream processing, sensor networks, text search, scientific и т.д.
авторы показывают, что специализированные БД могут превосходить традиционные RDBMS в 10-100 раз по производительности в своих областях. И так же предлагают некоторые архитектурые идеи для нового поколения БД.
авторы показывают, что "на своём поле" (OLTP) традиционные RDBMS уступают новому поколению БД в 100 раз по производительности.
Основные принципы, на которых строятся традиционные RDBMS:
— Ориентированное на диски хранилище и структуры индексов
— Многопоточность для скрытия латентности
— Контроль параллелизма основанный на локинге
— Восстановление основанное на логах
Были разработаны в конце 70 — начале 80 годов, и полностью утратили свою актуальность. Тем не менее код основных RDBMS растёт из System R, разработанной более 30 лет назад. И так никогда и не переписывался заново.
Предлагаются следующие постулаты для OLTP БД нового поколения:
— Основная память! Любая БД меньше терабайта сейчас может легко влезать в основную память. Соотв. надо делать хранилище данных и структуру индексов рассчитанной на основную память.
— Транзакции короткие! Никто сейчас не делает запрос пользователю во время выполнения транзакции. Либо есть все необходимые данные для выполнения, либо транзакция не выполняется. Соотв., учитывая использование основной памяти, любая транзакция будет выполняться меньше 1 мс. Соотв. отпадает необходимость в многопоточности и локинге. Транзакцию просто проще сразу выполнить от начала и до конца максимально быстро.
— Распределенность! Любая мало-мальски серьёзная БД будет распределенной. Это надо вносить в ядро БД. И на это так же можно повесить ряд других задач. Например, отдельный сервер не обязан быть сверх надёжным — кластер это обработает.
— Redo логи — основной ботлнек современных БД. Он не нужен! Кластер это обработает.
— Undo лог тоже не нужен в большинстве случаев!
— После устранения всего этого основным ботлнеком станет интерфейс с БД, основанный на ODBC/JDBC и SQL. Интерфейс должен поддерживать только хранимые запросы. Это так же даёт много ценной дополнительной информации для анализа и оптимизации, т.к. известны *все* запросы, которые будут выполняться в БД.
Статьи будут интересны интересующимся новыми веяниями в архитектуре, и вообще архитектурой систем. Так же могут помочь с выбором БД под конкретную задачу. Даётся обширный список источников, включающий аналогичные исследования и множество специализированных БД.
Что касается сути статьи, то ИМХО автор весьма замаскированно пожертвовал целостностью данных ради производительности. В разделе "4.1 «Входная» и «выходная» обработка" налицо dirty reads. Либо я что-то очень важное упустил, либо Майкл Стоунбрейкер выкинул все транзакции, после чего написал псевдонаучную статью о том какие все пидарасты и только он д'Артаньян.
"4.2 Правильные примитивы" выглядит крайне надуманным. Почему нельзя было с данными хранить время их поступления, причём чтоб время поступления было кластерным индексом? Непонятно о каких таких страшных потерях производительности идёт речь.
"4.3 Бесшовная интеграция обработки, выполняемой СУБД, с обработкой, производимой приложением" просто смешной раздел. Вся его суть в том что если приложению не нужна клиент-серверная архитектура, то надо пользоваться встраиваемыми СУБД. Право же на открытие не тянет.
"4.4 Высокий уровень доступности" вызывает хохот. Автор, начинает раздел так, как будто не имеет ни малейшего предстваления о кластерах. Повышать доступность за счёт уменьшения времени восстановления отдельно взятого сервера это конечно весело, но с реалиями жизни никак не связано. К концу он о них вспоминает, но осадочек от "довольно большого времени" требуемого на восстановление, конечно остаётся. За психологию 5, за остальное 2.
Порадовал отрывок
В третьих, в СУБД при восстановлении затрагиваются только табличные данные и игнорируются состояния операций. Например, в приложении Feed Alarm значения счетчиков не сохраняются в таблицах; следовательно, состояние счетчиков будет утрачено после отказа. Одним из простых решений было бы сохранение в таблицах состояния всех операций, чтобы можно было использовать восстановление в стиле СУБД; однако применение такого решения привело бы к существенному замедлению работы приложения.
Вместо того чтобы сделать транзакцию в самом Feed Alarm откатывая значения счётчика при ошибке, всё свалили на СУБД как на крайнюю. Некрасиво.
В "5.1 Хранилища данных" нам открывают великую тайну хранения по столбцам, хотя все DBA давным давно научились делать таблицы вида
table (id REFERENCES another_table.id, property)
где всё фактически по столбцам и хранится. Нового софта для этого не надо.
В "5.3 Текстовый поиск" нам откровенно врут. Гугл делал свою систему не потому что возможности или производительность существующих не устраивли, а потому что не устраивала кластеризуемость. Это известный факт.
В "5.4 Научные базы данных" на СУБД сперва свалили Data Mining, потом сказали: "Вот видите, не справляются". Подобные задачи и не надо решать на СУБД и никто в здравом уме не собирался. Если вилкой неудобно збивать гвозди это не недостаток вилки.
Там идёт обсуждение OLTP баз. Полная семантика транзакций поддерживается. Можно выполять хранимые процедуры на центральном сервере. И т.д.
Вопросы тоже возникают. Например, какое кол-во процедур в реальности будут single sited или one-shot. Но имхо статья всё равно интересная и стоит чтения.
Здравствуйте, remark, Вы писали:
R> — Основная память! Любая БД меньше терабайта сейчас может легко влезать в основную память. Соотв. надо делать хранилище данных и структуру индексов рассчитанной на основную память.
Интересно как он собирается сохранять данные в случае отказа?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, remark, Вы писали:
R>> — Основная память! Любая БД меньше терабайта сейчас может легко влезать в основную память. Соотв. надо делать хранилище данных и структуру индексов рассчитанной на основную память.
AJD>Интересно как он собирается сохранять данные в случае отказа?
Здравствуйте, remark, Вы писали:
R>Наткнулся на интересную серию статей касательно традиционных RDBMS и их перспектив.
R>Развитие коммерческих RDBMS за последние 25 лет можно охараетеризовать одной фразой "One Size Fits All". Традиционная RDBMS архитектура (изначально заточенная под одработку бизнес данных) использовалась во множестве data-centric приложений с разными характеристиками и требованиями. Авторы утверждают, что такой подход более не применим. Рынок DB должен распасться на ряд отдельных направлений: data warehousing, stream processing, sensor networks, text search, scientific и т.д.
R>В первых двух частях: R>“One Size Fits All”: An Idea Whose Time Has Come and Gone: R>http://www.cs.brown.edu/~ugur/fits_all.pdf
R>One Size Fits All? – Part 2: Benchmarking Results: R>http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p20.pdf
R>авторы показывают, что специализированные БД могут превосходить традиционные RDBMS в 10-100 раз по производительности в своих областях. И так же предлагают некоторые архитектурые идеи для нового поколения БД.
По-моему это очевидно: узкоспециализированная вещь будет эффективнее на конкретной задаче. Что касается БД, то за примерами далеко ходить не надо, никому не придет в голову использовать для сложных финансовых расчетов RDBMS (исключительно). Для этого есть Time-Series Databases, которые заточены под определенный тип доступа к данным (кстати TSDBs используют Memory Mapped Files по-максимуму, т.е. выгружают данные в память насколько это возможно). Тоже касается БД изображений и видео, где свои требования. Разумеется, приходится жертвовать унифицированностью доступа к данным, в угоду эффективности. RDBMS в этой связи компромисс.
Здравствуйте, Trean, Вы писали:
T>По-моему это очевидно: узкоспециализированная вещь будет эффективнее на конкретной задаче.
Тут как бы уже практика берёт своё. MSSQL, например, или, скажем, Oracle — не вещь в себе. Есть куча учебной литературы, причём не только от производителя, огромный опыт использования, комьюнити пользователей.
А то завяжешь всё на узко-специализированную систему, выиграешь 20% производительности, а потом ставится задача кластеризации и приехали... Никогда не надо забывать что надёжность и предсказуемость системы один из самых важных параметров. Если приложение ускорили в 2 раза это не должно сопровождаться падением системы в два раза чаще.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Trean, Вы писали:
T>>По-моему это очевидно: узкоспециализированная вещь будет эффективнее на конкретной задаче.
A>Тут как бы уже практика берёт своё. MSSQL, например, или, скажем, Oracle — не вещь в себе. Есть куча учебной литературы, причём не только от производителя, огромный опыт использования, комьюнити пользователей.
Куча учебной литературы не заставят делать систему то, что она делать не умеет. Вот и в Оракле об этом подумали и купили Times Ten. Так как Oracle ничего не могла противопоставить kdb+ от Kx, которая тянет до 1 миллиона вставок в секунду, и 10 миллионов записей в секунду на выборку.
A>А то завяжешь всё на узко-специализированную систему, выиграешь 20% производительности, а потом ставится задача кластеризации и приехали... Никогда не надо забывать что надёжность и предсказуемость системы один из самых важных параметров. Если приложение ускорили в 2 раза это не должно сопровождаться падением системы в два раза чаще.
Так кто ж спорит, про требования к системе на этапе проектирования архитектуры забывать не стоит
А 20% это вообще копейки, не тот прирост ради которого имеет смысл перескакивать на другой продукт.
Здравствуйте, remark, Вы писали:
R>>> — Основная память! Любая БД меньше терабайта сейчас может легко влезать в основную память. Соотв. надо делать хранилище данных и структуру индексов рассчитанной на основную память. AJD>>Интересно как он собирается сохранять данные в случае отказа?
R>Реплики это обработают
Как именно?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, remark, Вы писали:
R>>>> — Основная память! Любая БД меньше терабайта сейчас может легко влезать в основную память. Соотв. надо делать хранилище данных и структуру индексов рассчитанной на основную память. AJD>>>Интересно как он собирается сохранять данные в случае отказа?
R>>Реплики это обработают
AJD>Как именно?
На других репликах имеются актуальные целостные реплики данных
Здравствуйте, remark, Вы писали:
R>Здравствуйте, AndrewJD, Вы писали:
AJD>>Здравствуйте, remark, Вы писали: AJD>>>>Интересно как он собирается сохранять данные в случае отказа? R>>>Реплики это обработают AJD>>Как именно? R>На других репликах имеются актуальные целостные реплики данных
Вспоминается презентация по Oracle Coherence, которую недавно смотрел. Так-то по сути это распределённый кэш, но рассматривать можно и как несколько куцую распределённую БД в памяти. Там чувак интересные картинки показывал, что происходит, когда один из хостов "отваливается". Там система с наличием 2 реплик данных (основной реплики и "запасной").
Здравствуйте, Курилка, Вы писали:
R>>На других репликах имеются актуальные целостные реплики данных
К>Вспоминается презентация по Oracle Coherence, которую недавно смотрел. Так-то по сути это распределённый кэш, но рассматривать можно и как несколько куцую распределённую БД в памяти. Там чувак интересные картинки показывал, что происходит, когда один из хостов "отваливается". Там система с наличием 2 реплик данных (основной реплики и "запасной").
Здравствуйте, remark, Вы писали:
R> Традиционная RDBMS архитектура (изначально заточенная под одработку бизнес данных) использовалась во множестве data-centric приложений с разными характеристиками и требованиями. Авторы утверждают, что такой подход более не применим.
Ну, разные авторы утверждают это аккурат последние лет 30... И нельзя сказать, что их утверждения совсем уж лишены оснований, но...
R> Рынок DB должен распасться на ряд отдельных направлений: data warehousing, stream processing, sensor networks, text search, scientific и т.д.
Собственно, по факту он уже давно распался, только не с такой душераздирающей гранулярностью. warehousing выделился в OLAP решения, которые уже очень давно поставляются независимо. Поиск, если речь не идет о независимом решении именно для поиска, поставляется вместе с основным OLTP движком, даже такая экзотика как spatial и аналитические запросы встраиваются в OLTP движки, поверх той же реляционной модели.
R>авторы показывают, что специализированные БД могут превосходить традиционные RDBMS в 10-100 раз по производительности в своих областях.
Могут. Это вообщем-то не фокус, ясен байт, что если заточить БД под конкретную задачу, то она будет существенно эффективнее. Только вот разработка БД под конкретную задачу как правило не окупается, даже если производительность вырастет в 1000 раз.
R>авторы показывают, что "на своём поле" (OLTP) традиционные RDBMS уступают новому поколению БД в 100 раз по производительности.
Гонят..
R>Были разработаны в конце 70 — начале 80 годов, и полностью утратили свою актуальность.
И здесь тоже передергивают, так как актуальности это совсем не утратило и не утратит еще те же лет 30 как минимум.
R> Тем не менее код основных RDBMS растёт из System R, разработанной более 30 лет назад. И так никогда и не переписывался заново.
Ну, тут они либо просто не в курсе, либо уж совсем за дураков читателей держат...
R> — Основная память! Любая БД меньше терабайта сейчас может легко влезать в основную память. Соотв. надо делать хранилище данных и структуру индексов рассчитанной на основную память.
Тут все не так просто. Базу в любом случае надо держать на диске и каждая транзакция должна уметь до него доехать.
R> — Транзакции короткие! Никто сейчас не делает запрос пользователю во время выполнения транзакции.
Во. Они и так короткие.
R> Транзакцию просто проще сразу выполнить от начала и до конца максимально быстро.
То есть, тупо сериализовать? Смело..
R> — Распределенность! Любая мало-мальски серьёзная БД будет распределенной. Это надо вносить в ядро БД. И на это так же можно повесить ряд других задач. Например, отдельный сервер не обязан быть сверх надёжным — кластер это обработает.
А несерьезным что делать? Тоже кластер городить? Надежность им нужна не меньше чем серьезным.
R> — Redo логи — основной ботлнек современных БД. Он не нужен! Кластер это обработает.
Подавляющему большинству приложений кластер не нужен. Заводить его просто потому что БД по другому не умеет?
R> — Undo лог тоже не нужен в большинстве случаев!
А что делать когда он все-таки нужен?
R> Интерфейс должен поддерживать только хранимые запросы. Это так же даёт много ценной дополнительной информации для анализа и оптимизации, т.к. известны *все* запросы, которые будут выполняться в БД.
Мысль, в целом, здравая. Однако множество попыток пойти по этому пути, на сколько мне известно, к успеху не привели.
R>Статьи будут интересны интересующимся новыми веяниями в архитектуре, и вообще архитектурой систем.
Судя по изложенным тезисам — сомневаюсь..
Собственно почему Fits All...? Если задаться этим вопросом, то станет ясно, что подобная ситуация не сложилась бы, если бы вложения в RDBMS не оправдывали бы себя. На данный момент реляционка — действительно fits в подавляющем большинстве случаев. У реляционки есть одно важное преимущество, она предоставляет набор очень удобных абстракций для работы с данными, которые мало завист от приложения, которое эту БД использует. Любое частное решение моментально оказывается завязанным на конкретный сценарий и конкретное приложение... А жизнь показала, что срок жизни данных намного превышает срок жизни приложения, которое эти данные использует. По этой причине, на мой взгляд, с реляционок мы не слезем еще очень долго.
Мы уже победили, просто это еще не так заметно...
