Горизонтальное масштабирование. Проблемы и пути решения

 АЛЕКСАНДР КАЛЕНДАРЕВ, РБК Медиа, программист, akalend@mail.ru

Горизонтальное масштабирование
Проблемы и пути решения

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

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

Уточним терминологию:

• Производительность (performance) – способность приложения отвечать таким требованиям, как максимальное время реакции, пропускная способность.
• Пропускная способность (capacity) – максимальная возможность приложения пропустить через себя определенное количество запросов в единицу времени или держать определенное число пользовательских сессий.
• Масштабируемость (scalability) – это характеристика приложения, показывающая его способность сохранять производительность при увеличении пропускной способности. В свою очередь, масштабирование – это процесс обеспечения роста системы. Масштабирование может быть вертикальным или горизонтальным.
• Вертикальное масштабирование – это увеличение производительности за счет наращивания мощности железа, объема оперативной памяти и т.д. Рано или поздно вертикальное масштабирование упрется в верхний предел.
• Горизонтальное масштабирование – это увеличение производительности за счет разделения данных на множество серверов.

Функциональное разделение данных

Существует несколько вариантов горизонтального масштабирования. Например, очень часто используется разделение данных по функциональному признаку использования. Например, данные для фотоальбомов содержатся на одной группе серверов, данные профилей пользователей расположены в другой группе, а переписка пользователей – на третьей. На рис. 1 изображена схема горизонтального масштабирования по функциональному распределению.

Рисунок 1. Схема горизонтального масштабирования

Масштабирование с использованием репликации

Самый простой способ масштабирования, который часто используется для небольших и средних проектов, – использование репликации. Репликация – это механизм синхронизации нескольких копий объекта, таблиц базы данных (см. рис. 2). Master-slave-репликация – это синхронизация данных с основного master-сервера к подчиненным slave-серверам.

Рисунок 2. Масштабирование с использованием репликации

Так как в большинстве веб- и мобильных проектов операций чтения на порядок больше, чем операций записи, то операции записи мы можем производить на один master-сервер, а чтение данных осуществлять с множества slave-серверов. Между master- и slave-серверами должна быть настроена репликация.

Множество БД имеет встроенную репликацию, или, как говорят, «решение из коробки». Например, PostgreSQL-репликация может осуществляться следующими утилитами:

• Slony-I – асинхронная (master to multiple slaves) репликация;
• pgpool-I/II – синхронный мультимастер репликации;
• Pgcluster – синхронный мультимастер репликации;
• Bucardo;
• Londiste;
• RubyRep.
• начиная с версии 9.0, встроенная потоковая репликация.

При масштабировании с использованием репликации необходимо применять разные соединения: одно с master-сервером, только для записи или обновления, и второе, только со slave-сервером, непосредственно для чтения. При этом если у нас используется несколько slave-серверов, то стратегия выбора может быть случайной либо за определенным веб-сервером закрепляют определенный сервер БД.

Статью целиком читайте в журнале «Системный администратор», №10 за 2014 г. на страницах 54-62.

PDF-версию данного номера можно приобрести в нашем магазине.

Комментарии могут оставлять только зарегистрированные пользователи