RabbitMQ как прокси между хранилищем данных и производителем?

Question

У меня есть код, который производит много данных, которые должны храниться в базе данных. Проблема в том, что база данных не может соответствовать полученным данным. Поэтому мне интересно, поможет ли какой-либо механизм организации очередей в этой ситуации - я думаю, в частности, о RabiitMQ и возможно ли хранить данные в своих очередях, пока какой-либо потребитель не извлечет данные из них и не отправит их в базу данных , Кроме того, мне не особенно интересно, попали ли эти данные в базу данных или нет, потому что довольно скоро эти данные будут обновлены.

Answer 1

Базы данных должны обрабатывать вставки данных очень быстро, без механизмов блокировки, поскольку вставки относятся к данным, которых еще нет в хранилище. Если вы имеете дело со вставками данных и ваша сериализация в базу данных является узким местом, то любая проблема, с которой вы столкнетесь, будет все еще существовать с RabbitMQ, потому что вставки базы данных должны работать на быстрее , чем исходящие обмен сообщениями с RabbitMQ. В этом случае RabbitMQ не решит вашу проблему. С другой стороны, обновления данных заблокируют строку обновления (в общем), и у вас могут возникнуть проблемы с параллелизмом при блокировках и ожиданиях. В общем, попытайтесь понять, почему ваша база данных является узким местом.

В конце концов, если ваше хранилище данных - NOSQL, то это может быть не производящая запись, в этом случае вы можете проанализировать, что получает данные быстрее (NoSQL против RabbitMQ).

Если у вас есть производители данных в нескольких потоках, у вас есть проблема с параллелизмом для записи в постоянное хранилище. В этом случае RAbbitMQ должен обрабатывать параллелизм лучше, чем ваше хранилище персистентности, поскольку он рассчитан на высокий уровень параллелизма. Это зависит от того, какое хранилище данных вы используете.

Answer 2

@ hyperboreean Это может показаться немного бойким, но, возможно, вам действительно нужен кеш, такой как Redis или MemcacheD ?

Технически вы могли бы использовать RabbitMQ с потребителями, обновляющими БД, но вам нужно было бы внедрить механизм «очистки очереди», иначе ваши очереди будут увеличиваться до тех пор, пока ваша скорость ввода по-прежнему превышает возможности базы данных. По мере роста очередей данные в них устаревают - это означает, что только что отправленное обновление все еще находится в очереди. Думайте об этом как о магазине, в котором есть один контролер. Конечно, вы можете формировать отдельные строки, но это просто означает, что у вас есть несколько длинных строк и все еще есть один контролер. Вы по-прежнему связаны скоростью, с которой контролер может обрабатывать ваших клиентов.

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