Designing Data-Intensive Applications Глава 1. Trade-Offs in Data Systems Architecture Введение Первая глава книги получилась объёмной как по количеству страниц так и по количеству информации. По сравнению с первым изданием появилось упоминание Single-Node Data Warehouse решений на примере DuckDB, SQLite, но без деталей. Детали будут раскрываться уже в более поздних главах. Основная мысль первой главы дать читателю понимание, что нет “серебряной пули”, и в каждом решении существуют как свои плюсы так и минусы (trade offs). Посыл авторов благородный, помочь читателю разобраться в море различных технологических решений. Дать фундамент, который будет помогать принимать правильные решения при проектировании архитектуры будущих приложений. Что изменилось по сравнению с первым изданием? Первое издание книги вышло в 2017 году, с тех пор прошло 9 лет. Мир не стоит на месте, технологии развиваются. По словам авторов, в новом издании они постарались уделить достаточно внимания технологиям вокруг ИИ инфраструктуры, cloud native решениям на базе хранилищ объектов по типу Amazon S3, полностью переписали главу про Batch Processing из-за неактуальности MapReduce в наше время (при проектировании новых архитектур). Конспект Приложение считается Data-Intensive, если управление данными это одна из его ключевых задач. Основные вызовы у таких приложений — эффективная обработка и хранение большого массива данных — обеспечение доступности данных в условиях отказа частей системы — обеспечение согласованности данных (data consistency) Главные строительные блоки — Базы данных для хранения информации (например, PostgreSQL, MySQL, Microsoft SQL Server и т.д.) — Кэш-системы для обеспечения быстрого доступа к данным (например, Redis, memcached) — Поисковые движки для обеспечения быстрого поиска в большом массиве данных (Elasticsearch, Sphinx) — Системы для потоковой обработки данных (Apache Flink, Apache Storm) — Системы для пакетной обработки данных (Apache Hadoop, Apache Spark) Примеры конкретных инструментов это моё личное дополнение, их множество, здесь приведены лишь наиболее популярные и те, что у меня на слуху. От себя я бы ещё добавил, что рука об руку с обработкой данных идут и различные оркестраторы и workflow-менеджеры по типу Apache Airflow, Oozie, Luigi, NiFi, Prefect, Dagster и т.д. Типы баз данных — Транзакционные (OLTP), авторы в книге также называют их операционными — Аналитические (OLAP) Транзакционные базы используются там, где данные берут своё начало, а именно базы для бэкенда приложения с которым пользователи взаимодействуют через фронтенд (веб-приложения, мобильные приложения и т.д.). Транзакционным базам присущи точечные запросы на чтение, запись, обновление или удаление. Например, по user_id. Запросы преимущественно формируются на стороне приложение, пользователь напрямую не имеет доступа к базе и не пишет запрос. Примеры: PostgreSQL, MySQL, Oracle DB, Microsoft SQL Server. Аналитические базы данных используются для работы с данными для принятия решений на стороне бизнеса. Такие базы хранят в себе данные, собранные в том числе из транзакционных баз. Пользователями таких баз в основном являются бизнес и дата аналитики, Data Science специалисты. Зачастую они напрямую посылают запросы к базе, используя SQL. Запросы чаще всего большие и подразумевают обработку огромного набора данных (большие выборки). Примеры: Amazon Redshift, ClickHouse, Apache Druid, Pinot. Современный подход к организации данных подразумевает четкое разделение между OLTP и OLAP. Но до массового внедрения OLAP транзакционные базы данных использовались и в качестве хранилища аналитических данных. Были придуманы способы моделирования аналитических данных с учётом ограничений реляционной модели, например, Star Schema, Snowflake Schema. В условиях современных OLAP баз данных такие подходы устарели. Связь между OLTP и OLAP