Понять, что означают сильная ограниченная устаревшая информация, сеанс, согласованный префикс и возможные уровни согласованности
Я не большой поклонник спорта, но люблю свой 9-мяч. Между недолгой попыткой учебы в колледже и моей первой работой в области программирования я сделал всего понемногу. Каким-то образом мне удалось перейти от работы в книжном магазине, розничном магазине, ресторане быстрого питания и продаже электроники из багажника машины до работы в бильярдном зале полный рабочий день в течение года. Я никогда не терял страсти к игре и всегда чувствую себя наиболее расслабленным, когда смотрю или играю в бильярд.
Турниры по пулу обычно включают в себя гонку за чем-нибудь. Например, гонка до 7 означает, что в этом раунде побеждает тот, кто первым выиграет семь игр. В обычном турнире и большом бильярдном зале могут одновременно проходить десятки игр. Я прочитал отличный технический документ, который объясняет уровни согласованности с помощью аналогии с бейсбольным матчем. Хотя это дало мне новое понимание, я чувствовал, что чего-то не хватает.
Итак, я применил то, что я узнал, к своей страсти к бассейну и придумал это.
Если вы не знакомы с ним, CosmosDB - это облачная служба базы данных NoSQL, которая поддерживает несколько различных API, позволяет реплицировать данные в глобальных регионах, просто нажав кнопку в пользовательском интерфейсе портала, и предоставляет соглашения об уровне обслуживания ( SLA) для доступности, задержки, пропускной способности и согласованности. Вы можете выбрать уровень согласованности по умолчанию для базы данных и в дальнейшем переопределить его для каждого приложения или соединения.
Уровни согласованности обеспечивают компромисс между производительностью, доступностью, устареванием и упорядочением ваших данных. Самый простой способ объяснить, что это означает, - это пройти через уровни согласованности через призму турнира по пулу.
Подожди, кого это волнует?
Почему уровни согласованности вообще имеют значение? В некоторых случаях вполне подойдет локальный единственный экземпляр базы данных. Однако для большинства корпоративных приложений требуется быстрое выполнение (низкая задержка) и отказоустойчивость (высокая доступность). Низкая задержка и высокая доступность могут быть решены с помощью распределенной системы или нескольких узлов или кластеров базы данных, распределенных по географической области.
- Если один узел в кластере выходит из строя, другие узлы могут вмешаться, чтобы поддерживать доступность.
- Если один кластер в регионе выходит из строя, другие регионы могут вмешаться, чтобы поддерживать доступность.
- Наличие узлов в разных регионах приближает базу данных к пользователям в этом регионе, что, в свою очередь, обеспечивает меньшую задержку и более высокую скорость.
Было бы неплохо, если бы это было так же просто, как щелкнуть выключателем и создать распределенную систему. К сожалению, распределенные системы сложны. Теорема CAP описывает три гарантии:
- Согласованность - каждое чтение является текущим с последними записями
- Доступность - каждый запрос (например, чтение) получает ответ
- Допуск на разделение - если сообщения потеряны или задерживаются, система все равно будет работать как единое целое.
Теорема утверждает, что одновременно можно предоставить только две из трех гарантий. Обеспечить все три невозможно. Сбои и задержки сети - нормальная реальность, поэтому основное внимание уделяется согласованности и доступности. CosmosDB обеспечивает гарантию высокой доступности и дает возможность «набрать» уровень согласованности, чтобы получить компромисс с производительностью.
Бонус: если вы хотите копнуть еще глубже, обратите внимание на теорему PACELC.
Установка
Для простоты предположим, что есть 20 игроков, каждый из которых играет за 10 столами в гонке до трех. Обозначьте их буквами «А» и «Б» на каждой таблице. Чтобы еще больше упростить модель, предположим, что каждый матч заканчивается победой «А». История очков за каждым столом в конечном итоге выглядит так:
- A — 1, B — 0
- A — 1, B — 1
- A — 2, B — 1
- A — 2, B — 2
- A - 3, B - 2 (A - победитель)
Счетовод отслеживает счет за каждым столом, а за турниром следит большая аудитория. Теперь я проведу вас через каждый уровень согласованности, имея в виду эту настройку.
Сильная последовательность
Линеаризуемость. При чтении гарантированно возвращается самая последняя версия элемента.
Сильная согласованность, вероятно, является самым простым для понимания и на что обычно полагаются разработчики большинства традиционных систем управления реляционными базами данных (СУБД, то есть SQL или MySQL). По сути, любой и где угодно соглашается с тем, что происходит в любой момент времени.
В нашем турнире по пулу это создает небольшие накладные расходы. Каждый раз, когда счет меняется за столом, секретарь дает свисток, чтобы все остановить, пока счет остается общим. Они обновляют свой счет, затем переходят к каждому другому столу, чтобы сообщить другим секретарям. Наконец, они идут к аудитории и удостоверяются, что каждый член аудитории знает оценку. Затем они снова свистят в свисток, и все возобновится. Вы можете себе представить, что это немного замедляет работу.
Подводя итог, эта модель имеет:
- Высочайшая согласованность - все согласны
- Самая низкая производительность - мы должны убедиться, что все знают о каждом обновлении, прежде чем продолжить
- Самая низкая доступность - нет реальной возможности масштабирования, потому что добавление новых наблюдателей только увеличивает накладные расходы
С помощью кворума можно поддерживать сильную согласованность в распределенной системе. Когда несколько копий документа хранятся в нескольких системах, изменения ставятся на голосование и фиксируются только тогда, когда несколько узлов соглашаются, что изменение приемлемо (аналогично, для прерывания операции должно существовать определенное количество голосов). Это приносит в жертву задержку (вы должны дождаться прихода голосов) и пропускную способность (опять же, из-за того, что данные должны проходить через узлы). В нашем примере это действие секретаря, которое подтверждается каждым другим секретарем и членом аудитории.
Из-за накладных расходов, изначально заложенных в поддержание кворума, сильная согласованность стоит почти в два раза дороже, чем сеанс, согласованный префикс или конечная согласованность.
Согласованность данных: самая высокая
Доступность приложения: самая низкая
Задержка: высокая (плохая)
Пропускная способность: самая низкая
Примеры: финансы, инвентаризация, планирование.
Ограниченная устаревание
Согласованный префикс. Считывает отставание от записи на префиксы k или интервал t.
Ограниченная устаревшая информация - это компромисс, в котором задержки заменяются надежной согласованностью. Вместо того, чтобы гарантировать, что все наблюдатели имеют одни и те же данные одновременно, этот уровень позволяет указать задержку в операциях и / или времени. Например, эта база данных настроена так, чтобы отставать не более чем на 100 операций или задерживаться на пять секунд.
Что это означает?
В случае нашего турнира секретарь не дает свисток и не останавливает игру. Вместо этого игра продолжается, и результаты регистрируются с отметкой времени. Централизованная система сопоставляет их и транслирует на табло, которое может прочитать каждый. Поскольку для получения результатов из различных таблиц требуется время, табло отображается не в режиме реального времени. Игрок может выиграть свой турнир, но должен подождать несколько секунд, пока победа не появится на табло.
Компромисс здесь заключается в том, что каждому дается небольшая передышка для сопоставления оценок. В случае CosmosDB это означает, что вы можете выбрать несколько регионов, потому что задержка дает время для репликации данных в этих регионах (как вы можете догадаться, существуют ограничения и указание операционного лага равным «единице». не допускается, потому что это почти то же самое, что и сильная последовательность).
Обобщить:
- Согласованность за пределами заданного пользователем порога
- Обеспечивает гарантию того, «насколько вероятен» возможный результат.
- Это обеспечивает лучшую производительность, чем сильная согласованность.
- Доступность по-прежнему ниже из-за присущей ему задержки для синхронизации всех регионов.
- Как и сильная согласованность, это примерно вдвое дороже, чем сеанс, согласованный префикс и конечная согласованность.
Согласованность данных: высокая
Доступность приложения: низкая
Задержка: высокая
Пропускная способность: Низкий
Примеры: приложения, показывающие статус, отслеживание, баллы, тикеры и т. д.
Сессия
Согласованный префикс. Монотонное чтение, монотонная запись, чтение-ваша-запись, запись-следует-чтение.
Согласованность сеанса - это уровень согласованности по умолчанию для вновь создаваемых баз данных и коллекций, и по уважительным причинам. Это менее чем вдвое дешевле, чем сильная согласованность и ограниченная устаревшая информация, и обеспечивает как хорошую производительность, так и доступность. Думайте о сеансе как о вашем приложении или подключении.
Хороший довод в пользу согласованности сессий - это счетчики за каждым столом. С ограниченным упорством секретарь может попасть в такую неловкую ситуацию:
- Пишет A - 1 (B по-прежнему 0)
- Пишет B - 1
- Читает оценочную карточку для проверки
- Чтение возвращает A - 1, B - 0
Да, в мире NoSQL ваши чтения не должны коррелировать с вашими записями, если вы не используете что-то вроде строгой согласованности. В этом примере ограниченное устаревание не гарантирует согласованность актуальных данных из-за встроенной задержки, поэтому чтение вернуло состояние из предыдущего момента времени. В конце концов, если они продолжат проверять свою карточку, счет будет A - 1, B - 1.
Согласованность сеанса исправляет это. Это гарантирует, что все, что написано, будет актуальным для чтения из этого сеанса. Все остальное будет точным, но отложенным. Итак, вот что происходит:
- Пишет A - 1 (B по-прежнему 0)
- Пишет B - 1
- Читает оценочную карточку для проверки
- Чтение возвращает A - 1, B - 1 (гарантировано)
Если секретарь решит убить время, посмотрев на счет из других таблиц, он увидит точный счет, но не обязательно текущий. Другими словами, таблица 2 в настоящее время может быть на A - 1, B - 1, но секретарь видит A - 1, B - 0. Точно так же аудитория всегда имеет точный счет, который может быть отложен. Через несколько секунд после того, как секретарь записывает B - 1, зрители все еще могут видеть B - 0. В конце концов, счет увеличивается.
Обобщить:
- Сильная согласованность для сеанса - все чтения являются текущими с записями из этого сеанса, но записи из других сеансов могут отставать
- Данные из других сеансов поступают в правильном порядке, их актуальность не гарантируется.
- Это обеспечивает хорошую производительность и хорошую доступность за половину стоимости строгой согласованности и ограниченной устойчивости.
Если вы хотите выйти за рамки метафоры бассейна, подумайте о программе питания с социальным обменом. Пользователь, который вводит свое питание, всегда должен видеть текущее точное представление о калориях и составе питательных веществ за этот день. Однако другим пользователям в их социальных сетях не нужно видеть эти обновления в режиме реального времени. Со временем они могут получать обновления и нажимать кнопку «Нравится», чтобы получить хорошо приготовленную здоровую еду, даже если она появляется после небольшой задержки.
Согласованность данных: средняя
Доступность приложения: высокая
Задержка: средняя
Пропускная способность: Умеренный
Примеры: социальные приложения, фитнес-приложения, корзина для покупок.
Согласованный префикс
Возвращаемые обновления представляют собой префикс всех обновлений без пробелов.
Это один из самых простых уровней согласованности для объяснения, если вы понимаете предыдущие уровни. Мне нравится думать о непротиворечивом префиксе как об ограниченном устаревании без гарантий задержки / задержки операции. Любое наблюдение будет точным для определенного момента времени, но не обязательно актуальным.
В нашем турнире по пулу судьи старательно ведут счет и обновляют свои оценочные карточки. Они сопоставляются и транслируются на табло. С ограниченной устаревшей аудиторией известно, что на табло всегда отображается всего несколько очков или, возможно, несколько минут с задержкой. Используя последовательный префикс, это не так ясно. Когда много матчей заканчиваются одновременно, для суммирования и обновления результатов может потребоваться больше времени. По мере того, как матчи проводятся и счет не меняется, счет «догоняет» и становится текущим.
В идеале у счетчиков есть специальное приложение, использующее согласованность сеансов. Табло и приложение статистики пула, используемое аудиторией, используют согласованный префикс.
Обобщить:
- Показания соответствуют определенному моменту времени, то есть оценки всегда точны, но не обязательно актуальны.
- Нет гарантий, насколько актуально, но во многих случаях задержки могут быть в секундах, а не в минутах.
- Хорошая производительность и отличная доступность, поскольку различным узлам может потребоваться любое время, необходимое для синхронизации и согласования текущей модели.
Согласованность данных: низкая
Доступность приложения: высокая
Задержка: низкая
Пропускная способность: Умеренный
Примеры: социальные сети (комментарии, лайки), приложения, в которых есть обновления, например оценки.
Конечная согласованность
Не в порядке читает.
Для зрителей и судей на турнире по пулу возможная согласованность была бы катастрофой. Конечную согласованность легко понять: в конечном итоге чтения становятся непротиворечивыми. Нет никакой гарантии, сколько времени это займет (например, согласованный префикс), но еще одно предостережение заключается в том, что обновления не обязательно будут приходить по порядку.
Рассмотрим этот сценарий:
- Секретарь вводит A - 1 (теперь счет A - 1, B - 0)
- Секретарь вводит B - 1 (теперь счет A - 1, B - 1)
- Секретарь вводит A - 2 (теперь счет A - 2, B - 1)
- Секретарь читает счет и видит A - 0, B - 1
- Аудитория смотрит на табло и видит A - 2, B - 0.
В этом случае обновления не по порядку означают, что оценки могут не соответствовать действительности. Запись «A» может происходить раньше, чем запись «B», даже если время было другим. В конце концов, счет будет A - 2, B - 1, но нет никакой гарантии, когда и нет возможности действительно проверить это, да, это текущий счет.
Так почему бы вам вообще рассмотреть этот уровень согласованности?
Во-первых, поскольку CosmosDB не обязана гарантировать точность на определенный момент времени или даже порядок записи, это модель с наивысшей производительностью, наименьшими затратами и высочайшей доступностью.
Во-вторых, есть несколько допустимых сценариев, когда этот уровень в порядке. Например, автоматическому информационному бюллетеню лиги пула, вероятно, удастся избежать в конечном итоге согласованности, потому что, когда он опрашивает базу данных через несколько часов после окончания турнира, существует большая вероятность того, что согласованность в конечном итоге будет достигнута.
Согласованность данных: самая низкая
Доступность приложения: высокая
Задержка: низкая
Пропускная способность: Самый высокий
Примеры: неупорядоченные обновления, такие как обзоры и оценки, сводный статус.
Сработала ли эта аналогия, чтобы помочь вам лучше понять уровни согласованности? Оставляйте свои мысли и отзывы в комментариях. Вы также можете прочитать официальную документацию по уровням согласованности CosmosDB.
С уважением,
