AWS re:Invent 2023 - [LAUNCH] Achieving scale with Amazon Aurora Limitless Database (DAT344)
AWS re:Invent 2023 - [LAUNCH] Achieving scale with Amazon Aurora Limitless Database (DAT344)
Продолжая вчерашнюю тему про модели консистентности, рекомендую посмотреть интересное выступление от ребят из AWS про значимый апгрейд их базы данных Aurora, которую мы как-то обсуждали в бонусном выпуске "Code of Architecture" и по которой есть whitepaper от 2017 года. Сейчас ребята добавили возможности масштабирования к этой базе данных. Причем тут фокус был на масштабировании write нагрузки, так как с read нагрузкой у этой базы уже было все хорошо. Если кратко описывать изменения, то смысл примерно такой
- Добавляется семантика шардирования внутри самого Aurora - для этого у пользователей появляется возможности
- Пометить таблицы как шардированные и указать ключ шардирования - если транзакции попадают на один шард, то это максимально быстро, если нет, то используются распределенные транзакции двухфазный коммит. Для шардирования используется hash-range partitioning.
- Пометить часть таблиц как reference - такие таблички используются как справочники и они разложены на каждом шарде (их стоит использовать, если write нагрузки на эти таблички небольшие)
- Шардированная база поддерживается семантику вида read commited и repetable read
- Эта семантика работает внутри кластера Aurora, поэтому общие штуки типа дампа или point-in-time recovery работают как ожидается от кластера без шардов
- Под капотом все это работает за счет добавление концепции shard group внутри aurora cluster, где есть роутеры для распределенных транзакций (здесь координируются распределенные транзакции и собирается общий результат) и шардов для доступа к данным (здесь выполняются локальные части запросов, работает локальный планировщик, используются индексы и так далее). Здесь тоже появляется дополнительный параметр compute redundancy, который позволяет compute частям шардов лучше переживать отказы
- Для реализации repetable read ребята используют концепцию bounded clocks, которая похожа на концепт TrueTime из Spanner. Смысл этой концепции в том, чтобы использовать метки времени с разных устройств для упорядочивания транзакций. Проблема в том, что часы на разных машинка время может чуток отклоняться, поэтому приложению нужно несколько параметров: current time (approximate), earliest possible time, latest possible time. А дальше приложение должно подождать немного для того, чтобы точно не выставить транзакции метку времени из прошлого (иначе это может нарушить порядок транзакций в кластере). Эти параметры приложение получает из сервиса EC2 TimeSync с точностью порядка микросекунд. В самой презентации рассказывается как это работает для локальных и распределенных транзакций, а также для выполнения запросов с агрегатами.
- В конце доклада авторы рассказывают про то, как взаимодействуют роутеры и шарды, а также как померить эффективность запросов, какие запросы получают максимальные бенефиты от параллелизации выполнения запросов на разных шардах (создание индексов, вакуум, агрегаты)
- Пока эта limitless версия Aurora доступна через заявку на превью
В общем, это выступление достаточно интересно. Отдельно отмечу, что для получения пользы от этих нововведений надо уметь правильно дизайнить модель данных и понимать как эффективнее разложить данные для того, чтобы максимально часто попадать в конкретные шарды и меньше попадать на распределенные транзакции.
#Software #Architecture #DistributedSystems #SystemDesign #Engineering #Databases