Почему идеи в базах данных возвращаются. Часть II

Александр напоминает: в первой части они с Алексеем разбирали модели данных и языки запросов, а теперь дошли до раздела про системную архитектуру — авторы показывают, как за двадцать лет менялись пропускная способность сетей, иопсы дисков и стоимость вычислений и как это переопределяло устройство решений. Александру эта часть зашла: редко отходишь так далеко, чтобы увидеть тенденции целиком. Алексей пришёл в T-Bank Oracle-администратором, работает больше семи лет и ведёт команду платформенных баз данных; он замечает разницу в тоне — в первой части авторы категорично делили технологии на живые и мёртвые, а здесь раскрыли скорее плюсы. Нулевой уровень он описывает по практике: таблица, строки, блоки на восемь или шестьдесят четыре килобайта, ссылка на следующий блок, если строка не поместилась. Адрес находишь по индексу, читаешь блок, а СУБД возвращает строку целиком и сама выбирает нужные поля; исключение — index only access.

Первое изменение относительно бейзлайна — колоночное хранение, яркий представитель которого ClickHouse: данные лежат по отдельным файлам, поэтому и сжимать проще, и векторизация работает гораздо лучше; Александр упоминает ещё одну быструю базу, которую удобно поднять локально для аналитики. У Алексея ClickHouse уже отдан как сервис в DBaaS, и он добавляет минуточку патриотизма — это разработка Яндекса. На DB Engines, к статистике которого многие относятся скептически, в топе по-прежнему Oracle, MS SQL и MySQL, но потребление ClickHouse растёт; вместе с колонками он даёт кластеризацию и ступеньку к OLAP-объёмам, тогда как в OLTP приём работает хуже и чаще не нужен. В ту же сторону, по словам Алексея, двигался Oracle Exadata: storage-нода знает раскладку строк и колонок и отдаёт наверх только нужное по предикатам. Александр вспоминает Vertica, к которой приложил руку один из авторов статьи Stonebraker; она была и у них, а потом её съели ClickHouse с одной стороны и облачные базы с другой.

Второй тип архитектуры — облачные базы данных. Алексей формулирует идею: хранение и обработка разъезжаются по разным узлам, и слой обработки можно динамически растягивать под дневной пик и сжимать обратно. Александр объясняет, почему это стало возможно: раньше медленная сеть заставляла держать вычисления рядом с данными, и два драйвера масштабирования — объём данных и интенсивность обработки — были склеены; потом объектные хранилища вроде S3 стали стандартом де-факто, а сеть стала быстрой. Данные сжимать не хочется, они ценные и должны просто лежать, а компьют хочется двигать под нагрузку. Пример для OLTP — AWS Aurora, которую Джефф Безос примерно в 2014 году назвал в письме акционерам среди прорывов Amazon: компьют отпилили от хранилища, между мастером и репликами гоняют только write-ahead log, а данные подтягивают из объектного хранилища в свой кэш в памяти. Пределы на чтение это сняло, запись по-прежнему упирается в единый мастер; Аврору, по воспоминаниям Александра, они разбирали с Виталием Кондратовым и Игорем Масловым на внутреннем канале Code of Architecture.

Третий тип — лейкхаус, который авторы, по пересказу Алексея, называют ещё одним решением, раздутым облачными платформами: единая инфраструктура, держащая и SQL-, и не-SQL-нагрузку поверх объектного хранилища, куда данные прикапываются в Parquet или ORC — ORC он, честно говоря, не встречал, внутри в основном Parquet. Александр видит здесь ту же сепарацию компьюта и хранилища, применённую в домене, который звался сначала DWH, потом data lake; он разводит ETL и ELT, называет озеро своим чистилищем и посмеивается над неймингом, в котором warehouse, lake и house норовят слипнуться. Практический предел старого подхода — Greenplum, одним из крупнейших пользователей которого в России компания, по их словам, и является: кластер шардов на довольно старом Postgres, где компьют и сторедж склеены. Данные ещё влезают, а поток запросов аналитиков уже нет, и компьют отдельно не отмасштабируешь. В новом подходе — Parquet, вендоронезависимый каталог Iceberg и движок вроде Trino — воркеры и слой данных растягиваются независимо.

Четвёртый класс — NewSQL; Алексей шутит, что фантазия с названием далеко не ушла, а смысл в том, чтобы вернуть строгие транзакции туда, где их не было: в Mongo, Cassandra и прочие большие хранилища. Александр даёт теорию: ACID против BASE, из которого он честно не помнит весь акроним, и потерянная линеаризуемость — единый порядок событий, одинаковый для всех. В NoSQL её не было, да и в реляционных на serializable работать не хотели, потому что он рушит производительность. Эрик Брюэр сформулировал CAP сначала как гипотезу, где-то в двухтысячных: при разделении сети выбираешь между консистентностью и доступностью. Брюэра забрал Google, где, насколько Александр помнит, он теперь VP в Google Cloud, а компания сделала Spanner с компонентом True Time на атомных часах; похожие базы потом строили уже на NTP. Ложка дёгтя от Алексея: модель держится на взаимных блокировках, и под нагрузкой всё упирается в них.

Александр соглашается, что на практике побеждают проверенные решения: шардированный Postgres понятно как эксплуатировать, а Spanner или Yandex Database, которая шла от других, детерминированных транзакций в духе Calvin, — волшебная коробка ценой в драгоценность. Акселераторы и блокчейн-базы оба почти пропускают: обзор GPU-баз двадцать четвёртого года Алексей скачал, но прочитать не успел, а в блокчейне Александр не понял саму идею. Дальше выводы авторов. Маркетинг недооценивать нельзя: Oracle в начале жизни, MySQL во времена Apache и PHP, MongoDB в стеке Mongo — Express — Angular — Node.js в 2010-е выезжали на нём, а продукт дорабатывали, уже завоевав рынок. Опенсорс от бигтехов бывает выложен и заброшен. Первый опыт установки важен, потому что адопшен идёт снизу: инженер поиграл, рассказал коллегам, и плохая молва закапывает продукт. Хейт в адрес ORM Алексею не отозвался — в вендорском ПО, отчётности и 1С без прослойки разработку не масштабировать; Александр вспоминает Postgres 9, кажется, в 2013-м, где деградацию вызвала не ORM, а пагинация лимитами и офсетами. Про ML оба сдержанны: разве что оптимизатор запросов, хотя Александр советует посмотреть на эволюционную систему оптимизации Google, переписавшую шедулинг Borg и сэкономившую 0,7% мощностей.