Сервер MySql с интенсивным вводом-выводом на Amazon AWS

Чтобы получить максимальную производительность от облачного решения, вам необходимо создать архитектуру облака. Если вас беспокоит, сколько операций ввода-вывода в секунду вы можете получить от службы, которая полностью масштабируется (как вверх, так и вниз), вы думаете о виртуальных машинах, а не об облачных вычислениях. Что касается количества доступных операций ввода-вывода в секунду, я думаю эта статья на EBS объясняет вопросы, которые следует учитывать

Проблемы:

• Два сервера, которые вы указали выше, абсолютно идентичны.
• Вы говорите о FusionIO, но вы также говорите о запуске MySQL и Apache на одном компьютере.
• Вы не упоминаете, файлы Apache или база данных MySQL (или ее части, такие как ib_logfile) будет на дисках FusionIO.

Заблуждение:

Не всегда верно, что «реальное оборудование всегда будет быстрее виртуальных машин». Правда, что на том же оборудовании то же приложение будет работать лучше не быть в виртуальной машине, но так как у вас нет доступа к оборудованию Amazon, что сравнение является спорным.

Суть облака заключается в том, что оно масштабируется по горизонтали, поэтому, если вы можете обслуживать 100 одновременных посетителей на одном сервере, вы можете обслуживать 1000 одновременных посетителей с 10 серверами, и каждый посетитель получает одинаковую скорость ответа, независимо от того, сколько их у вас есть. .

Облако:

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

1. Вы можете очень быстро вращать экземпляры вверх и вниз. Если ваш трафик очень взрывной (скажем, вы запускаете веб-сайт по продаже билетов), тогда вы можете очень легко клонировать свой веб-уровень, уровень базы данных и / или уровень хранилища на сотни виртуальных машин за час до того, как билеты Джастина Бибера поступят в продажу, и отключите их все за час после сэкономить на деньгах. Решения на основе оборудования обычно занимают недели для увеличения вашей емкости, и они продолжают стоить денег, когда они не используются полностью.
2. Первоначальная стоимость может быть намного ниже. Упомянутое вами оборудование, вероятно, стоит десятки тысяч долларов в дополнение к другим вашим расходам на хостинг. Мой сервер Amazon обходится мне примерно в 15 долларов в месяц, и все же я мог легко масштабировать его до гораздо более мощной виртуальной машины и масштабировать до десятков экземпляров с балансировкой нагрузки с уведомлением за несколько часов.
3. Они делают за вас большую часть работы. У Amazon есть и другие сервисы, такие как DynamoDB, которые автоматически масштабируются в соответствии с требованиями рабочей нагрузки или хранилища, которые вы им предоставляете. Они работают на твердотельных накопителях для повышения скорости и реплицируются в нескольких местах, обеспечивая избыточность и доступность.

Тем не менее, ваше приложение должно иметь возможность масштабирования по горизонтали. Вы не можете просто бросить его в облако и ожидать, что он будет масштабироваться вечно. Например, у сеансов PHP по умолчанию есть две проблемы:

1. Они хранятся на локальном диске, что означает, что вам нужно либо использовать липкие сеансы, либо общий диск, который будет узким местом.
2. Они открываются flock() что является исключительной блокирующей блокировкой файла. Только один процесс PHP может использовать файл сеанса одновременно. Это может стать серьезной проблемой, когда вы начинаете запускать множество вызовов AJAX.

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

Если вы используете распределенную базу данных (которой являются службы баз данных Amazon), ваше приложение также должно иметь возможность справляться с компромиссами, присущими ШАПКА теорема. Это означает, что вы можете получить два из трех аспектов: согласованность, доступность, допуск на разделы. Вам нужно будет знать, какого из трех у вас нет, и ваше приложение компенсирует это.

Если ваше приложение подходит для оборудования, выбирайте оборудование. Если это подходит для облака, выбирайте облако.

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

Еще один момент, о котором не упоминалось, - это возможность масштабирования емкости базы данных в будущем. Требования к оборудованию не статичны, они будут меняться со временем по мере роста приложения. @rhossi, вы должны учитывать для каждого из вариантов оборудования свой путь к масштабируемости в будущем. Вкратце: (1) Для масштабирования Amazon EC2 вы можете перейти на более крупный экземпляр [легко], для горизонтального масштабирования вам необходимо установить MySQL на дополнительных экземплярах и определить кластеризацию между ними [жесткая, а также неоптимальная производительность сети если вы не запрашиваете специальные экземпляры кластера]. (2) Для Amazon RDS, чтобы масштабировать, то же самое [просто], чтобы масштабировать, добавьте больше экземпляров RDS и определите кластеризацию [жестко]. (3) Что-то еще - вы можете заглянуть в Xeround's облачная база данных решение на EC2, которое имеет автоматическое масштабирование и не требует кластеризации, однако я думаю, что оно ограничено по объему хранения, поэтому может не подходить. Могут быть дополнительные параметры, предлагающие автоматическое масштабирование, и я думаю, что было бы хорошо изучить их. (4) Реальное оборудование - для масштабирования требуется ручное обновление оборудования [небольшие хлопоты + предоплата], для горизонтального масштабирования требуется больше машин и ручное определение кластеризации [средне-сложное], но этого будет легче достичь, чем в облаке, потому что IP-адреса статичность и лучшая сетевая производительность. HTH