Масштабирование MySQL Database
Осторожно. Windows XP требует полной лицензии на каждый экземпляр, если Вы не используете VECD, который только применим для сотрудников или подрядчиков, работающих непосредственно на Вас.
Windows Server, лицензирующий, предоставляет дополнительные лицензии, но ТОЛЬКО для выпусков Сервера. Выпуски низкого уровня включены так, чтобы лицензия Windows Server 2008 включала Сервер 2003 и 2008, но клиентская операционная система НЕ включена. Это - неприятность, я знаю.
- Стандарт = 1 дополнительная лицензия виртуального сервера на том же сервере
- Предприятие = 4
- Центр обработки данных = неограниченный
Но не клиентские Ose.
Три самых популярных метода масштабирования являются репликацией "главный-подчиненный", разделением и sharding. Репликация "главный-подчиненный" является только эффективной, когда Вы хотите масштабировать чтения. Это не предназначается для масштабирования размера DB или записей. Разделение является методом хранения большой таблицы в нескольких физических местоположениях (на нескольких жестких дисках). Sharding можно рассмотреть как делящий на глобальном уровне, выполненном приложением, не сервером MySQL. В основном sharding является методом того, чтобы хранить подобные данные через несколько не непосредственно связанные базы данных MySQL. Сначала два метода поддерживаются MySQL внутренне, sharding должен быть выполнен на прикладном уровне разработчиками приложений. Похоже, что необходимо использовать sharding, так как разделение не может распространиться через несколько серверов и имеет определенные ограничения затем.
Кластеризация обычно используется в качестве решения производительности, однако моей интерпретации того, что Вы записали, то, что это - размер базы данных, которая является проблемой?
Используя NoSQL база данных обычно делается по причинам производительности (репликация MySQL проста настроить - таким образом, нет большого различия в терминах availabiltiy), Но Вы освобождаете на ОГРОМНОЙ сумме функциональности. Hadoop не собирается решать Ваши проблемы объема данных и может подразумевать, что у Вас есть МНОГО кода для перезаписи.
Как Вы справляетесь, объемы данных весьма зависит от природы приложения и данных - можно ли удалить старые данные? Можно ли переместить его офлайн? Можно ли консолидировать старые данные?
Идеальное решение для нас - когда жесткий диск достигнет своего предела, мы просто добавим другой жесткий диск на машине затем, MySQL распознает его как один
В то время как можно просто добавить диск как RAID 0 или массив JBOD, это - очень грязная практика - Вы идете от единой точки отказа до нескольких точек отказа.
Так же можно смонтировать диск и переместить отдельные файлы таблицы по (использующий символьные ссылки от исходных местоположений), но это предполагает, что Вы не выполняете однофайловый innodb бэкенд. Это настолько же плохо как использует RAID-0/JBOD.
Для транзакционного DBMS, зеркально отражая (RAID-1) предлагает значительные выигрыши в производительности - но не увеличивает тома. Таким образом, я рекомендовал бы планировать переход в устройстве хранения данных от 1 до 4 дисков (настроенный как зеркальная пара наборов полосы).