Как мы построили быстрое и надежное хранилище просмотров объявлений

[ggo]

Каков объем данных?

[antonsergeyev]

Данные одного проекта занимают около 25гб в MongoDb (из них большую часть занимает статистика по дням, на сумму просмотров приходится ~1гб). А в редисе лежит меньше 100мб на проект — это кэш и очереди вместе.

[faiwer]

А статистика минувших дней лежит на отдельном сервере\ах?

[antonsergeyev]

База пошардирована, но статистика никак не отделена от актуальных данных.
Спасает то, что при удалении объявления удаляется и его статистика; может быть в будущем удалять их не будем в целях аналитики — тогда и разделим.

[melesik]

И как счётчики 20 лет назад работали без mongodb, redis и go? Как можно всё так усложнить?

[antonsergeyev]

Сами удивляемся!

На самом деле на крупных проектах скорее всего и 20 лет назад использовали промежуточное in-memory хранилище для подобных нагрузок на запись. Не redis, так что-то другое, но принципиальная сложность вряд ли изменилась.

[Sovigod]

Просмотры и разрезом по дням/часам/минутам — это же time series. Пробывали что-то колоночное? типа clickhouse/influxdb?

[antonsergeyev]

Пробовали influxdb, но не взлетело: во-первых, мы плохо его подготовили (на каждый запрос общего числа просмотров вычисляли сумму из time series — очень медленно); во вторых, даже если готовить хорошо, все-таки более 90% запросов у нас интересуются не статистикой, а суммой просмотров, поэтому заводить ради этого отдельную бд не захотелось.
После неудачи с influxdb решили выбрать что-то из имеющихся у нас в продакшене технологий — mysql или mongodb; вторая оказалась быстрее.

[Sovigod]

Ну общий каунтер в любом случае надо бы кешировать. Просто с умным фоновым обновлением кеша.
А с приличным tsdb вы получите много приятностей для аналитики. Например уникальные просмотры(по ip или user_id, смотря что вам надо). Ну или просмотры(уники и нет) но по целым разделам, а не по отдельным объявлениям. Менеджеры такое очень любят.
Ну и гляделки приятные из коробки типа grafana с ее алертами на бизнес метрики.

И еще. в clickhouse у вас все это будет занимать намного меньше места. Был опыт переноса просмотров с mysql -> clickhouse. На больших сроках и объема почти в 100 раз меньше места потребляет clickhouse

[majesty]

Clickhouse мы пробовали на других задачах (тоже хранение событий, но уже для внутренней аналитики). Непредсказуемое поведение и ведро процессорных мощностей, которое нужно вкидывать буквально каждый месяц привели к тому, что мы его похоронили в пользу BigQuery.

[Sovigod]

У нас тоже долго жрал очень много процессора. Но оказалось надо перечитать документацию и пересоздать таблицы с правильными индексами. Работать стало быстро, а потребление упало на порядок.

[zapishiscom]

А почему запросы в основном только на чтение? Это же просмотры объявлений, значит инкремент, значит запись!

[antonsergeyev]

Большая часть запросов на чтение приходит со страниц поиска: мы выводим много объявлений в списках (читаем просмотры), но люди переходят, конечно, не по всем из них.
Ну и есть много других мест на сайте и в приложениях, где объявление отображается, но его просмотр не засчитывается.

[maximgorbatyuk]

Получается, у вас к каждому объявлению сущность с числовым счетчиком прикручен? Тогда несколько вопросов.
Почему был выбран именно такой подход? Почему бы не инсертить каждый просмотр как новую метку с двумя полями «ДатаСоздания» и «ОбъявлениеАйди», например? Тогда можно было бы и собрать более подробную статистику по дням/часам/секундам, и проблем с целостностью можно избежать. А прежние просмотры при архивации объявления удалять с базы

[antonsergeyev]

Подход time-series баз данных интересен; может быть, если понадобится более детальная статистика — будем использовать и его (в комбинации с другими, чтобы не тормозить на чтении общего числа просмотров).
А вообще причины отказа от time-series бд я описал выше

[maximgorbatyuk]

Прочел коммент по ссылке. Хм, решение довольно спорное, но если с точки зрения бизнеса статистика не нужна, да и учитывая расходы на хранение данных — вполне подходящее. Спасибо за ответ