В последнее время я общался с коллегами в науке и технике, и меня часто спрашивали, как выбрать между суббазой, субтаблицей и распределенной базой данных.Также в Интернете есть много статей о промежуточном программном обеспечении + традиционной реляционной базе данных (суб-базе данных). база данных и подтаблица) и распределенная база данных NewSQL, но некоторые мнения и суждения я считаю экстремальными, и несправедливо оценивать качество плана вне контекста.

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

Где развита база данных NewSQL?

Прежде всего, о том, считается ли "промежуточное ПО + подтаблица реляционной базы данных" распределенной базой данных NewSQL, есть зарубежная статья pavlo-newsql-sigmodrec, если по классификации в этой статье Spanner, TiDB, OB являются первыми новыми архитектурами. Решения промежуточного программного обеспечения, такие как Sharding-Sphere, Mycat и DRDS, относятся ко второму типу (в этой статье также есть третья облачная база данных, которая не будет подробно представлена ​​в этой статье). Является ли режим основанным на промежуточном программном обеспечении (включая SDK и прокси) + традиционную реляционную базу данных (подбаза данных и подтаблица) в распределенной архитектуре? Я думаю, что да, потому что хранилище действительно распределено и также может масштабироваться горизонтально. Но не "псевдо" распределенная база данных? С точки зрения продвинутой архитектуры это также имеет смысл. «Псевдо» в основном отражается в повторяющемся синтаксическом анализе SQL и генерации плана выполнения между уровнем промежуточного программного обеспечения и базовой БД, а механизм хранения основан на B + Tree, который фактически избыточен и неэффективен в архитектуре распределенной базы данных. Чтобы избежать словесной войны между истинными и ложными распределенными базами данных, база данных NewSQL в этой статье относится именно к этой новой архитектуре базы данных NewSQL.

Насколько продвинута база данных NewSQL по сравнению с промежуточным ПО + подбазой данных и подтаблицей? Нарисуйте простую диаграмму сравнения архитектур:

1. Традиционные базы данных предназначены для дисков, а управление хранилищем в памяти и контроль параллелизма не так эффективны, как базы данных NewSQL.
2. Анализ SQL в режиме промежуточного программного обеспечения, оптимизация плана выполнения и т. д. повторяются в промежуточном программном обеспечении и базе данных, а эффективность относительно низкая;
3. По сравнению с XA распределенная транзакция базы данных NewSQL оптимизирована и имеет более высокую производительность;
4. Новая архитектура хранилища базы данных NewSQL основана на протоколе paxos (или Raft) с несколькими копиями. высокая доступность и высокая надежность (RTO
5. База данных NewSQL по своей сути поддерживает шардинг данных, а миграция и расширение данных автоматизированы, что значительно сокращает работу администратора баз данных, при этом она прозрачна для приложения, нет необходимости указывать ключи базы данных и таблиц в SQL.

Большинство из них также являются основными преимуществами продуктов баз данных NewSQL, но действительно ли эти прекрасные функции верны? Ниже я понимаю вышеизложенные пункты.

Распределенная транзакция

Это палка о двух концах.

предел CAP

Подумайте, почему появившаяся ранее база данных NoSQL не поддерживала распределенные транзакции (последняя версия mongoDB и т. д. тоже начала ее поддерживать), не хватает ли теоретической и практической поддержки? Нет, причина в том, что теорема CAP по-прежнему является проклятием на голову распределенной базы данных, что неизбежно принесет в жертву доступность A или устойчивость к разделам P, обеспечивая при этом сильную согласованность. Почему большинство NoSQL не поддерживают распределенные транзакции?

Итак, выходит ли база данных NewSQL из пределов теоремы CAP? нисколько. Google Spanner, владелец базы данных NewSQL (в настоящее время большинство распределенных баз данных спроектировано в соответствии с архитектурой Spanner), обеспечивает согласованность и доступность выше, чем 5 девяток, заявляя, что является «фактически ЦС», в чем его истинное значение Вероятность того, что система находится в состояние ЦС очень высокое, а вероятность отключения службы из-за сетевого раздела очень мала.Настоящая причина в том, что он создает частную глобальную сеть, чтобы гарантировать отсутствие сетевого раздела, вызванного прерыванием сети.Эксплуатация и техническое обслуживание команда также является точкой продажи облачного ключа. Подробнее см. в статье «Spanner, TrueTime и CAP Theory», написанной Эриком Брюэром, автором предложения CAP.

Порекомендуйте интересную статью о распределенных системах, стоящих на распределенных плечах гигантов, в которой упоминается: В распределенных системах вы можете знать, где работа, или вы можете знать, когда работа сделана, но вы не можете понять и то, и другое одновременно. Оба двухфазных протокола по существу являются протоколами антидоступности.

Комплектность:

Поддерживает ли протокол двухфазной фиксации строго ACID и можно ли покрыть различные нештатные ситуации? 2PC отправляет исключение на этапе фиксации. На самом деле, как и при первой фазе фиксации с максимальной эффективностью, будут некоторые видимые проблемы. Строго говоря, атомарность A и согласованность C не могут быть гарантированы в течение определенного периода времени. (механизм восстановления может гарантировать окончательные А и С после устранения неисправности). Полная поддержка распределенных транзакций — непростая задача, она должна быть в состоянии справиться с различными аномалиями сети и различного оборудования, включая сетевую карту, диск, процессор, память, блок питания и т. д., и пройти строгие тесты. Я общался с другом раньше, и они даже сказали, что известная на данный момент поддержка NewSQL для распределенных транзакций неполна.У них есть все случаи, которые невозможно запустить.Люди в кругу настолько уверены, что также показывает полноту поддержки распределенных транзакций. На самом деле она неравномерна.

Однако распределенные транзакции являются очень важным базовым механизмом этих баз данных NewSQL.От его реализации зависит межресурсный DML, DDL и т. д. Если производительность и полнота этого блока скомпрометированы, корректность Это повлияет на выполнение сегмента SQL. Большое влияние.

представление

Традиционные реляционные базы данных также поддерживают распределенные транзакции XA, но почему они редко используются в сценариях с высокой степенью параллелизма? Поскольку базовый протокол двухфазной фиксации XA имеет такие проблемы, как высокая нагрузка на сеть, длительное время блокировки, взаимоблокировка и т. д., он также редко используется в системах OLTP, основанных на традиционных реляционных базах данных в больших масштабах. Реализация распределенных транзакций базы данных NewSQL по-прежнему в основном основана на протоколе двухэтапной фиксации. Например, модель распределенных транзакций Google Percolator использует атомные часы + MVCC + изоляция моментальных снимков (SI). Этот метод обеспечивает глобальную согласованность через TSO (Timestamp). Oracle) MVCC избегает блокировок и асинхронно выполняет часть коммитов через первичные и вторичные блокировки, что повышает производительность распределенных транзакций по сравнению с XA.

