в PG хранятся метаданные признаков для отображения в админке, в Redis экспериментально хранятся геопризнаки (функционал не критичный и, можно сказать, отдельный). Эксперимент в целом удачный, но поддерживать работу одной СУБД сильно проще - поэтому развивать это решение не спешим.
Поскольку на авалоне часто запускают эксперименты (связанные, например с выбором водителя на заказ), то походов в сервис больше чем поездок. Так как на каждую поездку рассматривается несколько кандидатов.
У системы на текущий момент 130 сервисов-потребителей, все из них создают нагрузку от сотни до десятка тысяч на чтение признаков. Также система хранит сотни признаков, которые обновляются в режиме реального времени или раз в промежуток времени. Отсюда нагрузка.
В поле payload пользователь хранит данные произвольного типа. В целевом состоянии каждый признак должен быть схематизирован (его схема зафиксирована в protobuf). Таким образом мы можем валидировать данные и сохранять понимание семантики данных потребителями.
Рассматривали разные варианты: среди них были Redis и ClickHouse. Выбрали YDB, потому что был опыт с этой СУБД в контексте масштабирования системы. Было практическое понимание, что схема рабочая.
Но на самом деле слой хранения у нас абстрагирован от СУБД. Экспериментально мы храним геофичи в Redis. При необходимости можем использовать и другие СУБД.
в PG хранятся метаданные признаков для отображения в админке, в Redis экспериментально хранятся геопризнаки (функционал не критичный и, можно сказать, отдельный). Эксперимент в целом удачный, но поддерживать работу одной СУБД сильно проще - поэтому развивать это решение не спешим.
Поскольку на авалоне часто запускают эксперименты (связанные, например с выбором водителя на заказ), то походов в сервис больше чем поездок. Так как на каждую поездку рассматривается несколько кандидатов.
У системы на текущий момент 130 сервисов-потребителей, все из них создают нагрузку от сотни до десятка тысяч на чтение признаков. Также система хранит сотни признаков, которые обновляются в режиме реального времени или раз в промежуток времени. Отсюда нагрузка.
В поле payload пользователь хранит данные произвольного типа. В целевом состоянии каждый признак должен быть схематизирован (его схема зафиксирована в protobuf). Таким образом мы можем валидировать данные и сохранять понимание семантики данных потребителями.
Рассматривали разные варианты: среди них были Redis и ClickHouse. Выбрали YDB, потому что был опыт с этой СУБД в контексте масштабирования системы. Было практическое понимание, что схема рабочая.
Но на самом деле слой хранения у нас абстрагирован от СУБД. Экспериментально мы храним геофичи в Redis. При необходимости можем использовать и другие СУБД.
спасибо