Как стать автором
Обновить

Комментарии 16

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

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

База пошардирована, но статистика никак не отделена от актуальных данных.
Спасает то, что при удалении объявления удаляется и его статистика; может быть в будущем удалять их не будем в целях аналитики — тогда и разделим.
И как счётчики 20 лет назад работали без mongodb, redis и go? Как можно всё так усложнить?
Сами удивляемся!

На самом деле на крупных проектах скорее всего и 20 лет назад использовали промежуточное in-memory хранилище для подобных нагрузок на запись. Не redis, так что-то другое, но принципиальная сложность вряд ли изменилась.
Просмотры и разрезом по дням/часам/минутам — это же time series. Пробывали что-то колоночное? типа clickhouse/influxdb?
Пробовали influxdb, но не взлетело: во-первых, мы плохо его подготовили (на каждый запрос общего числа просмотров вычисляли сумму из time series — очень медленно); во вторых, даже если готовить хорошо, все-таки более 90% запросов у нас интересуются не статистикой, а суммой просмотров, поэтому заводить ради этого отдельную бд не захотелось.
После неудачи с influxdb решили выбрать что-то из имеющихся у нас в продакшене технологий — mysql или mongodb; вторая оказалась быстрее.
Ну общий каунтер в любом случае надо бы кешировать. Просто с умным фоновым обновлением кеша.
А с приличным tsdb вы получите много приятностей для аналитики. Например уникальные просмотры(по ip или user_id, смотря что вам надо). Ну или просмотры(уники и нет) но по целым разделам, а не по отдельным объявлениям. Менеджеры такое очень любят.
Ну и гляделки приятные из коробки типа grafana с ее алертами на бизнес метрики.

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

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

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

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

Большая часть запросов на чтение приходит со страниц поиска: мы выводим много объявлений в списках (читаем просмотры), но люди переходят, конечно, не по всем из них.
Ну и есть много других мест на сайте и в приложениях, где объявление отображается, но его просмотр не засчитывается.
Получается, у вас к каждому объявлению сущность с числовым счетчиком прикручен? Тогда несколько вопросов.
Почему был выбран именно такой подход? Почему бы не инсертить каждый просмотр как новую метку с двумя полями «ДатаСоздания» и «ОбъявлениеАйди», например? Тогда можно было бы и собрать более подробную статистику по дням/часам/секундам, и проблем с целостностью можно избежать. А прежние просмотры при архивации объявления удалять с базы
Подход time-series баз данных интересен; может быть, если понадобится более детальная статистика — будем использовать и его (в комбинации с другими, чтобы не тормозить на чтении общего числа просмотров).
А вообще причины отказа от time-series бд я описал выше
Прочел коммент по ссылке. Хм, решение довольно спорное, но если с точки зрения бизнеса статистика не нужна, да и учитывая расходы на хранение данных — вполне подходящее. Спасибо за ответ
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.