@hyperboreean Это может показаться немного проблематичным, но, возможно, вам действительно нужен кеш, такой как Redis или MemcacheD?
Технически вы можете использовать RabbitMQ с потребителями, обновляющими БД, но вам нужно будет реализовать механизм очистки очереди, или ваши очереди будут расти все больше, пока ваш уровень ввода еще превышает то, что может обрабатывать база данных. По мере роста очередей данные в них становятся устаревшими - это означает, что обновление, которое только что было отправлено, все еще находится в очереди. Подумайте об этом, как о магазине, в котором есть одна проверка. Конечно, вы можете создавать отдельные строки, но это означает, что у вас есть несколько длинных строк и все еще есть одна проверка. Вы по-прежнему связаны тем, что контролер может обрабатывать ваших клиентов.
Из всего слишком краткого описания кажется, что ваши данные являются действительно временными данными, и система кэширования (или другое расположение, отличное от NoSQL) может быть лучше подходит. Если вам нужно в дальнейшем сохранить данные, у вас может быть отдельный процесс, который вытаскивает текущие данные из механизма кеша и загружает его в вашу БД. Тогда вы будете ограничены тем, сколько времени потребовалось, чтобы извлечь его из-за того, как часто вы можете фактически загружать данные в БД.