Вопрос выбора СУБД для коммерческого приложения является крайне важным, так
как выбор СУБД повлияет на:
Изначально MySQL был очень ограничен в
функциональности. Так например MySQL
только недавно начал поддерживать вложенные запросы, триггеры, процедуры.
Основным же преимуществом MySQL была его скорость
работы. Для небольших веб-приложений в большинстве
случаев MySQL был наилучшим выбором за счет скорости
работы, простоты управления, open-source лицензии.
Для сложных критически важных систем самыми важными требованиями являются
непрерывная работа и высокая скорость обработки запросов. При этом требуется
выполнять частые бекапы, не
останавливая систему. Немаловажным фактором также является возможность масшабирования системы.
Может ли справиться MySQL с задачей построения
системы, удовлетворяющее следующим требованиям:
Скорость работы системы зависит от целого ряда факторов, а именно от
используемого хранилища данных (Engine), размера и структуры
данных, индексов, сложности запросов, аппаратного обеспечения. За счет
оптимизирования хранения данных, индексации нужных полей и оптимизации запросов
можно добиться увеличения скорости работы системы.
Начиная с версии 4.1.13 MySQL
поддерживает кластеризацию. Пока есть еще ряд существенных ограничений
на использования MySQL кластеров, но в новых версиях
постепенно снимаются эти ограничения. Кластеризация позволяет решать проблему масшабирования системы, надежности хранения данных, а также
позволяет выполнять он-лайн бекапы
данных.
Вопросы оптимизации скорости работы MySQL и
кластеризации будут освещены с следующих статьях.
В данной статье пойдет речь о репликации в MySQL.
С помощью репликации удается решать задачу высокой
доступности системы, делать бекапы, не останавливая
работу приложений, и при этом повышать надежность хранения данных.
Репликация это механизм синхронизации содержимого нескольких копий объекта.
В случае MySQL репликация представляет собой средство
для копирования всех изменений в основной базе данных (master
database) в подчиненную или несколько подчиненных баз
данных (slave databases).
В самом простом случае потребуется 1 master сервер
и 1 slave сервер. Все изменения на master сервере будут вноситься на slave
сервер. Таким образом, когда вносятся какие-либо изменения на основном сервере,
подчиненный сервер будет опрашивать основной сервер и вносить те же изменения в
собственной базе данных. В результате данных будут дублироваться на двух
серверах. Избыточность, состоящая в хранении данных на двух серверах, позволит
решить ряд вопросов и увеличть надежность системы
хранения данных:
Когда накапливаются большие объемы данных, процесс резервирования (бекапа) занимает достаточно большое время и при этом
блокирует таблицы для чтения. Таким образом в процессе
бекапа таблицы, все запросы, изменяющие данные, также
блокируются до окончания бекапа. Это приводит к
фактическому простою системы или же значительному увеличению времени отклика
системы.
Эта проблема решается с помощью репликации. Вместо блокирования таблиц в
основной базе данных, бекап будет выполняться
подчиненной базы данных. В результате в процессе бекапа
основная база данных обрабатывает запросы без задержек.
Репликация может также использоваться для масштабирования системы. В том
случае, если запросы обновления данных составляют малую часть от запросов
выборки данных, есть отличная возможность разделить запросы выборки данных по
подчиненным серверам. В результате новые данные и обновления будут вноситься на
основном сервере, в то время как выборка данных будет разделена по одному или
нескольким подчиненным серверам.
Настройка репликации в MySQL не вызывает проблем и
выполняться может как при установке системы, так и в процессе работы системы.