SI — это оптимистическая блокировка.В сценариях с горячими данными может произойти большое количество сбоев при отправке. Кроме того, уровень изоляции SI не совсем такой, как у RR, у него не будет фантазийных чтений, но будет перекос записи.

Но независимо от того, как он оптимизирован, по сравнению с 1PC, дополнительное получение GID, накладные расходы на сеть и сохраняемость журнала подготовки 2PC все равно будут приводить к значительной потере производительности, особенно когда количество кросс-узлов велико, например, в банковском деле. Для пакетного вывода один файл может уйти на аккаунты W. Как бы вы это ни делали, пропускная способность будет не очень высокой.

Тестовые данные распределенных транзакций, предоставленные Spanner

Хотя продукты распределенных баз данных NewSQL рекламируют полную поддержку распределенных транзакций, это не означает, что приложения могут полностью игнорировать разбиение данных.Лучшие практики работы с этими базами данных все равно будут написаны, и большинству сценариев приложений следует максимально избегать распределенных транзакций. .

Поскольку стоимость производительности строго согласованных транзакций слишком высока, мы можем подумать, действительно ли нам нужны такие строго согласованные распределенные транзакции? Особенно после разделения микросервисов многие системы вряд ли будут помещены в единую базу данных. Попытка ослабить требования согласованности — это гибкая транзакция, отказ от ACID (атомарность, согласованность, изоляция, долговечность) и переход к BASE (базовая доступность, мягкое состояние, в конечном счете согласованность), такие как Saga, TCC, надежные сообщения для обеспечения возможной согласованности. и другие модели. Для крупномасштабных сценариев OLTP с высокой степенью параллелизма я лично рекомендую использовать гибкие транзакции вместо строго согласованных распределенных транзакций. Что касается гибких транзакций, автор ранее также писал технический компонент, и в последние годы появились некоторые новые модели и фреймворки (например, Fescar, исходный код которого был только что открыт Али).

Можно ли решать распределенные транзакции только с двухфазным протоколом фиксации? Идея избежать распределенных транзакций через сервер обновлений в Oceanbase 1.0 очень поучительна, но она также стала 2PC после версии 2.0. Распределенные транзакции в отрасли — это не только двухэтапные решения для представления, есть и другие решения — время перехода от двухэтапного (если его нельзя открыть, есть отечественная переводная версия)www.jdon.com/51588)

HA и мультижилье в разных местах

Режим ведущий-ведомый не является оптимальным.Даже полусинхронная репликация, в крайних случаях (от полусинхронной до асинхронной), также имеет проблему потери данных.В настоящее время отрасль признала, что лучшее решение основано на paxos Протокол распределенного консенсуса или другие типы Paxos похожи на метод плота. Google Spanner, TiDB, cockcoachDB и OB используют этот метод. Хранение с несколькими копиями на основе протокола Paxos следует принципу более половины записи, поддерживает автоматический выбор мастера решает проблему высокой надежности данных и сокращает время аварийного переключения.Повышает доступность, особенно снижает нагрузку на эксплуатацию и техническое обслуживание.Это решение является технически зрелым, а также является стандартным в нижней части базы данных NewSQL. Конечно, этот метод также можно использовать в традиционных реляционных базах данных.Команды Alibaba и WeChat также преобразовали хранилище MySQL для поддержки нескольких копий paxos.MySQL также запустила официальную версию MySQL Group Cluster.Ожидается, что master-slave модель может стать историей.

Алгоритм распределенного консенсуса сам по себе не сложен, но в конкретной инженерной практике необходимо учитывать и оптимизировать множество исключений, а реализовать надежный и зрелый протокол консенсуса на уровне производства непросто. Например, при реальном использовании его необходимо преобразовать в мультипаксос или мультиплот, и необходимо уменьшить сетевые, дисковые IO и другие накладные расходы с помощью пакетных, асинхронных и других методов.

Следует отметить, что многие производители баз данных NewSQL рекламируют, что на основе протокола paxos или raft может быть реализовано [множество действий в разных местах], что на самом деле является предварительным условием, то есть сетевая задержка между разными местами не может быть слишком высокой. На примере банка "два места и три центра" расстояние между разными местами составляет тысячи миль, а задержка достигает десятков миллисекунд.Хочешь жить дольше - нужно участвовать в подтверждении более половины журнала базы данных с копией в другом месте.Такая большая задержка практически невозможна.Система OLTP неприемлема.

** Это прекрасное видение — сделать больше работы в разных местах на уровне базы данных, но нет хорошего плана для задержки, вызванной расстоянием. ** Я общался с командой ant ранее, решение мультиактивности ant в разных местах заключается в синхронизации информации о транзакциях с двойной записью через MQ на прикладном уровне, а удаленный DC сохраняет информацию о транзакциях в распределенном кеше. происходит удаленное переключение, промежуточное программное обеспечение синхронизации базы данных уведомляет о времени задержки данных приложение считывает информацию о транзакции из кэша и заносит в черный список бизнес-объекты, задействованные в этот период, такие как пользователи и учетные записи, и удаляет эти бизнес-объекты из черного списка. после синхронизации данных. Поскольку двойная запись — это не все журналы операций базы данных, а только информация о транзакциях, задержка данных влияет только на данные за определенный период времени — это более надежное решение для мультиактивности в разных местах.

Кроме того, некоторые системы претерпели преобразование единиц, что также следует учитывать при выборе мастера paxos.Это также функция, которой в настоящее время не хватает во многих базах данных NewSQL.

Масштабный механизм горизонтального расширения и фрагментации

Алгоритм paxos решает проблему высокой доступности и высокой надежности, но не решает проблему горизонтального расширения масштаба, поэтому необходимо поддерживать шардинг. Базы данных NewSQL построены со встроенным механизмом сегментирования и автоматически определяют горячие точки в соответствии с нагрузкой данных (использование диска, скорость записи и т. д.) каждого сегмента, а затем выполняют разделение сегментов, миграцию данных и слияние. процессы применяются Это незаметно, что значительно снижает нагрузку на администратора баз данных при эксплуатации и обслуживании. Взяв, к примеру, TiDB, он разделяет данные на регионы, и если регион достигает 64 М, данные автоматически переносятся.

В режиме подтаблицы подбазы данных ключ разделения, метод разделения (диапазон, по модулю, согласованный хэш или пользовательская таблица маршрутизации), правила маршрутизации, количество разделенных таблиц базы данных, расширение и т. д. По сравнению с базой данных NewSQL, этот режим значительно усложняет работу приложения, что также является серьезной проблемой для большинства систем.

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

**Здесь возникает проблема, заключающаяся в том, что унифицированная встроенная стратегия сегментирования базы данных NewSQL (например, tidb на основе диапазона) может быть не самой эффективной, поскольку она не согласуется с элементами секционирования в модели предметной области, что приводит к следствием этого является то, что многие транзакции будут генерировать распределенные дела. **Например, базовая бизнес-система банка использует клиента в качестве измерения, то есть таблица клиентов, таблица счетов клиентов и таблица потоков записываются вместе в большинстве сценариев, но если они разделены в соответствии с к диапазону первичных ключей каждой таблицы. Эта транзакция не может быть выполнена на одном сегменте, что приведет к проблемам с производительностью в высокочастотных OLTP-системах.

Поддержка распределенного SQL

Обычный односегментный SQL, оба из которых хорошо поддерживаются. Поскольку позиционирование и цель базы данных NewSQL — это общая база данных, поддерживаемый SQL будет более полным, включая сложные SQL, такие как объединение и агрегирование между сегментами. Режим промежуточного программного обеспечения предназначен для требований приложений, но большинство из них также поддерживают SQL с разделенными ключами, обход таблиц базы данных, объединение одной базы данных, агрегацию, сортировку, пейджинг и т. д. Но поддержки объединения и агрегации между библиотеками недостаточно. Базы данных NewSQL обычно не поддерживают такие функции, как хранимые процедуры, представления и внешние ключи, а нижний уровень модели промежуточного программного обеспечения представляет собой традиционную реляционную базу данных.Эти функции относительно легко поддерживать, если они включают только одну базу данных. Базы данных NewSQL часто предпочитают быть совместимыми с протоколами MySQL или PostgreSQL, поэтому поддержка SQL ограничена этими двумя.Промежуточное программное обеспечение, такое как режим драйвера, часто требует только простого синтаксического анализа SQL, маршрутизации вычислений и перезаписи SQL, поэтому оно может поддерживать больше типов SQL базы данных. .

Основное отличие в поддержке SQL заключается в распределенном генераторе плана выполнения SQL.Поскольку база данных NewSQL имеет распределение и статистическую информацию базовых данных, ее можно использовать как CBO, а сгенерированный план выполнения более эффективен.Однако есть в режиме промежуточного программного обеспечения такой информации нет, и только она может быть основана на правиле RBO (Rule-Based-Opimization), поэтому режим промежуточного программного обеспечения обычно не поддерживает соединение между базами данных, поскольку эффективность реализации часто не высока, лучше оставить это приложению.

Здесь также видно, что архитектурный стиль режима промежуточного программного обеспечения + подбазы данных и подтаблицы отражает компромисс и баланс, который представляет собой дизайн, ориентированный на приложения; в то время как база данных NewSQL предъявляет более высокие требования и «все включено», Это общее базовое технологическое программное обеспечение, поэтому сложность и технический порог последнего также намного выше.

механизм хранения

Механизм хранения традиционных реляционных баз данных ориентирован на диски, и большинство из них основаны на B+-деревьях. Дерево B+ уменьшает количество случайных чтений за счет уменьшения высоты дерева, тем самым уменьшая количество обращений к диску и повышая производительность чтения.Однако большое количество случайных записей приведет к разбиению дерева, что приведет к случайным записям и снижению производительности записи. . Базовый механизм хранения NewSQL в основном использует LSM.По сравнению с LSM дерева B+ случайная запись на диск становится последовательной записью, что значительно повышает производительность записи. Однако производительность чтения LSM хуже, чем у дерева B+, из-за необходимости слияния данных.Вообще говоря, LSM больше подходит для сценариев, где запись больше, чем чтение. Конечно, это только сравнение с точки зрения структуры данных.В реальной реализации базы данных производительность чтения и записи будет оптимизирована с помощью SSD, буферизации, фильтра Блума и т. д., поэтому производительность чтения не будет слишком сильно уменьшаться. Из-за накладных расходов на несколько копий и распределенных транзакций время отклика данных NewSQL не превосходит время отклика реляционной базы данных SQL на одной машине, однако из-за эластичного расширения кластера общее улучшение QPS по-прежнему очевидно. Это также то, что производители баз данных NewSQL называют распределенными базами данных.

Зрелость и экология

Распределенная база данных – это новый тип базового программного обеспечения общего назначения. Для точного измерения и оценки требуется многомерная тестовая модель, включая статус разработки, использование, экологию сообщества, мониторинг эксплуатации и обслуживания, периферийные вспомогательные инструменты, удовлетворение функций, таланты администраторов баз данных, SQL тестирование производительности совместимости, тестирование высокой доступности, онлайн-расширение, распределенные транзакции, уровень изоляции, онлайн-DDL и т. д. Хотя разработка базы данных NewSQL тестировалась в течение определенного периода времени, она в основном сосредоточена в Интернете и неосновных транзакциях. систем традиционных предприятий, находится в стадии быстрой итерации и непрерывной оптимизации и улучшения использования масштаба. Напротив, традиционные реляционные базы данных разрабатывались годами. Благодаря полной оценке они имеют очевидные преимущества в отношении зрелости, функциональности, производительности, окружающей среды, контроля рисков и накопления соответствующих талантов. Совместимость с системами также лучше. Для интернет-компаний давление роста объема данных и гены поиска новых технологий будут более склонны попробовать базу данных NewSQL, и им больше не нужно будет учитывать разделение таблиц базы данных, преобразование приложений, расширение, согласованность транзакций и другие проблемы. очень привлекательное решение.. Для отраслей с высокой осведомленностью о рисках, таких как традиционные предприятия, такие как банки, база данных NewSQL может все еще находиться на стадии исследования и разумного пилотного проекта в будущем. Основанная на промежуточном программном обеспечении + подбазе данных и режиме подтаблицы, структура проста, а технический порог ниже.Хотя нет базы данных NewSQL с исчерпывающими функциями, основным требованием большинства сценариев является правильная маршрутизация SQL после разделения.Подробнее более чем достаточно, можно сказать, что этого достаточно в большинстве сценариев OLTP.

Суммировать

Если после прочтения приведенного выше контента вы все еще не знаете, какой режим выбрать, то объедините следующие вопросы, сначала подумайте, является ли проблема, решаемая базой данных NewSQL, реальной проблемой для самой себя:

• Должны ли строго согласованные транзакции разрешаться на уровне базы данных?
• Скорость роста данных непредсказуема?
• Превышает ли частота расширения мощностей собственные возможности по эксплуатации и техническому обслуживанию?
• Является ли пропускная способность более важной, чем время отклика?
• Должен ли он быть полностью прозрачным для приложения?
• Есть ли группа администраторов баз данных, знакомых с базами данных NewSQL?

Если 2 или 3 из вышеперечисленных положительных результатов, вы можете рассмотреть возможность использования базы данных NewSQL.Хотя на раннем этапе могут потребоваться определенные затраты на обучение, это направление развития базы данных, и будущие преимущества будут выше, особенно в интернет-индустрии.С быстрым увеличением объема данных боль, вызванная подбазой данных и подтаблицей, будет увеличиваться день ото дня. Конечно, если вы выбираете базу данных NewSQL, вы также должны быть готовы к определенным рискам. Если вы еще не приняли решение, рассмотрите следующие вопросы:

• Достаточно ли возможной согласованности для практических сценариев?
• Можно ли оценить общий объем данных в ближайшие несколько лет?
• Существует ли окно обслуживания системы для таких операций, как расширение емкости и DDL?
• Является ли он более чувствительным к времени отклика, чем к пропускной способности?
• Вам нужна совместимость с существующими системами реляционных баз данных?
• Есть ли накопление талантов традиционных администраторов баз данных?
• Можно ли допустить вторжение подбазы данных и подтаблицы в приложение?

Если большинство этих вопросов положительные, то лучше подбиблиотека и подтаблица. В мире программного обеспечения существует несколько идеальных решений, и базы данных NewSQL не являются панацеей для распределенных архитектур данных. Напротив, подтаблица подбазы данных является более дешевым и менее рискованным решением.Он в наибольшей степени повторно использует традиционную экологию реляционной базы данных.Благодаря промежуточному программному обеспечению он также может выполнять большинство функций после подбазы данных и подтаблицы, и возможность настройки сильнее. На текущем этапе, когда база данных NewSQL еще не полностью сформирована, можно сказать, что подбаза данных и подтаблица являются решением с низким верхним пределом, но высоким нижним пределом, особенно для основных систем традиционных отраслей. намереваетесь использовать базу данных в качестве продукта черного ящика, убедитесь, что практичная и хорошая подтаблица подбазы данных будет считаться безопасным выбором.

наконец

Спасибо, что дочитали до конца.Если в статье есть какие-либо недостатки, вы можете поддержать и высказать свое мнение в области комментариев. Если вы считаете, что моя статья была вам полезна, то ставьте палец вверх.

Также прошу обратить внимание на мой публичный номер:Программист Офиопогон, будет каждый день делиться техническими статьями или отраслевой информацией о Java. Добро пожаловать, чтобы следить и пересылать статью.