Рационализация согласованности в облаках

Компонент статистики и политики


Компонент статистики отвечает за сбор статистики во время выполнения. Статистика собирается локально. На основе этой локальной информации компонент судит о глобальном состоянии (разд. 5). Используя эти суждения, одиночный сервер может принять решение об использовании того или иного протокола (т.е. протоколов сессионной согласованности или сериализуемости). Более строгая согласованность обеспечивается только в тех случаях, когда все серверы принимают решение об использовании согласованности категории A. Таким образом, если размер окна достаточно велик, и все запросы равномерно распределены по серверам, для принятия пригодных решений не требуется какой-либо центральный сервер. Однако консолизация статистики и периодическая веерная рассылка информации о принятых решениях могут сделать систему более устойчивой. В будущем мы планируем использовать эти приемы.

Для вероятностных политик требуются разные виды статистических данных. Общая политика обрабатывает записи, для которых маловероятны параллельные обновления на разных серверах с гарантиями уровня C. Поэтому для этой политики требуется информация о частоте обновлений, и для нее наиболее интересны редко обновляемые элементы данных. С другой стороны, для Динамической политики особенно интересны часто обновляемые элементы данных. Эта политика допускает частые параллельные обновления с гарантиями уровня C, пока вероятность достижения порогового значения не станет слишком высокой.

Для обеих этих политик мы сохраняем статистическую информацию прямо при записи. Для Общей политики мы сокращаем размер области памяти, требуемой для хранения статистики, за счет простой аппроксимации. Если нашей целью является достижение доли конфликтов менее 1%, то моделирование с использованием соотношения (3) из п 5.1.1 показывает, что интенсивность входного потока должна быть меньше, чем

, независимо от числа серверов. Если показатель скольжения окна равен δ , то уровень сессионной согласованности можно использовать при среднем числе обновлений в течение интервала кэширования, меньшем 0.22×δ.
Мы используем это свойство для сокращения числа разрядов, требуемых для хранения значения для одного кадра, и выделяем специальное значение для числа обновлений, большего того, которое помещается в выделенное число разрядов.

Например, если мы предположим, что размер окна равен одному часу, показатель скольжения равен 5 минутам, и размер интервала кэширования составляет 2 минуту, то потребуется хранить значения для двенадцати кадров окна. Средняя интенсивность обновлений в расчете на кадр должна быть
. Допуская некоторое отклонение, мы можем использовать для хранения значения 4 бита, резервируя одно значение (здесь 16) для обозначения числа обновлений, большего 15. Далее такое число трактуется как бесконечность. Тогда при таком окне на каждую запись требуется 12 × 4 бит = 48 бит, что является вполне приемлемым расходом.

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

Аналогичным образом проиводится сбор статистики для Динамической политики. Основным отличием является то, что собирается сумма обновлений, а не число операций. Поэтому объем памяти для хранения статистических данных невозможно оптимизировать так, как описывалось выше. По соображениям эффективности полная статистика собирается только для наиболее часто обновляемых записей. Все остальные записи обрабатываются с использованием порогового значения, назначенного для применения по умолчанию. Собираемая статистика имеет не очень большой объем и может сохраняться в основной памяти. Например, в системе с 10000 часто обновляемых записей категории B при наличии 100 кадров в окне и использовании 32 бит для хранения суммарных значений обновлений записей потребуется всего 10000 × 100 × 32 ≈ 4 мегабайта.

Оставшиеся вычисления описываются в разд. 5. Для уменьшения погрешности оценки мы свертываем точные функции распределения, если для некоторой записи в окне выполнялось менее 30 операций обновления. В противном случае, как описывалось в разд. 5, для сокращения вычислений используется аппрокимация на основе нормального распределения. Еще одной проблемой, свойственной Динамической политике, является начало работы системы, когда какая-либо статистика отсутствует. Эта проблема разрешается за счет использования в начале работы Политики разъединения и перехода к Динамической политике после накопления достаточного объема статистической информации.


Содержание раздела