Дизайн системы: стратегии работы с большими объемами операций записи в БД

Я бы сказал, что решение будет сильно зависеть от того, что именно вам нужно сделать. Решение для записи тысяч записей в секунду может сильно отличаться от увеличения счетчика в приведенном вами примере. Более того, tables вообще не могло быть такой нагрузки. В вашем вопросе также отсутствуют требования Consistency/availability, и в зависимости от них вся архитектура может сильно отличаться.

В любом случае, вернемся к вашему конкретному упрощенному случаю и вашим вариантам.

Вариант 1 (репликация Master-Slave)

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

Вариант 2 (шардинг БД)

Ваше предположение верно, мало чем отличается от п.1

Вариант 3 (пакетные обновления)

Очень близко. Уровень кэширования, предоставляемый облегченным хранилищем, обеспечивающим одновременное атомарное увеличение/уменьшение с постоянством, чтобы не потерять ваши данные. Мы использовали redis для аналогичной цели, хотя любая другая база данных "ключ-значение" подойдет как ну - вокруг буквально десятки таких баз данных.

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

Решение будет выглядеть следующим образом:

incoming requests → your backend server -> kv_storage (atomic increment(product_id))

И у вас будет запущен скрипт "промывки", то есть */5, который делает следующее (упрощенно):

1. для каждого product_id в kv_storage читать текущее value
2. обновить счетчик БД (+= value)
3. уменьшить value в kv_storage

Дальнейшее масштабирование

• в случае сбоя скрипта ничего страшного не произойдет - обновления поступят при следующем запуске
• если ваши серверные блоки не справляются с нагрузкой - вы можете легко добавить больше блоков
• если один ключ-значение db не может справиться с нагрузкой - большинство из них поддерживают масштабирование по нескольким полям, или простая стратегия сегментирования в ваших внутренних сценариях будет работать нормально
• если один сценарий «промывки» не поспевает за приращениями — вы можете масштабировать их до нескольких полей и решать, какие диапазоны ключей обрабатываются каждым из них.

Вы задали типичный вопрос CQRS. «CQRS» означает разделение ответственности за запросы команд. Это то, на что это похоже - вы отделяете свои записи (команды) от своих чтений (запросов). Этот подход решает проблемы, когда у вас разные потребности между записью и чтением - именно ваша ситуация.

Чтобы добиться этого масштабируемым образом, вам необходимо подтвердить (т. е. принять) запрос на увеличение и поставить его в очередь для обработки. И пусть чтение работает в режиме реального времени для каждого запроса. Обработайте запросы в очереди с помощью фонового обработчика команд, который знает как согласовать. т. е. в случае сбоя он должен знать, как разрешить конфликт (например, если кто-то другой обновил строку, получить более новую версию и повторить попытку).

Я полностью не согласен с другим ответом, в котором кто-то предположил, что очередь приведет к выходу из строя всей вашей системы. Постановка в очередь ничего не сбивает, потому что это очередь, а не обработка в реальном времени. В этом суть масштабирования. Наоборот, внесение изменений в режиме реального времени, даже если это означает просто изменение логического флага в кэше в памяти, намного хуже, чем очередность. Просто подумайте, что произойдет, если в этот момент кеш в памяти выйдет из строя. Асинхронная автономная (фоновая) обработка гарантирует, что такие проблемы не помешают в конечном итоге обработать команду. Однако может потребоваться либо медленная обработка команд в очереди (в зависимости от того, с какой скоростью они могут работать, не влияя на чтение), либо в отдельной копии данных.

Вы могли бы использовать определенную технологию, такую ​​как кеш в памяти, как предлагали другие, но это опять же еще одна реализация парадигмы CQRS. Это может быть кеш или просто еще одна копия записи или базы данных. То же самое и тот же эффект.