Какую задержку можно ожидать при использовании MongoHQ с внешнего веб-сервера - PullRequest
4 голосов
/ 22 февраля 2011

Кто-нибудь может посоветовать использовать хост-решение БД, в частности MongoDB, с веб-сервером. В частности:

Является ли задержка приемлемой? Как разместить (географически через Azure и т. Д.) Веб-сервер с размещенным сервером БД, чтобы уменьшить задержку? Есть ли способ уменьшить стоимость полосы пропускания от совершения звонка с веб-сервера на хост-сервер БД (через частный IP или другой?) Существуют ли решения для веб-хостинга, которые предлагают пакет (хостинг приложений и размещенная БД)

1 Ответ

3 голосов
/ 22 февраля 2011

Я только что посмотрел на MongoHQ - не вижу способа указать конкретный центр обработки данных. Даже если бы вы могли (возможно, я упустил эту деталь), это регионы AWS, которые не находятся в тех же центрах обработки данных, что и Windows Azure. Вам нужно сделать предположение о том, какой регион AWS ближе всего, скажем, к северо-центральному центру обработки данных Windows Azure.

Если вы хотите уменьшить пропускную способность / задержку, вы можете разместить MongoDB в рабочей роли или даже в веб-роли, где размещается ваш веб-сайт, что уменьшит ежемесячную стоимость экземпляра. Просто помните, что если вы размещаете в Windows Azure, вам нужно быть готовым к масштабированию, поэтому автономных баз данных MongoDB будет недостаточно. Что ж, вы могли бы поместить MongoDB в свою собственную рабочую роль, сохранить свою базу данных на облачном диске (в хранилище больших двоичных объектов) для обеспечения надежности и убедиться, что вы никогда не увеличивали число экземпляров выше 1. Когда работает только один экземпляр, у вас могут быть периодические перебои в работе, когда рабочая роль перезагружается для установки исправления безопасности или происходит сбой основного оборудования (резервное копирование будет выполнено в очень короткое время, но у вас будет периодические периоды автономной работы базы данных).

Я [продемонстрировал использование репликационных наборов MongoDB] [1] на конференции MongoSV. Единственная проблема заключается в том, что для этого вам потребуется 3 экземпляра. Если вы обычно запускаете 3 экземпляра своей веб-роли, вы можете использовать их в качестве контекста. В противном случае вам потребуется управлять этой конфигурацией в отдельном наборе рабочих ролей. По сравнению с MongoHQ ваши ежемесячные расходы будут расти (но ваша пропускная способность не будет взиматься между вашей веб-ролью и MongoDB, у вас будет очень низкая задержка, и вы легко сможете масштабировать свою базу данных до 1 ТБ, увеличивая за пределами MongoHQ 2 ГБ.

Еще одна вещь: если у вас есть несколько веб-сайтов, использующих MongoDB, вы можете создать одну размещенную службу MongoDB в Windows Azure (как описано выше), а затем получить к ней доступ из всех развертываний вашего веб-сайта. Это обеспечит экономию за счет масштаба, уменьшая затраты при переходе на многопользовательскую базу данных MongoDB.

РЕДАКТИРОВАТЬ 6/16/2013 Это очень старый, устаревший ответ. Несколько обновлений:

  • Как MongoHQ, так и MongoLab предлагают размещенный MongoDB. MongoHQ предлагает как бесплатные (512 МБ), так и совместно оплачиваемые предложения в центре обработки данных в восточной части США. MongoLab предлагает бесплатные (500 МБ и совместно оплачиваемые предложения в дата-центрах Восточной и Западной США.
  • Виртуальные машины Windows Azure в настоящее время находятся в производстве, что позволяет легко развертывать выделенные автономные или репликационные развертывания в любом центре обработки данных (а также настраивать ACL для безопасности конечных точек).

РЕДАКТИРОВАТЬ 7/15/2013 В настоящее время MongoLab предлагает набор реплик объемом 8 ГБ. Я написал об этом здесь , который также имеет ссылку на пост MongoLab .

...