movit26 мар в 07:01

Миллиард записей и 8 Марта: как YDB спас праздник

15 мин

12K

Блог компании ЯндексБлог компании YDBВысоконагруженные системы * Распределённые системы * Базы данных *

✏️ Технотекст 8

+74

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

bighorik 26 мар в 07:10

Поймал вас за накруткой, коллега ¯\_(ツ)_/¯

grigoryvp 26 мар в 07:14

Я больше скажу, уже +9! 😜

Boomburum 26 мар в 08:16

Я посмотрел и там ноу криминал — два голоса с весом +3 (один из них наш, модераторский) и один от обычного пользователя с весом +1 :)

TyVik 27 мар в 05:13

А быстро у вас модераторы читают!

grigoryvp 27 мар в 10:27

Да у них наверняка собственная админка и лента. Я со своим RSS в Feedly за ними не успеваю 😳

Boomburum 27 мар в 12:34

В первую очередь проверяется оформление, вёрстка :) которые в корп.блогах в целом довольно на высоком уровне.

gmelikov 26 мар в 15:38

О, зацепил подход про keyframe, как бы его лаконичнее объяснять только не придумал :) И использование updated_at тоже интересно, по нему оч удобно в итоге даже иногда диффы строить при распространении данных на минималках.

vcKomm 27 мар в 05:51

А почему не использовать updated_at вместо generation?

movit 27 мар в 06:31

updated_at изменяется каждый раз при изменении записи любым из сервисов, который её обрабатывает.

Нужно отдельное поле, которое вправе менять только первый сервис в цепочке поставки данных. Для цен такой сервис — интеграции, для категорий товаров — админка категорий.

Только в таком случае интеграции могут быть уверены, что после того как они отдали очередную пачку записей, generated_at обновилось только у этих записей. updated_at у записей, которых не было в новом поколении, мог быть обновлён изменениями других сервисов, про которые интеграции даже не знают.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий