Югабайт спонсировал этот пост.
Вероятность — это ветвь математики, которая касается неопределенности. Это помогает нам понять вероятность возникновения различных результатов. Ниже мы рассматриваем два альтернативных варианта архитектуры для масштабирования базы данных по горизонтали и используем теорию вероятностей, чтобы показать, что одна архитектура более надежна, чем другая в 60 000.
Горизонтальная база данных масштабирования параметров Архитектуры. Шарки на уровне приложения
Sharding уровня приложения использует знания, специфичные для домена для разделения данных на несколько экземпляров базы данных, работающих на нескольких серверах. Каждый экземпляр базы данных изолирован, что позволяет масштабироваться рабочие нагрузки. Эта архитектура требует пользовательской логики для маршрутизации, перебалансировки и обработки перекрестных решений.
Распределенный SQL
Распределенный SQL предоставляет единственную логическую базу данных, которая горизонтально масштабируется по нескольким серверам со встроенной репликацией и логикой на основе кворума для реализации глобальных кислотных транзакций. Дополнительные серверы могут быть добавлены и интегрированы в систему, что позволяет масштабировать рабочие нагрузки. Автоматическая маршрутизация, перебалансировка и обработка перекрестных операций упрощает разработку и ускоряет время на рынке.
Для этого сравнения мы предполагаем, что обе архитектуры работают на платформе Google Cloud, используя виртуальные машины, размещенные в рамках службы вычислительного двигателя. Google Cloud Platform обеспечивает ежемесячную целевую задачу на уровне службы работы на 99,9% для одного виртуальной машины/экземпляра. Мы используем этот SLO в наших расчетах доступности системы.
Архитектура 1-Шардинг на уровне приложения
Основная приложением система разделяет данные на нескольких серверах, которые затем работают полузависимо.
- Данные вручную разделены на серверы — например, клиенты A — F на сервере 1, G — L на сервере 2 и т. Д.
- Каждый сервер отвечает только за его срез данных.
- Приложение должно направлять запросы на правильный сервер.
- Если сервер не работает, его данные становятся недоступными, даже если другие серверы являются здоровыми.
Доступность 6-узловой системы на уровне приложения мы знаем, что:
- Вероятность доступного узла, доступен узел) = 0,999.
- Узлы не зависят друг от друга.
- Системе нужны все шесть узлов, чтобы быть доступными.
В теории вероятности независимых событий — это события, результаты которых не влияют друг на друга. Например, при броске четырех кубиков число, отображаемое на каждом кости, не зависит от трех других костей.
Аналогичным образом, доступность каждого сервера в кластере с шестью узлами, обезвоженным на приложения, не зависит от других. Это означает, что каждый сервер имеет индивидуальную вероятность доступного или недоступного, а на неудачу одного сервера не зависит от сбоя или иным образом других серверов в кластере.
В действительности, могут быть общие ресурсы или общую инфраструктуру, которая связывает доступность одного сервера с другим. В математических терминах это означает, что события зависят. Тем не менее, мы рассматриваем вероятность того, что эти типы неудач будут низкими, и поэтому мы не учитываем их в этом анализе.
Математически, если два события A и B являются независимыми, то вероятность того, что A и B происходит вместе, является продуктом их индивидуальных вероятностей:
Для кластера базы данных из шести узлов это будет означать:
Следовательно, архитектура шестиузет, поддерживающая SLO 99,4%, что особенно ниже SLO базовых виртуальных машин.
Архитектура 2 — Распределенный SQL
Распределенная база данных SQL автоматически нарушает данные одной логической базы данных на нескольких серверах. Кроме того, для устойчивости он поддерживает реплики для каждого осколка и обычно использует алгоритм на основе кворума для координации обновлений, обеспечивая прочную согласованность для чтения и записи.
- Каждый осколок данных реплицируется по нескольким узлам, с одной репликой, обозначенной как лидер.
- Кворум (большинство) необходим для записи данных (например, 2 из 3, если коэффициент репликации составляет 3).
- Кворум также требуется для чтения, что элегантно достигается путем маршрутизации запроса лидеру, избегая необходимости выдавать чтение во всех трех репликах и ждать, пока большинство ответит.
- Данные не привязаны к одному узлу.
- Система может переносить сбои узлов и все еще обслуживать запросы.
Доступность коэффициента репликации шестикновения три распределенного SQL Cluster
Каждый узел управляет одним или несколькими осколками данных. Каждый осколок находится в группе кворума, с его данными реплицированы на двух других узлах. Для защиты от отключений зоны доступности (AZ), а также от отдельных сбоев узлов кластер обычно распределяется по трем зонам доступности, а алгоритм распределения данных гарантирует, что реплики осколка всегда помещаются в различные зоны доступности.
В теории вероятности биномиальное распределение моделирует количество ожидаемых результатов во время ряда испытаний или тестов.
Мы можем использовать биномиальное распределение для расчета вероятности того, что k -серверы будут доступны в кластере N -серверов:
Мы знаем, что:
- P (узел доступен) = 0,999.
- Узлы не зависят друг от друга.
- Узлы равномерно размещены в трех зонах доступности.
- Есть много групп кворума, распространяющихся по серверам.
- Группы плотов организованы так, что реплики всегда находятся в отдельных зонах доступности.
- Если один узел потерян, затронута только одна копия данных, поэтому кластер остается доступным.
- Если два узла потеряны, если они находятся в одном и том же AZ, затронута только одна копия данных, поэтому кластер остается доступным. Это еще больше увеличивает доступность, но мы не включили эти расчеты для простоты.
- Если теряются три или более узлов, затронуты две или более копий данных, а кластер будет недоступен.
Таким образом, система шестикновения доступна, если:
- Все шесть узлов подняты.
- Ровно пять узлов.
Это означает:
Архитектура на основе трехкоружных коэффициентов репликации (RF) на основе трехквета поддерживает SLO 99,998%, особенно выше, чем SLO базовой виртуальной машины.
Доступность распределенного SQL-кластера коэффициента репликации 10 узлов 5
Для дальнейшего повышения устойчивости и защиты от двух одновременных сбоев, распределенный SQL может быть настроен для работы с коэффициентом репликации RF из пяти. С помощью этой архитектуры каждый узел управляет одним или несколькими осколками данных.
Каждый осколок находится в группе кворума, с его данными реплицированы на четырех других узлах. Для защиты от отключений зоны доступности (AZ), а также от отдельных сбоев узлов кластер обычно распределяется по пяти зонах доступности, а алгоритм распределения данных гарантирует, что реплики осколка всегда помещаются в различные зоны доступности.
Мы знаем, что:
- P (узел доступен) = 0,999.
- Узлы не зависят друг от друга.
- Узлы равномерно размещены в пяти зонах доступности.
- Есть много групп кворума, распространяющихся по серверам.
- Группы плотов организованы так, что реплики всегда находятся в отдельных зонах доступности.
- Если один узел потерян, затронута только одна копия данных, поэтому кластер остается доступным.
- Если теряются два узла, затронуты только две копии данных, поэтому кластер остается доступным.
- Если три или четыре узла теряются, если они находятся в двух или менее AZ, затронуты только две копии данных, поэтому кластер остается доступным. Это еще больше увеличивает доступность, но мы не включили эти расчеты для простоты.
- Если пять или более узлов потеряны, затронуты три или более копий данных, а кластер был бы недоступен.
Архитектура на основе кворума на основе 10 узлов поддерживает цель на уровне обслуживания 99,99999%, которая значительно выше, чем SLO кластера RF3.
Архитектурное влияние на доступность
Традиционные архитектуры ограничены риском неудачи с одним узлом. На уровне приложения Sharding составляет эту проблему, потому что, если какой-либо узел уходит, его осколок и, следовательно, общая система становится недоступной.
Напротив, распределенные базы данных с консенсусом на основе кворума (например, yugabytedb) обеспечивают устойчивость и масштабируемость разлома, что обеспечивает более высокую устойчивость и улучшенную доступность.
Архитектура
Цель уровня обслуживания
Одиночный узел
99,9% (три 9 с)
6 Узел на уровне приложения на уровне приложения
99,4% (два 9 с)
6 Node RF3 распределенный SQL Cluster
99,99% (четыре 9 с)
10 Node RF5 распределенный SQL Cluster
99,99999% (семь 9 с)
В приведенной выше таблице приведена гораздо большая вероятность отказа с использованием шестиузлетной архитектуры на уровне приложений, чем 10-узловый распределенный SQL-кластер RF 5. Конкретно:
Вероятность сбоя шестикнового приложения Sharded по сравнению с 10-узловым RF5 =
Имеет ли значение устойчивость?
Предприятия, которые предоставляют высокопроизводительные услуги транзакций в реальном времени, такие как платежные процессоры и решения по борьбе с отмыванием денег, критически зависят от устойчивости их инфраструктуры.
Каждая минута простоя утраченной доход. Это разрушает доверие и потенциально вызывает отток. Платформа, обрабатывающая 10 000 транзакций в секунду по 50 долларов сша, с платой 2% потеряет 600 000 долл. сша дохода в минуту, только в сборе.
Устойчивость имеет значение. Хорошо задокументированные процессы и запуска, активируемые во время сценария отказа, недостаточно. Операционная устойчивость для критических услуг требует устойчивых, самовосстанавливающихся архитектур, таких как распределенный SQL.
Заключение
Традиционные архитектуры, особенно те, которые используют один узел или на уровне приложений, склонны к сбою и предлагают ограниченную доступность. Распределенные базы данных SQL с репликацией на основе кворума обеспечивают значительно более высокую доступность, устойчивость к неисправности и устойчивость.
Разница не просто техническая, но и критически важная для бизнеса. Время простоя может привести к существенной потери дохода, повреждению репутации и нормативному риску. По мере увеличения операционных требований и нормативных ожиданий, принятие устойчивых, самовосстанавливающихся архитектур имеет решающее значение для любого предприятия, которое опирается на высокопроизводительные услуги в реальном времени.
Познакомьтесь с Yugabytedb, PostgreSQL-совместимой распределенной базой данных для ваших облачных приложений. Эластичный, масштабируемый и гибкий. Узнайте больше последних из Yugabyte Trending Stories Youtube.com/thenewstack Tech, которые движутся быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Yugabyte Emea VP Крис Смит имеет опыт работы в математике и провел большую часть своей карьеры, работая с базами данных и платформами управления данными на ролях, охватывающих разработку программного обеспечения и лидерство на рынке. Перед югабайтом Крис занимал должность вице -президента … Подробнее от Криса Смита
