Соотношение чтений к записям (read/write ratio)

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

➡️ На сисдиз собесе

1️⃣Влияет на выбор подходящей БД

Архитектура хранения зависит в том числе от того, будут ли в системе преобладать чтения или записи, а также от абсолютных значений нагрузки: условно 1000 RPS или 1000000 RPS.

Для систем с преобладанием чтения (read-heavy) стоит выбирать хранилище, оптимизированное для сценариев чтения (поиск, фильтрация). Например, реляционку или подходящую NoSQL БД.

Для write-heavy систем часто хорошо подходят базы данных на основе LSM-деревьев (на мой вкус про них очень хорошо написано в кабанчике), например Cassandra.

К сожалению, я не работала с Кассандрой в проде, но однажды успешно прошла собес предложив и обосновав ее использование для проектируемой системы.

Конечно, и PostgreSQL можно использовать в write-heavy сценариях, особенно если нам важны полноценные ACID-транзакции. Вопрос скорее в масштабе нагрузки и других требованиях системы.

2️⃣Для предложения кэширования или наоборот асинхронной обработки

Для read-heavy систем, если одни и те же данные читаются многократно, часто ставят кэш перед БД, чтобы снизить нагрузку на нее.

Для write-heavy кэш, конечно, не решит проблему высокой нагрузки на запись. Тут, если нужно и система позволяет, может пригодиться асинхронный подход: между приемом данных и их обработкой можно поставить очередь. Она позволит сглаживать пики нагрузки и обрабатывать записи с той скоростью, которую выдерживает downstream-система.

Конечно, если средняя скорость поступления данных постоянно выше скорости обработки, очередь проблему не решит. Обычно на сисдизах тут появляется горизонтальное масштабирование обработчиков.

3️⃣Для обсуждения репликации

Для read-heavy систем может использоваться подход, когда запись производится на мастер (лидер), а часть чтений уходит на реплики.

Для write-heavy систем репликация тоже нужна, в первую очередь для отказоустойчивости (если лидер вышел из строя, переключились на реплику).

➡️ В жизни

На практике мы не часто сталкиваемся с построением с нуля большой системы с выбором всех технологий. Тем не менее оценка соотношения чтений и записей может пригодиться и для локальных доработок.

Например, когда проектируем новую фичу, требующую новых таблиц в БД:

Если будет heavy-read, то можно сразу задуматься об индексах. По каким полям будет частый поиск? Фильтрация? Сортировка?

Если будет heavy-write, то наоборот не стоит перегружать таблицу индексами, чтобы не замедлять запись.

Если нагрузка высокая, и данные при записи сильно отличаются от того, что нам удобно для чтения, можно поддерживать отдельную read-модель: сохранять исходные данные в одной таблице, а асинхронно наполнять другую, оптимизированную под конкретные запросы. Я на практике встречала такой подход.

А что преобладает в вашей части продукта?

🦆 - чтения
🐼 - записи
🦄 - в разных частях по-разному