простота масштабирования mongodb против mysql

Question

Я создаю приложение Grails, которое является бэкэндом для мобильного приложения.В настоящее время он развернут на Amazon EC2.Он сохраняет данные в базе данных MySQL.Один экземпляр в данный момент указывает на базу данных.Я планирую развернуть несколько экземпляров приложения за балансировщиком нагрузки, и в конечном итоге запросы на чтение перейдут к подчиненным экземплярам БД.Мы планируем выпустить в ближайшие месяцы, и у нас будет бета-группа из нескольких тысяч пользователей.Это более интенсивно читать, чем писать.

Мы рассмотрели использование mongodb вместо sql и считаем его хорошим решением.

Не имея большого опыта по масштабированию mysql (или mongodb), было бы легче масштабировать mongodb, поскольку он имеет такие функции, как автоматическое разбиение.(В поисках мыслей от людей, которые сделали оба) Я думаю, что сейчас будет легче переключиться на mongodb, чем на «производство» и необходимость миграции.

Мысли?

Answer 1

MongoDB имеет две версии «масштабирования»:

1. Считывание масштаба через наборы реплик .
2. Масштабирование записи через sharding .

Они не серебряные пули, но их очень легко настроить. Наборы реплик имеют автоматическое переключение при сбое, что практически необходимо при использовании EC2 (у них хорошая история случайных неудачных узлов). Когда вам нужно масштабирование записи, MongoDB имеет документированные процессы для обновления вашего набора реплик на серию сегментированных наборов реплик.

К сожалению, есть ограничение (последнее, что я проверял), такие вещи, как scalr, на самом деле не поддерживают автоматическое масштабирование. Таким образом, вам придется развернуть свое собственное решение для добавления и удаления узлов из набора.

Некоторые важные соображения:

1. Производительность дискового ввода-вывода в облаке отрывочна. Хорошая производительность зависит от объема оперативной памяти, которую вы можете использовать для решения этой проблемы.
2. Если вы используете наборы реплик для операций чтения, убедитесь, что ваш драйвер / оболочка данных способна обрабатывать распределение операций чтения. Так же, как MySQL на данный момент не является «бесплатным», вам нужно решить «писать против чтения».
3. 64-битные машины. MongoDB действительно хочет работать на 64-битном оборудовании. Это экономически выгодно, так как вам, вероятно, придется увеличить количество машин 4 ГБ вместо 2 ГБ (я не думаю, что это большое ограничение, но я также знаю, каково это - запускаться).
4. MongoDB - все еще новая технология. Списки очень активны, и люди используют его в производстве для очень больших наборов данных. Но это все еще новый продукт, вы должны быть готовы работать из командной строки, анализировать документы и задавать вопросы.

было бы проще масштабировать mongodb

На некотором уровне масштабирование будет "сложной" проблемой. Что хорошо делает MongoDB, так это предоставляет способ действительно масштабировать множество блоков по горизонтали с репликацией. По моему опыту, MySQL действительно занимает около двух ячеек для записи. Вы можете легко настроить co-master, но после этого вы должны начать заниматься всеми видами разбиения, и вы в основном теряете возможность делать объединения.

Я думаю, что сейчас будет проще переключиться на mongodb, чем на «производство»

Это, вероятно, будет.

Мысли

Начните с малого. Получите один кусок работы и посмотрите, нравится ли вам, как он работает. Если у вас есть доступ к учетной записи EC2, то легко раскрутить пару машин и играть. MongoDB не является панацеей, но она действительно хорошо работает для многих современных веб-проблем. Просто измерьте, насколько сильно вам нужны объединения:)