Я хочу создать базу данных MySQL, которую легко масштабировать. Традиционное масштабирование вне облака означает (1) обновление оборудования, (2) сегментирование или (3) репликацию.
Вариант 1 прост, но ограничен. Вариант 2 (я слышал) очень сложный, и я не хочу тратить ограниченные силы на обслуживание / администрирование. Вариант 3 кажется подходящим только для случаев с высокой скоростью чтения и низкой записью, что не подходит для моего варианта использования, а также есть проблемы с согласованностью.
Я подумываю о создании частного облака OpenStack и развертывании виртуальной машины, на которой размещена база данных. Было бы легко масштабировать по вертикали (просто назначьте больше vCPU, vRAM, HDD), и я могу добавить больше физических узлов в облако по мере необходимости. Тогда у меня был бы только один огромный экземпляр MySQL в облаке.
Мои вопросы:
1) Имеет ли это практический смысл? Я не возражаю против небольших накладных расходов (я бы предпочел потратить больше на оборудование, чем на обслуживание / администрирование), но если накладные расходы слишком велики, это может не иметь смысла.
2) Насколько масштабируемым будет это решение? Могу ли я просто продолжать добавлять физические узлы в облако и увеличивать масштаб виртуальных ЦП, vRAM до сколь угодно больших объемов?
Приложение не очень требовательно к задержкам. Мне просто нужно простое в масштабировании решение.
В зависимости от ваших требований к безопасности и подключению вы можете выбрать управляемое решение или DBaaS в облаке.
Amazon, конечно же, предлагает свои RDS http://aws.amazon.com/rds/. Это действительно наведи и щелкни, и они будут управлять кластеризацией, оборудованием и обслуживанием за вас. Это несколько центов в час, и если вы можете выбрать вариант с высокой устойчивостью в нескольких зонах доступности за вдвое дороже.
Rackspace сделайте это тоже (это ссылка на облако Великобритании) и многие другие.
Извините, если это не для вас, а хостинг на вашем собственном сервере, или, что еще хуже, создание частного облака с нуля может не стоить ваших денег или ваших усилий.
Нет, «облако» не может волшебным образом добавить больше физических узлов к одной виртуальной машине.
Виртуализация - это технология разделения одной реальной аппаратной машины на несколько виртуальных машин. «Облачная» установка - это просто архитектура администрирования, которая позволяет вам без особых усилий управлять несколькими виртуальными машинами на нескольких реальных машинах. Но, в конце концов, каждая виртуальная машина работает на единственной реальной машине.
Совершенно другая установка, которая (немного) ближе к тому, что вы хотите, - это кластер. Это набор машин, на которых запущено некоторое программное обеспечение, предназначенное для работы на всем наборе машин, используя ресурсы (ЦП, ОЗУ, хранилище) со всех из них. В некотором смысле кластер становится единой машиной. Но эта «большая машина» - это не то же самое, что обычный сервер, а просто больше; это совершенно другое, и любое приложение должно быть спроектировано с самого начала для работы в кластере.
Есть установка «MySQL Cluster», но это не то, что вы можете себе представить, поскольку он хранит все в ОЗУ. Это действительно быстро и масштабируемо, но очень дорогой и сложный в управлении.
Поскольку вы говорите, что «приложение не очень требовательно к задержке», я полагаю, когда вы говорите «легко масштабировать», вы имеете в виду большой объем хранилища. В настоящее время нетрудно добавить пару сотен терабайт на одну машину, поэтому простое масштабирование на самом деле может быть простым и (относительно) дешевым способом.
Настоящая проблема состоит не в том, чтобы соединить все оборудование вместе, а в его реальном использовании. MySQL, безусловно, можно настроить для этого, но блокировка всей таблицы для таблиц MyISAM была бы катастрофой. Даже InnoDB сталкивается с настоящими проблемами и длительным временем обработки. В этом пространстве PostgreSQL получает Больше и Больше варианты использования, поэтому, если вы не застряли в MySQL, это реальный вариант, который стоит рассмотреть.
более того, есть совершенно другой сценарий, либо с использованием архитектуры ячеек (что можно рассматривать как крайний случай сегментирования), либо с некоторыми решениями NoSQL, такими как Hadoop или Riak