OLTP — это дорого, используйте ClickHouse.

В этой статье мы рассмотрим новый паттерн применения — выгрузку большей части данных из Postgres в ClickHouse. Это приводит к на порядок лучшей юнит-экономике ваших приложений по мере роста объема данных.

Мы начнем с того, что база данных оперативной обработки транзакций (OLTP), такая как Postgres, делает при каждой записи и чтении, а также с издержек, которые она несет для поддержания ACID-совместимости транзакций. Затем мы покажем, как перестать платить эту цену за данные и запросы, которые в этом не нуждаются.

В 2000-х годах во время бума веб- и мобильных технологий объемы данных, которые приходилось обрабатывать системам, росли экспоненциально. В то время многие быстро растущие компании обратились к NoSQL-базам данных за масштабируемостью и эффективностью, которые SQL-базы данных тогда не могли предоставить.

В течение последующих нескольких лет вопрос масштабируемости операционных баз данных был решен. Благодаря достижениям облачных технологий новейшие системы предлагают десятки терабайт на одиночных развертываниях OSS PostgreSQL с одним писателем. При этом некоторые форк-решения с закрытым исходным кодом масштабируются до более чем 100 ТБ хранилища без ущерба для гарантий OLTP. В то же время такие системы, как Spanner и шардированные MySQL/PostgreSQL, позволяют компаниям веб-масштаба достигать транзакционной согласованности в глобальном масштабе.

Повышенная масштабируемость сопровождается крупными счетами за облачную инфраструктуру. Системы на базе OLTP-движков масштабируются в лучшем случае линейно. Вы платите в N раз больше за Postgres, вы получаете до N раз больше хранилища и вычислительной мощности. С архитектурой ClickHouse Managed Postgres на базе NVMe вы можете получить лучшие множители транзакционной пропускной способности. Тем не менее, по мере взрывного роста ваших объемов данных затраты на вычисления и хранение растут линейно.

В 2026 году благодаря буму агентного ИИ объемы данных и объемы запросов растут быстрее, чем когда-либо прежде, достигая десятков терабайт транзакционных данных быстрее, чем раньше в этом цикле, что требует лучшей экономичности для динамично развивающихся компаний.

Мы можем посмотреть за рамки традиционных OLTP-решений в поисках ответа, точно так же, как это сделали интернет-компании в 2000-х годах.

PostgreSQL здесь используется как самая популярная OLTP-база данных для новых приложений. Другие операционные системы баз данных работают по очень похожей механике.

PostgreSQL гарантирует четыре фундаментальных транзакционных свойства для всех записываемых и считываемых данных: атомарность, согласованность, изолированность и долговечность (ACID):

• Атомарность: применяются все изменения транзакции или ни одно из них.
• Согласованность: каждая транзакция оставляет базу данных в допустимом состоянии с соблюдением всех ограничений.
• Изолированность: параллельные транзакции не мешают друг другу; каждая ведет себя так, будто выполняется в одиночку.
• Долговечность: зафиксированные изменения переживают сбои процессов и падения инстансов.

Гарантирование ACID для сложных многострочных транзакций при параллельном выполнении тысяч таких операций — сложная задача. Postgres решает её с помощью нескольких механизмов, и каждый из них добавляет работы к каждой записи: для обеспечения долговечности он сбрасывает запись журнала упреждающей записи (WAL) транзакции на диск перед подтверждением каждого COMMIT. Для изоляции он использует MVCC: обновление никогда не изменяет строку на месте. Вместо этого он записывает полную новую физическую копию строки и оставляет старую копию в виде мертвой кортежи (dead tuple), пока VACUUM не вернет ее. А чтобы чтение сразу после записи видело новые данные, каждая вставка или обновление также изменяют каждую затронутую запись индекса.

Если сложить все это вместе, амплификация оказывается значительной: для изменения ~100 байт данных строки Postgres изменяет несколько 8-килобайтных страниц кучи (heap) и индексов в пуле буферов и в конечном итоге записывает десятки килобайт на диск в виде WAL, полностраничных образов и сбросов страниц.

И дело не только в пути записи. Когда система полностью поддерживает ACID, форматы данных также создаются под это, и чтение влечет за собой дополнительные расходы:

• Размер хранилища: Postgres хранит каждый кортеж в несжатых 8-килобайтных страницах. Стоимость хранения устоявшихся, редко читаемых данных такая же, как у строк, которые вы обновляете каждую секунду.
• Дисковый ввод-вывод при чтении: каждое чтение строки загружает весь кортеж со всеми его столбцами плюс страницы индексов, которые его определяют. Как только объем данных превышает объем оперативной памяти, эти 8-килобайтные страницы продолжают вытеснять друг друга из кеша, поэтому все больше и больше операций чтения уходят на диск.
• Амплификация индексов: любой поиск по чему-либо, кроме первичного ключа, требует индекса, поскольку полное сканирование таблицы слишком дорого при масштабировании. Postgres обновляет каждый индекс в рамках транзакции записи, что замедляет запись и увеличивает затраты на хранение и сборку мусора.

Ниже представлено упрощенное представление амплификации записи и чтения в базе данных PostgreSQL, когда объем данных превышает буферы памяти:

Совместное хранение (shared storage) и шардированные системы спроектированы так, чтобы обеспечивать линейное масштабирование в зависимости от объема данных и рабочей нагрузки.

