Конкурентоспособность современных IT-решений сегодня строится не только на функциональности или влиянии бренда. Важную роль в успешности продукта играет обработка данных. Скорость и отказоустойчивость решений дает бизнесу преимущество в гонке за долей рынка. Для крупных операторов данных, таких как видеохостинги, компании по предоставлению услуг связи, финансовые учреждения, эффективное масштабирование баз данных становится краеугольным камнем успешных технологических стратегий.
Под масштабированием баз данных (БД) понимают методы и практики, которые существенно расширяют их возможности по обработке возрастающих объемов информации с сохранением оптимальной производительности на уровне клиентов БД и общей надежности системы.
Когда нужно масштабирование БД
Необходимость масштабирования базы данных возникает, когда к этому подталкивают текущие или будущие бизнес-потребности проекта. Например, решения перестают отвечать требованиям рынка или рост компании опережает текущие возможности по обработке данных.
Показатели, которые являются для бизнеса сигналами к масштабированию, индивидуальны и могут зависеть от отрасли, сферы или специфики деятельности компании. Это может быть SLA времени отклика системы, стоимость поддержания ее работы, загрузка процессора или памяти. Поэтому задача состоит в том, чтобы определить эти важные показатели.
Если же вынести бизнес за скобки и сфокусировать внимание на технических показателях, то ключевыми для большинства будут:
- время ответа на запросы;
- скорость загрузки процессоров сервера базы данных;
- объем потребляемой приложением БД оперативной памяти;
- остатки свободного места на накопителях данных;
- количество операций чтения/записи и связанные с ними задержки;
- тренд числа ошибок;
- динамика количества транзакций за единицу времени;
- число подключений;
- изменение коэффициента попадания в кэш во времени.
Виды масштабирования
Для наращивания возможностей БД есть целый набор стратегий. Самые распространенные — это горизонтальное и вертикальное масштабирование. Также может использоваться партиционирование (бывает как вертикальным, так и горизонтальным), подключение кэширования или вообще переход в облако, где масштабированием займется провайдер.
Горизонтальное масштабирование
Под горизонтальным масштабированием (scaling out) обычно подразумевают методики, связанные с добавлением серверов к уже существующим. К ним относят шардинг и репликацию (также иногда говорят о разделении операций чтения и записи).
Шардинг (sharding)
Это вид партиционирования, когда данные распределяются между несколькими параллельно работающими серверами. Каждый из которых хранит свой фрагмент данных.
Повышение производительности системы достигается за счет того, что задачи обслуживания клиентов распределяются между серверами БД.
Репликация
Это разнесение данных на дополнительные серверы, каждый из которых берет на себя обязательство обеспечивать их чтение из своей копии, тогда как центральный сервер принимает функции записи информации и распределения обновленных частей данных на серверы для чтения. Производительность вырастает за счет появления нескольких точек, в которые клиенты могут обращаться для решения задач.
В отличие от шардинга каждый из реплицированных серверов может предоставить полный набор данных системы.
Как настроить горизонтальное масштабирование
Среди баз данных open source самой популярной можно считать PostgreSQL.
Здесь нет «честного» встроенного шардинга. В PostgreSQL — технология Foreign Data Wrapper (FDW), но практическое ее использование в целях построения шардинга приносит меньше пользы, чем хотелось бы. Бывает и так, что добавленные серверы не увеличивают, а снижают общую производительность системы.
В общем случае для реализации шардинга необходимо выбрать поле данных, по которому будет определяться обслуживающий запрос клиента сервер, и написать логику переадресации запросов в сторону этих серверов. Мультиплексирование можно реализовать как на уровне приложения (автоматический выбор сервера БД для подключения на уровне приложения), так и на уровне базы данных с использованием, например, pgpool.
Но есть альтернативный и более простой способ получить шардинг на родственных PostgreSQL технологиях. Например, можно воспользоваться системой GreenPlum, в которой шардинг заложен в архитектуру, и все, что остается после установки, это выбрать столбец, по которому будет выбираться шард с помощью подобной инструкции:
CREATE TABLE tableName ( column1 type1, column2 type2, ... columnN typeN ) DISTRIBUTED BY (column1);
Неверный выбор поля для разделения шард приведет к неравномерной нагрузке на серверы. Поэтому не стоит использовать в качестве такого ключа поля с большим количеством NULL-значений, повторяющихся элементов, дату и/или время.
В каких случаях нужно горизонтальное масштабирование
Шардинг хорошо подойдет для систем, в которых клиенты в подавляющем большинстве случаев работают только со своими данными, не требуют доставки и изменения данных других клиентов.
Например, шардинг отлично подойдет для масштабирования БД сервиса виртуальных АТС. ВАТС клиентов между собой не взаимодействуют.
В свою очередь, разделение чтения и записи работает хорошо там, где подавляющее большинство операций — это чтение данных, тогда как их запись и изменение происходят сравнительно редко.
Репликация подойдет для таких систем, как Content Delivery Network (CDN). Ресурсы CDN обновляются сравнительно нечасто, а их задержка при распространении обычно некритична на фоне последующего прироста скорости загрузки.
Репликация как стратегия повышения производительности сети естественным образом обеспечивает устойчивость к отказам всей системы, поскольку каждый из серверов содержит полную копию данных.
Вертикальное масштабирование
Вертикальное масштабирование (scaling up) — это чаще всего просто повышение производительности существующего сервера за счет добавления ему ресурсов. Можно заменить процессор, нарастить и/или изменить тип памяти, установить более быстрые жесткие диски или добавить специальные дисковые кэши.
Как настроить масштабирование вверх
Обычно масштабирование вверх дополнительной настройки не требует: все происходит автоматически на уровне операционной системы. В PostgreSQL подключить и автоматически использовать SSD-кэш не получится. Однако можно создать специальный временный table_space, подключать его для обработки больших объемов информации. Пример:
CREATE TABLESPACE fast_space LOCATION '/mnt/ssdcache';
ALTER TABLE frequently_accessed_table SET TABLESPACE fast_space;
Он хорошо сработает там, где БД необходимо обрабатывать большие объемы информации, создавать и сохранять временные таблицы для сортировки и хеширования данных и так далее.
В каких случаях нужно вертикальное масштабирование
В целом вертикальное масштабирование — это решение проблемы здесь и сейчас. Вместо того чтобы запускать процесс перевода единственного сервера базы данных в кластер, когда потребуется целая плеяда недешевых специалистов, можно просто попросить системного администратора докупить и доставить оборудование в сервер. Это здесь и сейчас улучшит ситуацию. Более того, дорабатывать существующие приложения не придется.
Перемены не потребуют изменения логики работы клиентов базы данных. Зато сразу дадут прирост в скорости.
Следует иметь в виду, что:
- У вертикального масштабирования есть естественный предел. По мере роста нагрузки наступает необходимость покупать high-end-оборудование. А его цена ограничивает соотношение «результат/затраты». Тогда переход к горизонтальному масштабированию может стать более выгодной альтернативой.
- Если сервер единственный, то замена оборудования и его донастройка могут потребовать простоя.
Чаще всего вертикальное масштабирование имеет смысл как дополнительный эффект от замены оборудования, которое отработало свой ресурс. Или как способ быстро решить проблему производительности на время, пока инженеры готовят переход к горизонтальному масштабированию.
Заключение
Горизонтальное масштабирование — это более дорогой и долгий, зато устойчивый к будущим изменениям способ.
Его делают с помощью шардинга (распределения данных между серверами) или репликации (разделения операций чтения и записи между серверами). Шардинг хорошо работает в случае, когда данные клиентов изолированы друг от друга. А разделение чтения и записи поможет там, где данные меняют не слишком часто, но интенсивно считывают.
Вертикальное масштабирование — это возможность получить быстрые результаты с помощью замены оборудования.
Его проще реализовать, но сам подход ограничен по соотношению затрат и отдачи от них.