В современном мире обработки данных и облачных сервисов вопрос масштабируемости и отказоустойчивости баз данных становится критически важным для обеспечения стабильной работы приложений и сервисов. Особенно актуальны эти параметры для компаний, работающих с большими объёмами данных и предоставляющих real-time услуги с высокой нагрузкой. Для достижения горизонтального масштабирования баз данных существуют две основных архитектурные стратегии — шардинг на уровне приложения и распределённые SQL базы данных. Несмотря на схожие цели, эти подходы существенно различаются по уровню отказоустойчивости и доступности. В данном материале на основе математического анализа вероятностей мы рассмотрим оба варианта и оценим, какой из них обеспечивает более высокую надёжность.
Шардинг на уровне приложения предполагает разделение данных между несколькими индивидуальными инстансами баз данных, каждый из которых размещён на отдельном сервере. Такое разделение производится с использованием специализированных знаний о предметной области, благодаря чему каждая база хранит «срез» данных, например, клиентов с определённым диапазоном идентификаторов. Соответственно, приложение отвечает за маршрутизацию запросов на нужный сервер и за обработку ситуаций, когда один из этих серверов выходит из строя. Каждый узел отвечает только за свою часть данных и работает относительно независимо от других. С одной стороны, такой подход сравнительно прост и может быть реализован без сложной логики синхронизации между серверами.
Однако с другой стороны, отказ даже одного узла приведёт к недоступности части данных и, как следствие, части сервиса. В рамках гипотезы, что каждый сервер имеет вероятность доступности около 99.9% (стандартное значение для виртуальных машин в облачных провайдерах), можно рассчитать общую доступность системы из шести узлов, где для корректной работы необходимы все узлы. При условии независимости отказов вероятность доступности всей системы вычисляется как произведение вероятностей доступности каждого узла. Это даёт итоговый показатель около 99.
4% для шестиузлового кластера, что уже несколько ниже базовой доступности отдельных серверов. Таким образом, для реальных бизнес-задач такой уровень доступности может оказаться недостаточным, особенно когда речь идёт о критически важных сервисах. Вторая архитектура — распределённые SQL базы данных — решает проблему устойчивости к отказам за счёт встроенного механизма репликации и использования квормного алгоритма для согласования транзакций. Такая база данных представляет собой единый логический объект, распределённый по множеству серверов. Каждый шардинг в этом случае реплицируется на несколько узлов, причём для успешного выполнения записи и чтения необходимы согласованные ответы большинства реплик.
Подобная архитектура позволяет автоматически балансировать нагрузку, маршрутизировать запросы и обеспечивать транзакции с сильной согласованностью. С учётом реплик и квормов, распределённая база может выдерживать выход из строя одного или нескольких узлов без потери доступности услуги, ведь данные дублируются и доступны с других серверов. Рассмотрим систему из шести узлов с коэффициентом репликации три. В такой конфигурации кластер остаётся доступным при условии, что работают не менее пяти узлов, то есть при отказе одного. Расчёты с использованием биномиального распределения показывают, что вероятность доступности такой системы превышает 99.
998% — существенно выше, чем у простого шардирования. Переход к более крупным и отказоустойчивым кластерам с репликацией пяти узлов (например, десятиузловая система с коэффициентом репликации пять) демонстрирует ещё более впечатляющие показатели — уровень доступности приближается к 99.99999%. Такая архитектура способна выдерживать одновременно отказ нескольких серверов и даже отдельных зон доступности (availability zones), что особенно важно для облачной инфраструктуры, распределённой географически. Преимущество распределённых SQL баз в их способности обеспечивать непрерывность работы сервиса даже при возникновении частичных сбоев инфраструктуры.
Современные алгоритмы, такие как Raft и Paxos, позволяют организовывать процесс репликации и согласования данных так, что бизнес-приложения получают гарантии глобальной согласованности и высокой доступности одновременно. Это снижает сложность разработки, так как не требуется вручную реализовывать логику маршрутизации или обработку падений отдельных узлов на уровне приложения. В то время как шардинг на уровне приложения является традиционным и более простым решением для горизонтального масштабирования, он серьёзно ограничен в плане отказоустойчивости. Отказ одного узла фактически делает часть данных недоступной, что ухудшает пользовательский опыт и приводит к потенциальным потерям. Для бизнесов с высокими требованиями к доступности и надёжности систем рекомендуется использовать распределённые SQL базы, которые, благодаря своей архитектуре и математической основе, обеспечивают значительно более высокие показатели устойчивости к отказам.