Для шардированной системы PostgreSQL при определенных инвестициях в схему можно добиться практически линейной масштабируемости объема данных и транзакционной способности по мере вливания средств.

В реальном мире большинство приложений получают убывающую отдачу из-за затрат на дополнительную координацию и периодические многофазные межшардовые коммиты.

Решения с совместным хранением влекут за собой дополнительные затраты на инфраструктуру для обработки рабочей нагрузки, поскольку большему количеству частей распределенной системы требуется избыточность. Дополнительные затраты затем амортизируются за счет агрессивного мультитенантного размещения на стороне хранилища.

Даже с учетом дополнительных оптимизаций и более дешевого объектного хранилища эти системы, как правило, обходятся дороже, чем простые развертывания OSS для рабочих нагрузок.

Многие приложения в различных бизнес-доменах по-разному относятся к активно изменяемым и устоявшимся данным. Активное состояние и последние строки часто используются для записи новых транзакций, они считываются пользователями и системами интеграции. После прохождения определенного временного окна или критерия активности данные остаются преимущественно доступными только для чтения, к ним обращаются нечасто, но их все равно необходимо сохранять.

Вот несколько примеров из различных бизнес-доменов приложений:

• Финансовые транзакции до предыдущего отчета сохраняются для нечастого доступа или аудита.
• Розничные покупки по истечении срока возврата становятся доступными только для чтения, хотя и необходимы для просмотра истории.
• Социальные активности после истечения периода возможных изменений по-прежнему доступны для просмотра.
• Метаданные тенантов для деактивированных клиентов становятся доступными только для чтения.

Во всех этих примерах, как только данные переходят из состояния с интенсивным изменением в устоявшееся состояние, необходимость в ACID отпадает. Тем не менее, данные влекут за собой сопутствующие расходы, пока они поддерживаются в OLTP-хранилище.

ClickHouse — это движок базы данных SQL. Он может обрабатывать любую SQL-нагрузку, для которой вашему приложению требуется база данных.

ClickHouse не оптимизирован для высокочастотных ACID-транзакций, и это полностью меняет экономику:

• Хранилище: колоночное сжатие обычно уменьшает объемы данных в 10–30 раз.
• Инфраструктура: решения на базе Postgres полагаются на крупные высокопроизводительные диски или уровни кеширования, что примерно в 5 раз дороже сопоставимой настройки ClickHouse Cloud.
• Индексирование: индексы создаются в фоновом режиме по большим пакетам строк, поэтому их обновление требует на порядки меньше CPU на одну запись.
• Агрегации: сводные и аналитические запросы обходятся примерно в 100 раз дешевле в выполнении благодаря специализированным структурам индексов, более простой модели параллелизма и отсутствию конкуренции за кеш с операциями записи.

Компромиссы:

• Более медленное чтение отдельных строк: восстановление полной строки из данных столбцов может занимать сотни миллисекунд.
• Согласованность в конечном счете: при чтении могут отображаться данные с задержкой до одной секунды.

Мало какие приложения готовы мириться с этим для данных, которые постоянно меняются. Но как только данные стабилизируются, зачем переплачивать в 5–10 раз за их готовность к обновлениям, которые никогда не наступят?

Вот как это работает:

• Операции записи и чтение свежих строк остаются в Postgres.
• ClickHouse обслуживает чтение стабилизированных данных, большинство запросов, требующих агрегации, а также периодическую запись.
• ClickHouse предлагает наилучшую экономическую эффективность для аналитических запросов в реальном времени и хранилищ данных для обоих уровней данных.

Бонус: меньше индексов и упрощенное обслуживание означают снижение затрат на вычислительные ресурсы PostgreSQL.

(CEO Janitor AI делится историей успеха переноса стабилизированных данных в ClickHouse на встрече CH South Bay Meetup)

Создание приложения с использованием двух баз данных, поддержание синхронизации данных и контроль сложности системы — непростая задача. ClickHouse Cloud создан для того, чтобы упростить этот процесс.

Наша миссия в ClickHouse — обеспечить лучшее в своем классе соотношение цены и производительности как для аналитических, так и для транзакционных рабочих нагрузок.

Единый стек OLTP+OLAP в ClickHouse Cloud оптимизирован для максимального использования преимуществ Postgres и ClickHouse, а также для обеспечения бесшовной интеграции:

• Локальное хранилище NVMe для данных Postgres обеспечивает в 2–10 раз более быстрые транзакции и более высокую пропускную способность для рабочих нагрузок OLTP.
• WalShadow — наш новейший встроенный вариант CDC, позволяющий реплицировать данные в ClickHouse за миллисекунды без ущерба для производительности и стабильности Postgres.
• pg_clickhouse — лучший в своем классе FDW для Postgres. Ваше приложение может продолжать использовать протокол Postgres, получая при этом экономические выгоды ClickHouse. Это экономит ваши первоначальные инженерные затраты.

Вы можете реализовать этот шаблон в ClickHouse Cloud уже сегодня и сократить расходы на обслуживание стабилизированных данных на порядок. Следующий шаг в нашей дорожной карте — полностью управляемое решение, которое будет автоматически переносить стабилизированные данные в ClickHouse за вас.

Попробуйте!