Это гостевой пост Дэниела Винтермейера, технического директора и соучредителя Clera, и инженера-основателя Джулиана Бушара. Оригинал статьи опубликован в блоге Clera here.
Система найма сломана. Кандидаты отправляют резюме в пустоту, основатели тонут в потоке ненужных им документов, а люди, которые идеально подошли бы на роль, почти никогда не встречаются. Мы решили, что должен быть лучший способ. Вы не ищете работу. Вы общаетесь с .
Мы — ИИ-агент по поиску талантов, работающий с обеих сторон рынка. Мы представляем более 200 000 кандидатов и помогаем им устроиться в компании (в основном от стадии pre-seed до Series B) в Нью-Йорке и Сан-Франциско. Прямо сейчас на платформе открыто около 2250 вакансий, и каждый день к нам присоединяется более 2000 новых кандидатов.
В основе нашей работы лежит мультиагентная система. Со стороны кандидата: вы регистрируетесь, общаетесь с нами через электронную почту, iMessage или чат-интерфейс, а агенты берут на себя всё — от первичного сбора данных и изучения ваших предпочтений до предложения и подбора подходящих вакансий. Со стороны компании: мы присутствуем в Slack-каналах основателей и представляем кандидатов напрямую, поэтому этап подачи заявок отсутствует. Мы предлагаем только те вакансии, которые подходят, и проводим настолько тщательный отбор, что около 50% наших представлений приводят к собеседованию. Поскольку мы работаем за комиссию по результатам найма, для нас важно, чтобы люди находили работу там, где они действительно хотят трудиться.
Самая важная часть системы — это данные. Каждый разговор при первичном сборе данных, каждая вакансия и каждый сигнал о том, кто подходит на какую роль, питают движок подбора, а эффективность этого движка зависит от качества данных. Оказалось, что это очень сложная задача.
На момент миграции мы использовали более 500 ГБ данных в Postgres (сейчас объем приближается к терабайту). До перехода на ClickHouse Managed Postgres мы столкнулись с огромным количеством проблем у нашего предыдущего поставщика баз данных.
Одним из самых ярких примеров был простой запрос по поиску таланта: поиск кандидата, который должен был выполняться мгновенно, занимал около трех секунд. У нас повсюду были аналитические запросы, и случались периоды, когда база данных работала на 100% загрузке процессора шесть дней подряд. Также были тайм-ауты, пропуски и сбои при записи. Если вы с этим сталкивались, то знаете, насколько это болезненно, ведь приходится повторять попытки, а база данных не должна вас подводить. В худшие моменты у нас были всплески, когда мы даже не могли обновить запись в таблице по первичному ключу.
Когда Джулиан проанализировал нашу рабочую нагрузку, он разделил её на три типа:
- «Горячие» чтения: небольшие CTE, запросы к списку вакансий и чтение материализованных представлений, которые должны быстро отображаться, когда кто-то просматривает сайт.
- Точечные запросы: мелкие операции чтения и записи по первичному ключу, которые должны выполняться за доли миллисекунды, если их ничто не блокирует.
- Фоновая работа: тяжелые аналитические CTE, которые запускает команда или которые отображаются на дашбордах, плюс обновление материализованных представлений для SEO.
Самой большой проблемой были точечные запросы. Они занимали несколько секунд, потому что блокировались фоновыми запросами. Кроме того, мы часто парсим много данных, поэтому у нас возникают резкие всплески нагрузки, которые создают дополнительное давление на IOPS, процессор и время выполнения всех остальных операций.
Мы решили, что нам нужна рабочая база Postgres, где точечные запросы остаются быстрыми, пока параллельно работают аналитика и парсинг, с хранилищем, способным выдержать нагрузку по IOPS, и под управлением специалистов. Мы не эксперты в базах данных. Нам нужно было решение, которое просто работает.
Мы начали с оценки четырех поставщиков: Supabase, Neon, PlanetScale и ClickHouse Managed Postgres. Мы не знали, что ClickHouse — это вариант, пока наши друзья из Langfuse не сказали: «Кстати, ClickHouse теперь тоже в игре. У них есть управляемый Postgres с NVMe-хранилищем. Вам стоит поговорить и с ними».
Мы протестировали поставщиков двумя способами. Во-первых, на наших собственных производственных данных, воспроизведенных под имитированной нагрузкой, соответствующей нашей реальной работе, и, во-вторых, с помощью стандартизированного бенчмарка, чтобы получить обобщенные показатели, которые публикуют другие провайдеры.
Для воспроизведения нагрузки мы загрузили около 500 ГБ производственных данных на все четыре платформы и выполнили три класса запросов, описанных выше, измеряя:
- Запросы в секунду (QPS)
- Задержку P99
- Процент ошибок
- Время получения соединения
- События ожидания (как часто происходили блокировки, которых мы хотели избежать)
Джулиан пытался прогнать всё через пулер каждого провайдера, но у всех были разные настройки, и уравнивать их не имело смысла, поэтому финальные цифры получены на прямых соединениях.
ClickHouse Managed Postgres победил почти во всем, особенно по IOPS. Разница заключалась в локальном NVMe-хранилище по сравнению с сетевыми хранилищами, которые используют большинство провайдеров, что добавляет задержку при каждом чтении и записи на диск. Только этого было достаточно, чтобы сразу исключить Supabase и Neon, оставив PlanetScale и ClickHouse.
Затем мы запустили sysbench TPC-C. По сути, это набор данных, имитирующий бизнес-процессы, со смесью запросов на чтение и запись. (Важно отметить, что sysbench не полностью соответствует стандарту TPC-C, но дает нам сравнимую базу.) Оба провайдера работали на одном классе машин с 500 ГБ сгенерированных данных. Один эксперимент включал 8, 16, 32, 64 и 128 потоков, запущенных три раза подряд, чтобы мы могли измерить как разброс между запусками, так и пропускную способность. Мы провели несколько экспериментов, снова отслеживая QPS, P99 и уровень ошибок, а в этот раз измеряя также транзакции в секунду (TPS) и вариативность.
ClickHouse Managed Postgres снова победил. Без каких-либо настроек его преимущество в пропускной способности варьировалось от 16% при 128 потоках до 42% при 16 потоках:
Важно отметить, что «из коробки» у них разные настройки PostgreSQL. Тюнинг — это часть предложения каждого провайдера, но его можно до некоторой степени корректировать вручную. Мы получили обратную связь от PlanetScale о том, как уравнять эти показатели, что мы и учли, хотя мы не могли протестировать огромные страницы (huge pages) без участия их инженерной команды.
Все находится в open-source репозитории на GitHub, включая все результаты, логи, скрипты и файлы Terraform, а также краткое описание в LaTeX и дамп контекста для ваших LLM. Пожалуйста, посмотрите, изучите, воспроизведите и напишите нам, если найдете ошибки. Если вы оцениваете базу данных любого типа, мы призываем вас провести подобное тестирование самостоятельно и сделать его открытым. Вы можете ошибиться, и тогда люди смогут вас поправить. В этом и заключается прелесть обмена знаниями в сообществе.
Был четверг, когда мы решили выбрать ClickHouse Managed Postgres. В пятницу утром Дэниел взял флэт уайт и пришел на наше ежедневное собрание в 10 утра, готовый обсудить предстоящую миграцию. Джулиан сказал: «Кстати, мы уже на ClickHouse».
В 11 вечера накануне Джулиан закончил финальную подготовительную работу. Он знал, что если мы сделаем всю подготовку и будем ждать, то продолжим откладывать. Поэтому, понимая, что это все равно придется сделать, он решил, что лучше сделать это сейчас.
Для этапа подготовки мы следовали руководству по миграции ClickHouse. На стороне источника это означало настройку времени жизни WAL, включение публикаций и предварительную проверку ключей и расширений. Расширения стали самой большой проблемой. Postgres предлагает их огромное множество, а некоторые провайдеры имеют очень специфические расширения, которые больше никуда не переносятся. Джулиан потратил несколько дней, заранее изменяя части системы, чтобы обойти это и убедиться, что мы сможем беспрепятственно мигрировать к любому провайдеру.
Он настроил два конвейера ClickPipes: один для основных данных, другой для второстепенных, чтобы сосредоточиться на основных данных и позволить обоим работать параллельно. Наша команда основателей — из Германии, и наша база данных находилась в ЕС, поэтому мы воспользовались возможностью одновременно перенести ее в США. Это более 500 таблиц, пересекающих Атлантику, в то время как на них поступал производственный трафик. В какой-то момент во время тестирования Джулиан столкнулся с проблемой из-за сочетания задержки в ЕС и объема таблиц. Кто-то из ClickHouse сделал PR для этого в 11 вечера. Такая отзывчивость была приятна и значительно облегчила переход.
Сама миграция прошла довольно легко. Сложнее было вернуть триггеры, перестроить индексы и переупорядочить таблицы. Затем были проверки на соответствие и фактический перенос, повторное развертывание всей системы с указанием на новую базу данных и проверка того, что ничего критически не сломалось. Все нужно было сделать быстро, потому что мы часто вносим изменения в схему, а вы не хотите, чтобы люди меняли старую схему, пока новая уже скопирована. К 6 или 7 утра оставалось в основном наблюдение и очистка. После ежедневного собрания в 10 утра Джулиан пошел спать.
Благодаря ClickHouse Managed Postgres все загружается намного быстрее для наших пользователей и внутренних администраторов, которые ежедневно используют наши инструменты и очень благодарны. Больше никто не боится, что кто-то из команды случайно запустит многочасовой аналитический запрос, который обрушит всю систему. Раньше такое случалось время от времени, но теперь — нет.
Не менее важно и то, что у нас появилось пространство для маневра. В настоящее время мы используем около 10–20% ресурсов процессора большую часть времени. Мы не изменили ни одной настройки с момента миграции. Производительность «из коробки» уже была настроена под наши нужды, и для нас все просто заработало. Что касается цены, то она осталась примерно на прежнем уровне, если не немного дешевле, но при этом с лучшей производительностью и масштабируемостью.
Стоит отметить, что мы мигрировали не в аналитическую базу данных ClickHouse. Мы перешли на их управляемый сервис Postgres, который по сути является стандартным Postgres, работающим на локальных NVMe-накопителях вместо сетевых дисков. Сейчас это все, что нам нужно, но если аналитическая сторона бизнеса когда-нибудь перерастет это, путь открыт. Managed Postgres может синхронизироваться с ClickHouse, когда нам это понадобится. Тем временем мы уверены, что можем нагружать систему гораздо сильнее.
В цифрах
- 500 ГБ мигрировано (сейчас ближе к 1 ТБ)
- Более 500 таблиц перенесено из ЕС в США
- 1 ночь, от финальной подготовки до переключения
- Со 100% до 10–20% загрузки ЦП
- До 42% больше TPS, чем у ближайшего конкурента в sysbench TPC-C
- 0 настроек изменено после миграции
