Приложениям необходимы быстрые чтение и запись, иначе они непригодны к использованию. Когда основной экземпляр Postgres не может обеспечить хорошую производительность, одним из существенных решений является синхронизация части рабочего набора вблизи приложения. Чтение становится локальным, а нагрузка на центральную базу данных снижается. Это может быть полезно, но платой за это становится еще один уровень данных, которым нужно управлять, в то время как запись по-прежнему зависит от центрального Postgres.
В этой статье мы рассмотрим, как работает локальная синхронизация данных, почему агенты ИИ делают локальный рабочий набор труднее предсказуемым и может ли более быстрый экземпляр центрального Postgres упростить архитектуру с самого начала.
Многие управляемые службы Postgres хранят свои данные на сетевых накопителях. Amazon RDS for PostgreSQL, например, хранит данные на томах EBS, доступных по сети, причем каждый том имеет собственные лимиты по IOPS и пропускной способности. Другие службы, такие как Neon, идут дальше и полностью отделяют вычисления от хранения. Такая архитектура обеспечивает сохранность данных при сходе с дистанции вычислительного узла и гибкость выделения ресурсов, но каждое чтение, не попавшее в кэш, должно проходить через сеть.
Это имеет значение, как только рабочая нагрузка начинает упираться в ввод-вывод (I/O). В этот момент добавление вычислительных мощностей не делает базу данных быстрее. Чтение по-прежнему требует выборки страниц из хранилища, запись по-прежнему генерирует WAL, а фоновые задачи, такие как VACUUM, конкурируют за тот же бюджет операций ввода-вывода. По мере роста параллелизма запросы замедляются, а хвостовая задержка увеличивается.
Именно поэтому приложения на управляемом Postgres часто работают медленнее по мере роста использования, даже когда процессор и память выглядят нормально. Прежде чем добавлять локальный уровень данных для обхода этой задержки, проверьте, не является ли настоящим узким местом система хранения под вашей базой данных.
Когда основная база данных начинает работать медленно, стандартным решением является добавление уровня перед ней. Годами этим решением был кэш вроде Redis или Valkey. В последнее время движки синхронизации продвинули эту идею дальше, сохраняя синхронизированную копию необходимых приложению данных внутри самого приложения. Уровень синхронизации подписывается на поток логической репликации базы данных, фильтрует изменения до заданного подмножества и поддерживает это подмножество материализованным в локальном хранилище. Хранилище может располагаться в памяти, во встроенной базе данных на клиенте или в кэше на пограничном узле (edge node). Механизм остается прежним.
Разработчик заранее определяет подмножество: какие таблицы, какие строки (обычно фильтр по столбцу арендатора или пользователя) и какие столбцы. В многопользовательском приложении подмножество для одного клиента — это, как правило, строки только этого арендатора и ничего больше. Каждый клиент, заявляющий одинаковое подмножество, получает одинаковый поток изменений, поэтому затраты на уровень синхронизации разделяются, когда множество клиентов запрашивают одни и те же данные.
Как только подмножество создано, чтение всего, что находится внутри него, становится локальным. Экраны, формы и панели мониторинга запрашивают локальное хранилище, и круговой путь (round trip) к Postgres исчезает из пути чтения для этих запросов. Чтение всего, что находится за пределами подмножества, по-прежнему направляется в базу данных, либо подмножество должно быть предварительно расширено.
Приложение приобретает вторую копию части своих данных с собственным жизненным циклом. Кто-то должен решать, что относится к подмножеству, когда оно изменяется, как долго клиент хранит его и что происходит при изменении схемы. Это того стоит для приложений, работающих в автономном режиме или в ненадежных сетях, а также для приложений, где множество клиентов читают один и тот же стабильный рабочий набор. Это менее очевидно оправдано, когда единственным требованием является быстрое чтение из онлайн-базы данных с хорошим подключением. Предсказуемые запросы облегчают определение подмножества. Сами по себе они не означают, что вам необходима локальная копия.
Уровень синхронизации обрабатывает только путь чтения, поэтому приложение должно поддерживать отдельный путь записи в центральный Postgres, обычно через собственный API. Как только транзакция фиксируется, изменение возвращается через логическую репликацию, проходит через уровень синхронизации и попадает в каждое локальное хранилище, чье объявленное подмножество включает затронутые строки. Таким образом, запись производит два отдельных события на клиенте: ответ API и появление зафиксированного изменения в локальном наборе данных вскоре после этого.
Чтобы скрыть этот разрыв, приложения сохраняют оптимистичное состояние. Изменение применяется к локальному представлению немедленно, до подтверждения со стороны сервера. Затем приложение должно согласовать это временное состояние с тем, что поступает через поток синхронизации, который включает зафиксированную версию собственной записи, а также записи от других клиентов, затрагивающие те же строки. Когда собственная запись появляется в потоке, временная копия удаляется. Если запись отклонена, временную копию приходится откатывать и исправлять представление.
Postgres остается авторитетным источником на протяжении всего процесса, и именно здесь упорядочиваются параллельные записи посредством транзакций. Приложение, которое считывает зафиксированное состояние напрямую из Postgres, получает этот порядок бесплатно. Оно никогда не ждет догоняющую локальную копию и никогда не хранит две версии одной и той же строки. Локальная копия обеспечивает быстрое чтение в обмен на проблему согласования, которую приложение должно решать самостоятельно. Ожидающие локальные изменения, асинхронно поступающие зафиксированные данные и представление, которое видит пользователь, — все они должны быть согласованы.
Традиционное приложение работает с ограниченным рабочим набором, поскольку пользователи перемещаются по нему по предсказуемым шаблонам. Страница продукта загружает информацию о продукте, страница выставления счетов загружает одну конкретную учетную запись, а страница поиска запрашивает заданный набор полей. Агент ИИ ведет себя иначе: он может загрузить продукт, определить клиентов, которые его купили, а затем найти похожие продукты — и все это на основе подсказок (промптов) и контекста, предоставляемых во время выполнения.
Теперь парадигма изменилась. С агентами разработчик не всегда может предсказать рабочий набор приложения или точно определить его границы. Объявленные подмножества остаются возможными, но границы рабочего набора должны быть достаточно широкими, чтобы поддерживать возможные пути запросов агента. Загрузка по требованию и прогрессивная загрузка могут предотвратить синхронизацию всего подмножества целиком, но нематириализованные данные по-прежнему требуют удаленного запроса, прежде чем станут доступны для локального запроса.
Это порождает ряд компромиссов:
- Синхронизировать данные в широком диапазоне и передавать то, что агент может никогда не использовать.
- Загружать данные постепенно и возвращать синхронизацию на путь чтения.
- Создавать подмножества под конкретные задачи и управлять их жизненным циклом по отдельности.
Расход (fan-out) уровня синхронизации наиболее эффективен, когда множество потребителей повторно используют одно и то же подмножество. Когда агентам требуются разные изменяющиеся подмножества данных, повторное использование локальных копий снижается, а возможности для амортизации работы по синхронизации уменьшаются. Возникает вопрос: если набор данных является движущейся мишенью, продолжает расти и постоянно требует синхронизации новых данных локально, остается ли эта архитектура актуальной?
ClickHouse Managed Postgres запускает Postgres на NVMe-накопителях, физически подключенных к вычислительным ресурсам базы данных. По сравнению с сетевыми хранилищами это снижает задержку дисковых операций и обеспечивает значительно больше IOPS для чтения, записи, активности WAL и обслуживания. Результатом являются более низкая задержка и более высокая пропускная способность запросов по сравнению с сетевыми решениями Postgres.
В случае приложений с хорошим качеством связи, если запросы к центральному экземпляру Postgres уже удовлетворяют требованиям по задержке и пропускной способности, поддержание синхронизированного локального набора данных может принести больше сложности, чем пользы от прироста производительности.
Это важно и для агентских архитектур (server-side agents). Они обычно работают вблизи бэкенд-сервисов и уже зависят от сетевого доступа к службам инференса или другим инструментам. Кроме того, они могут существовать для выполнения лишь одной задачи, из-за чего повторное использование локального набора данных оказывается недостаточным для оправдания затрат на его синхронизацию. Когда рабочий набор данных агента постоянно меняется, прямые запросы к быстрой авторитетной базе данных могут оказаться более простым решением:
- Выполнение запросов к любым авторизованным операционным данным через существующий API
- Чтение и запись в одну и ту же авторитетную систему
- Чтение из центрального экземпляра, когда важна немедленная согласованность
- Избежание синхронизации данных, которые агент может никогда не запросить
Архитектура принимает следующий вид:
ClickHouse Managed Postgres поддерживает реплики для чтения, что позволяет масштабировать нагрузку от агентов с интенсивным чтением горизонтально, не создавая локальный набор данных для каждого агента.
NVMe не решает проблемы неэффективных запросов. Пул соединений, оптимизация запросов и управление параллелизмом по-прежнему важны. Хотя более быстрое хранилище увеличивает емкость центральной базы данных, оно не устраняет все ограничения. Преимущество с архитектурной точки зрения заключается в том, что в привычной среде Postgres можно выполнять больший объем работы до того, как возникнет необходимость создавать еще одну копию данных на уровне приложения.
Есть одна копия данных, которая базе данных все же необходима, и это не копия на уровне приложения. Локальное NVMe-хранилище работает быстро, потому что расположено рядом с вычислительными ресурсами, но это также означает, что оно не переживет выход из строя этих ресурсов само по себе. ClickHouse Managed Postgres решает эту проблему так, как Postgres решал ее всегда: с помощью репликации на уровне базы данных, а не репликации дисков.
Сервис может работать с количеством резервных копий (standby) до двух, распределенных по зонам доступности. При наличии двух резервных копий репликация является синхронной: первичный узел ожидает подтверждения записи хотя бы от одной резервной копии перед тем, как подтвердить ее выполнение, поэтому при переключении отказоустойчивости не теряются ни одни зафиксированные транзакции. С одной резервной копией репликация является асинхронной, что жертвует небольшим окном недавних транзакций ради более низкой задержки записи. В обоих случаях переключение на резервный узел происходит автоматически. Независимо от резервных копий, WAL непрерывно архивируется в объектное хранилище, а базовые бэкапы поддерживают восстановление на определенный момент времени (point-in-time recovery).
Тестирование производительности HA в PostgresBench показало, во сколько обходятся эти гарантии. С двумя синхронными резервными копиями ClickHouse Managed Postgres обеспечил примерно в 4 раза большую пропускную способность, чем кластер Amazon RDS Multi-AZ, работающий с той же конфигурацией кворума из двух резервных копий, поэтому надежность не снижает производительность, о которой говорилось в предыдущем разделе.
Отвечая на вопрос этой статьи, отметим, что значение имеет именно то, где эти копии находятся. Они располагаются «под» базой данных, сервис управляет ими, а приложение никогда их не видит и не должно их согласовывать.
По мере роста набора данных и увеличения числа агентов, обращающихся к нему, рабочая нагрузка будет включать все больше исторических сканирований, агрегаций и сравнений, затрагивающих большие объемы данных. Хотя система оснащена быстрым NVMe-хранилищем, Postgres по-прежнему остается строчно-ориентированной транзакционной базой данных, поэтому такие запросы лучше обрабатывать в ClickHouse.
ClickHouse Managed Postgres объединяет оба движка в единый слой данных. WalShadow реплицирует определенные таблицы Postgres напрямую в ClickHouse, используя физический WAL. Эта функция в настоящее время находится в режиме частного предварительного просмотра (private preview), а задержка от фиксации до появления данных составляет около 200 мс, как показали бенчмарки ClickHouse.
Расширение pg_clickhouse позволяет получать доступ к таблицам ClickHouse через Postgres и перенаправляет поддерживаемые аналитические запросы в ClickHouse. Приложения и агенты могут сохранять подключение к Postgres, используя разные движки для транзакционной работы и для аналитических целей. Для этого необходимо настроить внешние таблицы (foreign tables) и обеспечить поддержку pushdown; автоматическая маршрутизация каждого запроса не предоставляется.
Репликация по-прежнему задействована, но аналитическая копия берет на себя общую нагрузку на уровне данных, выполняя масштабные сканирования и агрегации на базе колонночного движка. Аналитическая емкость способна масштабироваться самостоятельно, без необходимости распространять эти наборы данных по средам выполнения каждого агента.
Локальная синхронизация — отличное решение, когда приложениям требуется оффлайн-доступ, когда у них ограниченное сетевое подключение или когда они многократно читают предсказуемый рабочий набор. Для обычных приложений первым шагом является оценка того, сможет ли центральная база данных удовлетворить необходимые требования по задержке и пропускной способности, прежде чем внедрять еще одну копию данных.
AI-агенты делают это решение еще более важным: их запросы могут меняться с каждой задачей, из-за чего локальные наборы данных становится труднее определить. ClickHouse Managed Postgres создает основу для удовлетворения этих меняющихся потребностей: храните операционные операции чтения и записи в Postgres и добавляйте реплики для чтения там, где это допускают требования к актуальности данных. Когда использование приложения перерастает возможности Postgres, перенесите аналитическую нагрузку в ClickHouse.
Начните с простого вместе с ClickHouse Managed Postgres и развивайтесь вместе с ClickHouse.
