В рекламе Яндекса мы работаем со многими сложными сущностями, которые храним в базах данных.

Возьмем, например, рекламный баннер. Если взять всю полезную для показа информацию о баннере, то получится сложная развесистая структура, включающая в себя много простых полей вроде тайтла и картинки, а также сложных — вроде посчитанных эмбеддингов.

Данные баннера нужно постоянно обновлять — они включаются, выключаются, обновляют какие-то свои данные, по ним пересчитываются эмбеддинги. Так что у нас потоковая обработка данных с результатом в виде актуального состояния данных баннеров в таблице (в YT).

Вроде все просто, какие тут могут быть проблемы? На самом деле проблемы ожидаемые, у нас же Highload, и, если работать с нашей таблицей с баннерами наивным способом, то будем создавать слишком большую нагрузку.

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

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

Приходите, чтобы узнать новое, обсудить известное и поделиться своими идеями про работу с состояниями.