OB июнь: Эта статья "Серия технического анализа OceanBase 2.0"Пятая статья. Сегодня мы продолжим говорить о распределенной архитектуре, и поговорим о функции "глобальный снимок согласованности" в версии 2.0, которая всем небезразлична. Для получения более интересных вещей, пожалуйста, обратите внимание на публичный аккаунт OceanBase и продолжайте подписываться на эта серия контента!
предисловие
Прежде всего, я думаю, некоторые друзья могут спросить, увидев это название:
- Что такое «глобально согласованный снимок»?
- Какую роль он играет в базе данных OceanBase?
- Почему база данных OceanBase представила эту вещь в версии 2.0?
На самом деле истории происходят из двух традиционных понятий в базе данных: «Изоляция снимка"и"Multi-Version Concurrency Control (сокращенно MVCC)"Общий смысл этих двух технологий заключается в поддержке нескольких номеров версий (т. е. нескольких моментальных снимков) для данных в базе данных. Когда данные изменяются, можно использовать разные номера версий, чтобы различать изменяемое содержимое и модификацию. Предыдущее содержимое, чтобы обеспечить одновременный доступ к нескольким версиям одних и тех же данных, чтобы избежать проблемы конфликта чтения-записи, вызванной механизмом блокировки в классической реализации.
Поэтому эти две технологии используются во многих продуктах баз данных (таких как Oracle, SQL Server, MySQL, PostgreSQL), и база данных OceanBase также использует эти две технологии для повышения эффективности выполнения в параллельных сценариях. Но в отличие от традиционной одноточечной архитектуры полного совместного использования (т. е. Shared-Everything) традиционной базы данных,OceanBase — это нативная распределенная архитектура., принимает многоточечную архитектуру без совместного использования (т. е. без общего доступа) и столкнется с техническими проблемами, связанными с распределенной архитектурой, при реализации глобально (межмашинного) согласованного уровня изоляции моментальных снимков и управления параллельным выполнением нескольких версий (будет обсудим позже).
Чтобы решить эти проблемы, база данных OceanBase представила технологию «Global Consistent Snapshot» в версии 2.0. В этой статье будут представлены концепции и основные принципы реализации, связанные с технологией «глобально согласованных моментальных снимков» OceanBase.
(Примечание. Все описания в этой статье относятся к механизму реализации, использующему «уровень изоляции моментальных снимков» и технологию «управления параллельным выполнением нескольких версий». Для классического «уровня изоляции», использующего механизм «блокировки» для реализации традиционного « Уровень изоляции», который выходит за рамки этой статьи.)
Принцип реализации традиционной базы данных
Во-первых, давайте посмотрим, как в традиционных базах данных реализованы «уровень изоляции моментальных снимков» и «управление параллельным выполнением нескольких версий».
Взяв в качестве примера классическую базу данных Oracle, когда в базе данных фиксируются изменения данных, Oracle присваивает ей «Номер изменения системы (SCN)» в качестве номера версии. SCN — это значение, тесно связанное с системными часами, которое можно просто понимать как эквивалентное отметке системного времени.Разные SCN представляют «зафиксированную версию» данных в разные моменты времени, таким образом реализуя изоляцию моментальных снимков уровня данных.
Предполагая, что соответствующий номер версии записи равен SCN0 при ее первоначальной вставке, когда транзакция T1 изменяет запись, но еще не зафиксирована (Примечание. В настоящее время SCN1, соответствующий T1, еще не создан, необходимо дождитесь этапа фиксации T1), Oracle передаст данные Представленная версия SCN0 до того, как изменение будет сохранено в «Отменить сегменты». В это время, если другая параллельная транзакция T2 захочет прочитать эту запись, Oracle назначит SCN2 для T2 по текущей системной отметке времени. , и поиск данных по двум условиям:
1) Должны быть представлены данные;
2) Принятая версия данных меньше или равна максимальному значению SCN2.
В соответствии с приведенными выше условиями транзакция T2 получит данные, соответствующие версии SCN0, из сегмента отката и проигнорирует транзакцию T1, изменяющую ту же запись. При использовании этого метода предотвращается появление «грязного чтения», не возникают конфликты блокировок между одновременными операциями чтения/записи и реализуется многоверсионный контроль данных. Весь процесс показан на рисунке ниже:
Что касается «уровня изоляции моментальных снимков» и «управления многоверсионным параллелизмом», механизмы реализации различных продуктов баз данных будут различаться, но большинство из них следуют следующим принципам:
- Каждый раз, когда в данные вносятся изменения, им присваивается новый номер версии.
- Изменения в номерах версий должны быть гарантированно "монотонными вперед".
- Номер версии берется из текущей временной метки в системных часах или значения, тесно связанного с текущей временной меткой.
- При запросе данных вам также нужен номер последней версии (аналогично, это текущая метка времени или значение, сильно связанное с текущей меткой времени) и найти самые последние отправленные данные, меньшие или равные этому номеру версии.
Проблемы, с которыми сталкиваются распределенные базы данных Предыдущее описание «управления параллельным выполнением нескольких версий» выглядит идеальным, но есть неявное предварительное условие:Порядок изменения номеров версий в базе данных должен соответствовать хронологическому порядку транзакций в реальном мире.,который:
— Транзакции, которые происходят раньше в реальном мире, должны получить меньший (или равный) номер версии;
— Транзакции, которые происходят позже в реальном мире, должны получить больший (или равный) номер версии.
Если эта согласованность не может быть достигнута, каков будет результат? В качестве примера возьмем следующий сценарий:
1) запись R1 вставляется и фиксируется первой в транзакции T1, и соответствующий SCN1 равен 10010;
2) Затем запись R2 вставляется и фиксируется в транзакции T2, и соответствующий SCN2 равен 10030;
3) Впоследствии транзакция T3 хочет прочитать эти две части данных, и полученный SCN3 равен10020, поэтому он получает только запись R1 (SCN1
На самом деле нарушение этой согласованности может также привести к более экстремальным ситуациям, рассмотрим следующие сценарии:
1) запись R1 вставляется и фиксируется первой в транзакции T1, и соответствующий SCN1 равен 10030;
2) Затем запись R2 вставляется и фиксируется в транзакции T2, а соответствующий SCN210010;
3) Впоследствии транзакция T3 хочет прочитать эти две части данных, и полученный SCN3 равен10020, поэтому он может получить только запись R2 (SCN2
Некоторые друзья могут сказать: описанные выше ситуации на практике не случаются, потому что системная метка времени всегда монотонно вперед, поэтому транзакция, отправленная первой в реальном мире, должна иметь меньший номер версии. Да, для традиционных баз данных из-за одноточечной архитектуры совместного использования всего (Shared-Everything) база данных имеет только один источник системных часов, поэтому изменение метки времени (т. е. номера версии) действительно может быть монотонно опережающим и должно в соответствии с Хронологический порядок реального мира остается прежним.
Однако для распределенной базы данных, такой как OceanBase, из-за архитектуры без общего доступа распределение данных и обработка транзакций будут включать разные физические машины, и системные часы между несколькими физическими машинами неизбежно будут отличаться. number не может гарантировать, что номера версий, полученные на разных машинах, соответствуют реальным временным рядам. Взяв в качестве примера два приведенных выше сценария, если T1, T2 и T3 выполняются на разных физических машинах, и все они используют отметку времени локальной системы в качестве номера версии, то из-за разницы часов между машинами это вполне возможно. Два исключения, упомянутые выше.
Для решения упомянутых выше проблем в распределенное поле вводятся два понятия: «Внешняя согласованность» и «Причинная согласованность». Взяв в качестве примера два приведенных выше сценария, порядок возникновения транзакций в реальном мире будет T1 -> T2 -> T3.Если изменение SCN может гарантировать порядок SCN1
«Причинная непротиворечивость» — это частный случай «внешней непротиворечивости»: транзакции происходят не только в последовательном порядке, но и в причинно-следственной связи. Следовательно, охват «внешней непротиворечивости» шире, а «каузальная непротиворечивость» — лишь один из них. OceanBase удовлетворяет «внешней согласованности» в своей реализации, а также «причинно-следственной согласованности». Содержание второй половины этой статьи в основном сосредоточено на «внешней согласованности».
Часто используемые решения в отрасли
Итак, как распределенная база данных должна обеспечивать внешнюю согласованность в глобальной (межмашинной) области, чтобы достичь глобально согласованного уровня изоляции моментальных снимков и управления параллельным выполнением нескольких версий? Вообще говоря, в отрасли есть две реализации:
1) Использоватьспециальное оборудование, такие как GPS и атомные часы, чтобы системные часы нескольких машин были в высокой степени согласованы, а ошибка была настолько мала, что приложение вообще не могло ее воспринять. В этом случае можно продолжать использовать временную метку локальной системы в качестве номера версии, а также обеспечить внешнюю согласованность в глобальном масштабе.
2) Номер версии больше не зависит от локальных системных часов каждой машины, и все транзакции БД проходятцентрализованное обслуживаниеПолучите глобально согласованный номер версии и используйте эту службу, чтобы убедиться, что номер версии монотонно вперед. Таким образом, логическая модель получения номера версии в распределенной архитектуре такая же, как и логическая модель в одноточечной архитектуре, что полностью устраняет фактор разницы часов между машинами.
Типичным представителем первого способа является база данных Google Spanner. Он использует систему GPS для синхронизации времени между несколькими компьютерными залами по всему миру и использует атомные часы, чтобы гарантировать, что погрешность локальных системных часов поддерживается в небольшом диапазоне, чтобы системные часы нескольких компьютерных залов по всему миру можно удерживать в очень высоких пределах. Этот метод известен как TrueTime в базе данных Spanner. Исходя из этого, база данных Spanner может следовать традиционным путем, используя отметку времени локальной системы в качестве номера версии, не беспокоясь о нарушении внешней согласованности в глобальной области.
Преимущество этого метода заключается в том, что внедрение программного обеспечения является относительно простым и позволяет избежать узких мест в производительности, которые могут быть вызваны использованием централизованных служб. Но у этого метода есть и свои недостатки.Во-первых, существенно повышаются требования к оборудованию машинного зала.Во-вторых,метод "GPS+атомные часы" не может на 100% гарантировать,что системные часы между несколькими машинами полностью согласованы.Если аппаратное отклонение GPS или атомные часы вызывают время. Если ошибка слишком велика, проблема внешней согласованности будет устранена. Согласно описанию в статье GoogleSpanner, вероятность дрейфа часов крайне мала, но не равна нулю. На следующем рисунке представлена статистика диапазона ошибок часов для тысяч машин в документе Google Spanner:
OceanBase выбирает второй метод реализации, то есть используется централизованная служба для предоставления глобально унифицированного номера версии. Этот выбор в основном основывается на следующих соображениях:
- Этой проблемы можно полностью избежать, логически устранив разницу в часах между машинами.
- Избегается сильная зависимость от специального оборудования. Это особенно важно для продукта базы данных общего назначения, и мы не можем предполагать, что все пользователи, использующие базу данных OceanBase, развернули оборудование "GPS + атомные часы" в компьютерном зале.
Технология "глобально согласованных моментальных снимков" OceanBase Как упоминалось выше, база данных OceanBase использует централизованную службу для предоставления глобально согласованного номера версии. Когда транзакция изменяет данные или запрашивает данные, независимо от того, с какой физической машины исходит запрос, номер версии будет получен из этой централизованной службы.OceanBase гарантирует, что все номера версий монотонно передаются вперед и соответствуют реальному порядку времени.
С таким глобально согласованным номером версии OceanBase может делать согласованные моментальные снимки данных в глобальной (межмашинной) области в соответствии с номером версии, поэтому мы называем эту технологию как«Глобальный согласованный снимок». С помощью технологии глобально согласованных моментальных снимков можно обеспечить глобально согласованный уровень изоляции моментальных снимков и управление параллельным выполнением нескольких версий, не беспокоясь о нарушении внешней согласованности.
Однако я считаю, что у некоторых друзей возникнут сомнения, когда они увидят это, например:
- Как эта централизованная служба генерирует единый номер версии? Как можно гарантировать монотонность вперед?
- Каков объем этой централизованной службы? Используют ли транзакции во всем кластере OceanBase один и тот же сервис?
- Какова производительность этой централизованной службы? Станет ли это узким местом в производительности, особенно в случае большого количества одновременных обращений?
- Что, если произойдет сбой в этой централизованной службе?
- Если в процессе получения глобального номера версии для транзакции возникает сетевое исключение (например, мгновенное сетевое дрожание), нарушит ли оно «внешнюю согласованность»?
Ниже приведены ответы на эти вопросы один за другим.
Во-первых, номер версии, сгенерированный этой централизованной службой, является отметкой времени локальной системы, но ее служебный объект — это уже не просто локальные транзакции, а все транзакции в глобальной области видимости, поэтому эта служба вызывается в OceanBase.«Глобальная служба меток времени (GTS)». Поскольку служба GTS является централизованной и получает временные метки только от одних системных часов, гарантируется, что полученные временные метки (т. е. номера версий) должны быть монотонно опережающими и соответствовать реальному временному порядку.
Итак, есть ли только одна служба GTS в кластере базы данных OceanBase, и все транзакции в кластере получают временные метки отсюда? Друзья, знакомые с базой данных OceanBase, знают, что «арендатор» — это базовая единица для изоляции ресурсов в OceanBase. Это похоже на концепцию «экземпляра» в традиционных базах данных. Данные между разными арендаторами полностью изолированы, и нет требований к согласованности. Нет необходимости реализовывать глобально согласованные номера версий для арендаторов, поэтому у каждого «арендатора» в кластере баз данных OceanBase есть отдельная служба GTS. Это не только делает управление сервисами GTS более гибким (на основе арендаторов), но также распределяет запросы номеров версий в кластере на несколько сервисов GTS, значительно снижая вероятность возникновения узких мест в производительности, вызванных одноточечными сервисами. Ниже представлена простая схема службы GTS в кластере базы данных OceanBase:
Говоря о производительности, после фактических измерений одна служба GTS может ответить на 2 миллиона запросов временной метки (т. е. номера версии) в течение 1 секунды, поэтому, пока количество запросов в секунду в арендаторе не превышает 2 миллионов, производительность GTS не будет обнаружена. узкое место, и реальному бизнесу трудно достичь этого верхнего предела. Хотя производительность GTS не является проблемой, получение временных меток из GTS сопряжено с большими накладными расходами, чем получение локальных временных меток. По крайней мере, сетевая задержка неизбежна. Мы также измерили это. Когда сеть работает нормально, по сравнению с использованием локальной временной метки в качестве версии число, влияние использования GTS на производительность не превышает 5%, и большинство приложений его не воспримет.
Помимо обеспечения нормальной производительности обработки ГСТ, база данных OceanBase по-прежнемуНе влияет на внешнюю консистенциюВ рамках сделки оптимизирован процесс получения ГТС, а именно:
- Преобразование некоторых запросов GTS в локальные запросы и получение номера версии из локального контрольного файла, что позволяет избежать накладных расходов на передачу данных по сети;
- Объединение нескольких запросов GTS в один пакетный запрос для повышения глобальной пропускной способности GTS;
- Используйте «локальную технологию кэширования GTS», чтобы уменьшить количество запросов GTS.
Эти меры оптимизации еще больше повышают эффективность обработки GTS, поэтому пользователям вообще не нужно беспокоиться о производительности GTS.
Вышеуказанные ситуации являются нормальными, но для централизованных служб необходимо учитывать исключения. Во-первых, это проблема высокой доступности. Как и базовые службы передачи данных в OceanBase, служба GTS использует протокол Paxos для достижения высокой доступности. Если служба GTS прерывается из-за ненормальных условий (например, простоя), OceanBase автоматически выбирает ее. в соответствии с протоколом Paxos.Новый сервисный узел, весь процесс происходит автоматически и быстро (1~15 секунд), без ручного вмешательства.
Наконец, если транзакция обнаружит, что ответ GTS слишком медленный, она повторно отправит запрос GTS, чтобы избежать зависания обработки транзакции из-за запроса GTS из-за особых обстоятельств (таких как потеря сетевого пакета).
Короче говоря, GTS учла обработку многих нештатных ситуаций в процессе проектирования и разработки, чтобы гарантировать, что она может предоставлять стабильные и надежные услуги.
Подводя итоги технологии «глобальных непротиворечивых моментальных снимков», можно сказать, что база данных OceanBase имеет возможность достижения «уровня изоляции моментальных снимков» и «управления параллельным выполнением нескольких версий» в глобальном (межмашинном) масштабе и может гарантировать «внешнюю согласованность» в глобальная область видимости.На этой основе реализованы многие функции, связанные с глобальной согласованностью данных, такие как глобальное согласованное чтение, глобальное индексирование и т. д.
Таким образом, по сравнению с традиционной одноточечной базой данных, OceanBase сохраняет преимущества распределенной архитектуры без какого-либо ухудшения согласованности глобальных данных Разработчики приложений могут использовать OceanBase так же, как одноточечную базу данных, не беспокоясь об этом. проблемы согласованности между машинами. Можно сказать, что благодаря технологии «снимка глобальной согласованности» база данных OceanBase прекрасно реализует глобальную согласованность данных в распределенной архитектуре!
использованная литература
1. Snapshot isolation
2. Multiversionconcurrency control
3. Isolation(database systems)
4. Spanner (database)
5. CloudSpanner: TrueTime and External Consistency
6. Causal consistency
2.0 Статьи из серии «Анализ»
- Подробное объяснение нового поколения облачной платформы OceanBase (1)
- Шелковистая гладкость! Оперативный и обслуживающий персонал рассказывает о том, как добиться плавного онлайн-обновления базы данных (2)
- Важная инфраструктура OceanBase - DBReplay (3)
- Очарование балансировки нагрузки OceanBase (4)
Пекинская станция OceanBase TechTalk
27 октября (суббота) в Пекине стартует второе офлайн-мероприятие OceanBase TechTalk по обмену техническими данными.
В это время три тяжеловесных гостя OceanBase: Чен Мэнмэн (полное вино), Хань Фушэн (Ян Ран) и Цяо Гожи (Руи Тэн) побеседуют с вами о поддержке Tmall Double 11 в этом году.OceanBase 2.0 имеет новые функции продукта и основные технологические инновации.Пекин Чжунгуаньцунь, увидимся!
Ссылка для регистрации:2-й салон технологий OceanBase TechTalk на станции Пекин в 2018 году