Разбиение базы данных для общего счетчика

Question

Во время проектирования хранилища данных мы изучаем способ разделения записей. Основным узким местом является разделение общих счетчиков. Допустим, у нас есть n билетов, которые будут предложены (Типовое бронирование поездов, IRCTC e.t.c). Как мы разделяем хранилище данных, чтобы клиенты видели живую согласованность между ними (с точки зрения процентного количества заказа, то есть currentvalue/x).

Агрегация для каждого считывания будет слишком дорогостоящей, любые другие указатели будут полезны.

Также предполагается, что для операции записи используется параллелизм (поэтому нет необходимости загружать чтение в подчиненные устройства), и это было бы хорошо для окончательной согласованности. Но есть ли способ, которым разница в несогласованности может быть сведена к минимуму через осколки. Например, партион из 100 билетов выполнен как 25, 25, 25, 25 через 4 осколка. В любой момент времени представление базы данных должно быть как x% заполнено и как минимизировать несогласованность (наивные операции, такие как round robin, hashing e.t.c) среди осколков.

Answer 1

Если ваш случай использования таков, что вы хотите распространять общий счетчик, чтобы лучше обрабатывать нагрузку операций чтения, вы можете сохранить общий счетчик в своем собственном экземпляре (по предложению от @ItamarHaber) и встать в очередь N подчиненных экземпляров которые реплицируются из основного экземпляра. Операции чтения с этим общим счетчиком затем могут быть сбалансированы по нагрузке среди N подчиненных устройств. Существует некоторое обсуждение настроек мастер-ведомого такелажа через конфигурационный файл here, а также эту документацию о динамическом управлении настройками ведомого с помощью команды SLAVEOF.

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