A Short Summary of the Last Decades of Data Management • Hannes Mühleisen • GOTO 2024 (Рубрика Data)

Интересное выступление от Hannes Mühleisen на тему истории развития систем управления данными и куда они будут развиваться дальше. Сам Hannes является ученым по CS, а также создателем DuckDB и кофаундером DuckDB Lab.

Вот основные моменты выступления

• Автор начинает с отсылкам к глубокой истории, когда глинянные таблички использовались для учета в хозяйстве и это было раньше, чем появилась абстрактная письменность
• Дальше автор сразу переходит к роли IBM, чья история стартанула еще с переписи населения в США в 19 веке, а в начале 20 века после объединения нескольких компаний получилась IBM:) И взлет IBM именно как компьютерного гиганта начался с мейнфреймов, которые использовались для космонавтики в США -- IBM придумала иерархическую систему для менеджмента данных и она использовалась в этих мейнфреймах -- Дальше Edgar Frank "Ted" Codd придумал основы реляционной модели данных, в научной статье "A Relational Model of Data for Large Shared Data Banks" -- В 1973 году IBM сделала свою IBM System R, в которой была пилотная реализация реляционной модели
• Но в 1979 Oracle обошла IBM на повороте с промышленной реляционной базой Oracle
• В 1983 году IBM тоже включилась в гонку со своей IBM DB/2
• А уже в 1996 году в рамках академического проекта была создана PostgreSQL. Ее создал Michael Stonebraker из Berkley
• Для тех, кто интересуется генеалогией различных СУБД может быть интересна карта RDBMS Genealogy

Где-то в 80-е годы стало понятно, что одна база не покрывает всех сценариев и появилась развилка вида

• Transactional - в этом сценарии пользователи работают с транзакциями. Данные здесь эффективно хранить построчно (row-based), так как обычно нужна большая часть записи для чтения и обновления
• Analytical - в этом сценарии пользователи анализируют данные, здесь уже не особо нужны транзакции. Данные здесь эффективно хранить поколоночно (column-based), так как для расчета показателей часто нужны значения из конкретных колонок, при хранении их по колонкам их проще сжимать при хранении, а также считывать для рассчетов Для того, чтобы показать различия между СУБД автор приводит метафору пикапа и машинки формулы 1.
• Пикап - надежная рабочая лошадка, которая всегда должна работать и ей являются транзакционные базы
• Машинка формулы - это аналитические базы, которые должны быть быстрыми, но могут работать не всегда, так как они обычно не блокируют всю работу компании.

Дальше автор рассказывает про движение No SQL!

• 2006 год - Map/Reduce от Google для параллельной обработки задач на ненадежном оборудовании, из этого подхода вырос Hadoop. Изначально там не было SQL, но в 2010 году появился Hive, который вернул SQL поверх map/reduce, так как без SQL было слишком сложно писать запросы
• 2009 год - Schemaless от MongoDB. Тут концепция была в том, чтобы была не schema on write, что контролировалось базой, а schema on read, что должен был проверять app developer. В 2017 году в MongoDB появилась schema validation
• 2008 год - нет ACID транзакций и вместо этого tunable consistency в Cassandra. В 2023 году в Cassandra появились транзакции
• 2014 год - нет внутреннего storage в Apache Spark. В 2024 году появился внутренний storage

Все изменения были из-за того, что трио

• Таблицы
• SQL
• ACID слишком удобно для разработки приложений и именно туда будет двигаться работа с данными. Автор вспоминает про Postgres и SQLite, а также про newSQL как подход, что комбинирует это трио с масштабированием как в NoSQL. А дальше он говорит, что реляционные базы съедят почти все сценарии и показывает как это сделать с key/value, document, time series, vectors, graphs, data frames. Но, например, уже full text search не очень укладывается в реляционную модель.

Напоследок автор говорит о том, что big data мертва, так как теперь у нас есть возможность собрать очень мощную машинку, на которой запустить обработку того, что раньше крутилось в распределенной системе. И это, возможно, будет сильно эффективнее.

#Data #Architecture #Management #History