Comments 9
Офигенный лонгрид, спасибо
Рассматривали ли Кликхаус для хранения фич? И в целом, какие альтернативы рассматривали и отбросили?
Рассматривали разные варианты: среди них были Redis и ClickHouse. Выбрали YDB, потому что был опыт с этой СУБД в контексте масштабирования системы. Было практическое понимание, что схема рабочая.
Но на самом деле слой хранения у нас абстрагирован от СУБД. Экспериментально мы храним геофичи в Redis. При необходимости можем использовать и другие СУБД.
«Раз в сутки мы размечаем атрибуты пользователей. А дальше, в рантайме, хотим принимать решения в зависимости от того, проставлен атрибут на пользователя или нет».
Так вот почему у вас всё так через жопу, и столько жалоб...
А откуда берется 100k RPS на чтение и 30k RPS на запись?
Откуда так много?
И зачем хранить два варианта payload (String и json)?
У системы на текущий момент 130 сервисов-потребителей, все из них создают нагрузку от сотни до десятка тысяч на чтение признаков. Также система хранит сотни признаков, которые обновляются в режиме реального времени или раз в промежуток времени. Отсюда нагрузка.
В поле payload пользователь хранит данные произвольного типа. В целевом состоянии каждый признак должен быть схематизирован (его схема зафиксирована в protobuf). Таким образом мы можем валидировать данные и сохранять понимание семантики данных потребителями.
Как я понимаю, речь идет о городских сервисах Яндекса (Такси, Доставка, Еда и так далее)? Вроде бы общее число каких-то пользовательских операций (поездок, покупок) скорее около десятков в секунду, а признаки нужны при проведении каких-то пользовательских действий.
Вот я и пытаюсь понять, как 5 поездок в секунду в Яндекс.Такси (примерно) превращаются в тысячи и десятки тысяч запросов на чтение признаков.
И на схеме есть PG и Redis, какие задачи они выполняют?
Спасибо за ответы!
в PG хранятся метаданные признаков для отображения в админке, в Redis экспериментально хранятся геопризнаки (функционал не критичный и, можно сказать, отдельный). Эксперимент в целом удачный, но поддерживать работу одной СУБД сильно проще - поэтому развивать это решение не спешим.
Поскольку на авалоне часто запускают эксперименты (связанные, например с выбором водителя на заказ), то походов в сервис больше чем поездок. Так как на каждую поездку рассматривается несколько кандидатов.
Avalon: как построить эффективный Feature Store на YDB