antonsergeyev Dec 11 2018 at 08:01

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

11 min

8.5K

Kolesa Group corporate blogSystem Analysis and Design*Microservices*Programming*Data storage*

+23

Comments 16

ggo Dec 11 2018 at 09:23

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

antonsergeyev Dec 11 2018 at 11:23

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

faiwer Dec 11 2018 at 15:54

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

antonsergeyev Dec 11 2018 at 18:31

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

melesik Dec 11 2018 at 11:15

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

antonsergeyev Dec 11 2018 at 11:27

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

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

Sovigod Dec 11 2018 at 11:38

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

antonsergeyev Dec 11 2018 at 18:21

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

Sovigod Dec 11 2018 at 19:46

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

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

majesty Dec 13 2018 at 11:13

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

Sovigod Dec 13 2018 at 15:17

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

zapishiscom Dec 11 2018 at 15:25

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

antonsergeyev Dec 11 2018 at 18:17

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

maximgorbatyuk Dec 11 2018 at 17:33

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

antonsergeyev Dec 11 2018 at 18:24

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

maximgorbatyuk Dec 11 2018 at 18:34

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