Детализированные стратегии кэширования динамических запросов

Сегодня я хотел бы поговорить о стратегиях кэширования для совокупных запросов к часто обновляемым данным, основанным на времени. На предыдущем месте работы я провел немало «мозговых циклов» и с удовольствием поделюсь некоторыми своими находками.

https://jensrantil.github.io/posts/fast-aggregate-queries-on-dynamic-data/

#db

👉 @database_info

Компания Uber создала собственную базу данных с нуля. Она получила название Schemaless DB.
В ее рамках они хотели добиться высокой доступности операций записи.

Uber сделала это возможным благодаря использованию умной и простой техники под названием Buffered Writes.
В двух словах, Buffered Writes означает, что каждый запрос на запись хранится как минимум на двух узлах - Primary Leader и Secondary Leader.

Вот как это работает:

✅ Клиент делает запрос в обработчик запросов.

✅ Обработчик запросов отправляет запросы на запись на Secondary Leader. Данные сохраняются в специальной буферной таблице на Secondary Leader.

Затем он также отправляет запрос на запись на Primary Leader. Только если обе записи прошли успешно, клиент получает подтверждение успешной записи.

✅ Задача Primary Leader заключается в репликации данных.

Но если leader выходит из строя до успешной асинхронной репликации, Secondary Leader служит временной резервной копией данных.

✅ Background Worker следит за Primary Follower, чтобы узнать, когда появится запись после репликации

✅ Как только запись появляется на Primary Follower, Background Worker удаляет запись из Buffer Table.

Здесь следует отметить несколько важных моментов:

- Количество вторичных лидеров настраивается

- Secondary leader выбирается случайным образом

- Буферизованные записи используют идемпотентность. Если существует несколько записей с одинаковыми идентифицирующими полями, то не имеет значения, сколько раз был сделан запрос.

#db

👉 @database_info