.NET: очередь сообщений и прямая вставка в MongoDB - PullRequest
Новая
       14

.NET: очередь сообщений и прямая вставка в MongoDB

4 голосов
/ 03 апреля 2012

У меня есть следующий вариант использования: веб-приложение (на самом деле браузер клиента) периодически отправляет трекинг / пинг на веб-сервер (через XHR, JSON). Я храню эти треки в коллекции MongoDB с индексом четырех свойств. Очевидно, что эта коллекция будет расти очень быстро.

Я имею в виду три варианта:

  1. Просто обработайте сообщение JSON и вставьте в MongoDB.

  2. Получить JSON-сообщение и порождение фоновой задачи для вставки в MongoDB

  3. Обработать сообщение JSON и поместить сообщение в очередь (RabbitMQ ?!) и затем позволить потребителю очереди вставить в MongoDB.

Какой из них лучше всего подойдет в случае большого использования в Интернете? Я думаю, что 2-3) будет иметь серьезные накладные расходы и, следовательно, будет медленнее в режиме разработки, но я не могу предсказать, если 2-3) действительно будет масштабироваться лучше. Поскольку будет много строк и имеется огромный индекс, я бы сказал, что вставка в коллекцию MOngoDB будет довольно медленной, если будет достигнут определенный предел.

Справочная информация: не важно, чтобы обработка каждого сообщения / отслеживания была гарантирована, и если сервер выходит из строя, он в порядке, если данные потеряны.

Ответы [ 2 ]

2 голосов
/ 06 мая 2012

С моей точки зрения, если ваше приложение будет страдать от очень высоких накладных расходов и нужно будет масштабировать, я бы пошел на вариант № 3, который имеет следующие преимущества:

  1. Поскольку это асинхронный подход, производительность будет лучше.
  2. Является более зрелым и продвинутым решением, которое позволяет масштабировать (облегчает построение распределенных архитектур)
  3. Более подходит для поддержки служебных данных (учтите, что RabbitMQ написан на Erlang, одной из сильных сторон которого является параллелизм). Смотри http://en.wikipedia.org/wiki/Erlang_(programming_language)
  4. RabbitMQ - проверенный исполнитель, допускающий недлительные очереди. Это означает, что сообщения не сохраняются и теряются при остановке сервера.

Конечно, этот подход усложняет разработку, поскольку требуется больший контроль (обработка ошибок и т. Д.)

2 голосов
/ 03 апреля 2012

Мое мнение - иди с # 1. Синглтон-вставки в MongoDB чрезвычайно быстры. Нет необходимости в очереди или внутреннем процессе. Кроме того, из-за отсутствия строгой сохранности данных, если ваша MongoDB находится в наборе реплик, вы также можете подключиться без включенного SafeMode, чтобы минимизировать накладные расходы.

Некоторое справочное чтение - ребята из Boxed Ice даже заменили свою реализацию RabbitMQ на MongoDB.

...