RDS, скалер с EC2 или xeround для базы данных 40 ГБ
В настоящее время мы готовимся к переносу веб-сайта с достаточно высоким трафиком в облако.
Мы думаем об использовании scalr, чтобы помочь нам управлять всей установкой, тем более что у нас нет опыта работы с amazon.
Мы не уверены в том, следует ли нам использовать функциональность Scalr MySQL, которая опирается на поддерживаемые EBS экземпляры EC2, или нам следует использовать RDS или даже xeround и пользоваться гораздо более простым обслуживанием и управлением.
Наш набор данных составляет около 40 ГБ, и мы используем пропускную способность 4000 ГБ в месяц между сервером приложений и сервером базы данных.
любой опыт на подобных установках?
заранее спасибо
2 ответа
Я могу сказать вам по моему опыту с большим БД... но гораздо больше, чем ваш около 90 гигов.
Мы использовали RDS, и по крайней мере 3-4 раза в день у нас возникали ужасные задержки при запросах. Подобные запросы, которые занимают секунду, будут продолжаться в течение 10-20 секунд. Мы перешли к их крупнейшей инстанции с рейдовым EBS, и производительность была примерно такой же, но мы не достигли тех действительно плохих всплесков задержки.
Переход в облако действительно очень хороший вариант. Самое сложное в масштабировании вашего облачного приложения - это масштабирование базы данных. Не смущайтесь, MySQL предлагает решения для восстановления после сбоев (сколько времени это занимает…), которые могут поддерживать несколько реплик для обработки операций чтения. Scalr и RDS являются очень подходящими вариантами, если вы знаете, каковы ограничения... С Scalr - они будут масштабировать вашу БД, предоставляя ведомые, ведущие и настраивая репликацию базы данных. Хотя автоматическая инициализация облегчает, а репликация действительно дает некоторые исправления, имейте в виду, что добавление репликаций чтения не исправит записи OLTP… и не будет обрабатывать истинную линейную эластичность по требованию. Каждый раз, когда вы добавляете реплику чтения, это, скорее всего, событие службы.
Для HA Scalr использует EBS. Если последний период простоя AWS EBS имеет какое-либо указание..., убедитесь, что ваши данные / хранилище также HA...
Масштабируемое решение должно быть линейным и эластичным (масштабировать, увеличивать, уменьшать) по требованию без каких-либо простоев. Облачным приложениям необходим собственный настоящий HA - несколько реплик, выполняющих чтение и запись все время, а не аварийное переключение. RDS докажет ту же "предварительно сконфигурированную настройку MySQL" и, следовательно, будет иметь те же ограничения. И последнее, но не менее важное: убедитесь, что нет единой точки отказа и каково влияние на ваших разработчиков... каждый раз, когда вы вносите изменения в приложение. В Xeround нашей целью дизайна было решение этих проблем. Наши гены и решения класса Telco, разработанные с самого первого дня как виртуальные для облачных операций, позволяют нам предлагать гибкую, масштабируемую и высокодоступную облачную БД по запросу.
Мы провели годичную бета-версию с тысячами пользователей, многие из которых точно такие же, как вы.
Сейчас мы работаем в GA - войдите в систему, чтобы получить 30 бесплатных пробных версий (кредитная карта не требуется), и убедитесь сами.
Рази Шарир (Xeround).