Спонсируемый Реляционные базы данных используются в большинстве мировых приложений, но реляционной модели тоже несколько десятилетий. В традиционных развертываниях РСУБД напряжение начинает проявляться. Традиционные механизмы СУБД, работающие локально в центрах обработки данных клиентов, все чаще сталкиваются с проблемами масштабирования в соответствии с требованиями современных приложений.
Повышенное давление на традиционные реляционные базы данных происходит из-за фундаментальных изменений в приложениях, которые мы создаем. Сегодняшнее программное обеспечение должно обслуживать на порядок больше пользователей, чем это было при первом появлении реляционных баз данных, при сохранении высокой производительности для требовательной аудитории, которая часто распространяется по всему миру. Они должны поддерживать гораздо большее количество подключений от пользовательской базы, которая круглосуточно забивает базу данных запросами. Эти запросы также могут увеличиваться в зависимости от факторов, от сезонных колебаний до краткосрочных деловых событий, не все из которых предсказуемы.
Кроме того, рост объемов данных не показывает никаких признаков остановки. По оценкам аналитической компании IDC, объем цифровых данных во всем мире удвоится через четыре года, а среднегодовой темп роста к 2025 году составит 22,9%. Как пишет Джеффри Хойло, директор программы IDC, «поток данных, с которым приходится бороться каждой компании. из подключенных продуктов, активов, процессов и клиентов, трудно использовать без установленных приложений, которые обеспечивают сопоставление информации и быстрое принятие решений ».
Эти драйверы вынудили Amazon заново изобрести РСУБД для нового поколения веб-приложений в форме Aurora, реляционной базы данных, созданной для облака. Он построен на основе открытого исходного кода, расширяя функциональные возможности MySQL и PostgreSQL для удовлетворения требований современных приложений.
«Наши клиенты все время просили современную базу данных», – объясняет Адитья Самант, старший архитектор решений для баз данных в AWS, добавляя, что базы данных старой гвардии поставлялись с управлением лицензиями и другими условиями. Заказчики хотели легкости и простоты открытого исходного кода с масштабируемостью и производительностью коммерческих механизмов. «Так родилась Aurora. Это база данных, которую мы создали для облака».
Преимущества облачной СУБД
Aurora имеет те же коммерческие преимущества, что и другие управляемые сервисы Amazon, в том, что она не обременяет клиентов высокими лицензионными сборами поставщиков. Вместо этого вы платите по мере использования в зависимости от объема используемых вычислений и хранилища. Вы даже не платите за резервное копирование, пока эти файлы не превышают размер исходной базы данных.
Однако реальное преимущество системы заключается в том, что изначально она была ориентирована на облачные технологии. В отличие от других реляционных баз данных, таких как Oracle и SQL Server, Aurora изначально создавалась для облака. Это позволило Amazon создать код, который использовал преимущества масштабируемости облака и распределенных операций. Это позволяет клиентам по желанию добавлять дополнительные вычислительные ресурсы и емкость хранилища, а также распространять экземпляры по всему миру для обслуживания глобальных пользователей при сохранении производительности.
Одно место, которое проявилось наиболее четко, было в подходе базы данных к уровню хранения. Традиционные реализации СУБД пытались уменьшить узкие места ввода-вывода и повысить производительность с помощью аппаратных разработок, таких как локальные диски NVMe. Это повышает производительность, но по-прежнему оставляет базу данных зависимой от оборудования локального хранилища, которое может выйти из строя.
Amazon хотела разделить вычисления и хранилище, чтобы снизить надежность и накладные расходы на управление при одновременном повышении производительности. Для этого пришлось с нуля переосмыслить подсистему хранения.
Переписываем правила журналами
Команда дизайнеров Авроры сосредоточилась на бревнах. Они всегда были в РСУБД, но они были мерой устойчивости. Реляционные системы работают с данными на страницах, которые они иногда сбрасывают на диск. Журналы копируют эти данные, чтобы база данных могла восстановить страницу, если она была потеряна, до ее очистки.
Использование журналов в качестве средства защиты при сбросе страниц на диск обеспечивает надежность базы данных, но также отрицательно сказывается на производительности сети и ввода-вывода. Запись одной логической транзакции базы данных как часть сброса страницы может включать несколько операций записи на физический диск.
Команда AWS изменила сценарий при разработке Aurora, превратив журналы в основной механизм хранения. База данных собирает журналы в страницы размером 4 КБ, по сравнению с 8 КБ Postgres и 16 КБ MySQL. Эти страницы журнала – единственное, что пересекает границу сети; записываемые данные остаются в памяти. Уровень хранения AWS, созданный для поддержки Aurora, восстанавливает записи данных из журналов в любое время.
Это дает несколько преимуществ. Если базе данных когда-либо потребуется восстановить поврежденные данные, это можно будет сделать в кратчайшие сроки, потому что уровень хранения сделал тяжелую работу. Традиционная СУБД должна будет воспроизводить файлы журнала, чтобы наверстать упущенное. Это также позволяет клиентам разгрузить многие задачи управления базой данных, такие как резервное копирование, исправления и другие административные задачи, связанные с обработкой хранилища, чтобы база данных могла продолжать обслуживать запросы.
Это было ключевым преимуществом для Dow Jones, которая перенесла критически важную рабочую нагрузку по удержанию клиентов на Aurora. У новостной организации была устаревшая система, у которой были проблемы с производительностью, несмотря на ежегодное потребление 400 000 долларов США на навыки администратора базы данных. Перенос рабочей нагрузки в Aurora дал ей 200 транзакций в секунду и автоматическую репликацию для аварийного восстановления, что резко снизило затраты на управление и обеспечило компании необходимую производительность.
Распределенная база данных в облаке
Еще одна вещь, которую облачная архитектура позволила команде Aurora сделать, – это создать действительно распределенную реляционную систему. AWS имеет 24 географических региона, в каждом из которых есть несколько зон доступности. В них находятся десятки дата-центров. Amazon создала сетевые каналы между этими объектами для работы с задержкой в несколько миллисекунд. Компания хотела, чтобы Aurora распределяла свои базы данных по этим зонам, чтобы сделать ее еще более надежной, и поэтому разработала ее для продолжения работы, даже если вся зона выходит из строя, и для быстрого восстановления после более крупных сбоев.
Реляционные системы используют репликацию для повышения устойчивости. Они либо блокируют транзакции до тех пор, пока все реплицированные записи не завершатся успешно (так называемая синхронная репликация), либо позволяют репликации завершиться в своем собственном темпе (так называемая асинхронная репликация). Синхронная репликация может снизить производительность базы данных, если одна из реплицируемых систем медленно отвечает, в то время как асинхронная репликация рискует потерять данные, если произойдет сбой до завершения репликации.
Amazon объединила эти два понятия, используя концепцию кворума. Aurora записывает свои файлы журналов на шесть отдельных узлов в трех зонах доступности в инфраструктуре AWS, но для завершения требуется только четыре записи. Это придает ему устойчивость, необходимую для того, чтобы выдерживать серьезные неудачи. Частично это можно сделать экономно, потому что он только записывает файлы журналов и переносит большую часть управления данными на уровень хранения.
Выбранные узлы, которые не получили обновление, могут наверстать упущенное позже благодаря протоколу консенсуса AWS. При этом используется то, что называется «сплетнями», когда узлы сверяются друг с другом, чтобы определить любые дыры в своих записях данных.
AWS дополнительно защищает Aurora от сбоев, разделяя тома данных на логические блоки по 10 ГБ и реплицируя их для создания шести физических копий, каждая из которых распределена по большой распределенной инфраструктуре. Это позволяет ему быстро восстанавливать любые поврежденные данные путем репликации блока данных 10 ГБ по своей высокоскоростной внутренней сети.
Это предоставляет клиентам высокодоступные базы данных, которые могут автоматически восстанавливаться после сбоев инфраструктуры из-за природных или логических катастроф, позволяя их бизнес-операциям продолжать работу с минимальными нарушениями. Это то, что администраторам баз данных потребовало бы больших усилий для организации с использованием локальной базы данных, но это происходит незаметно в облаке AWS, уменьшая рабочую нагрузку для администраторов баз данных и позволяя им сосредоточиться на оптимизации логики базы данных для большей функциональности.
Читать реплики
Aurora также пользуется преимуществом еще одного повышения производительности в базовой инфраструктуре AWS, что позволяет более эффективно использовать реплики чтения. Эти доступные только для чтения экземпляры базы данных помогают повысить производительность базы данных за счет масштабирования чтения, снижая нагрузку на основной экземпляр Aurora. У вас может быть до 15 из них по сравнению с пятью MySQL, и они служат в качестве автоматизированных целей аварийного переключения с небольшим влиянием на основной.
Реплики Aurora используют файлы журналов по мере их отправки в кворум, сравнивая их содержимое с записями, которые у них уже есть в памяти, и соответствующим образом обновляя их содержимое. Если реплика чтения получает запрос на запись, которой у нее нет в памяти, она берет его из той же подсистемы хранения, в которую записывает база данных Aurora.
Клиенты также могут настроить глобальную базу данных Aurora, чтобы обеспечить более быструю физическую репликацию между кластерами Aurora в разных регионах, а не только в зонах доступности. Это дает вам возможность репликации до пяти вторичных регионов.
Торговая платформа Intuit использует опцию Global Database, чтобы обеспечить доступ только для чтения с малой задержкой к данным, включая информацию о ценах, в разных регионах. Это достигается за счет субсекундной глобальной репликации, которая также отвечает потребностям компании в аварийном восстановлении. Аварийное переключение занимает меньше минуты.
Облачные возможности Aurora позволяют повысить производительность по сравнению с традиционными системами РСУБД в любом масштабе. Amazon заявляет, что он выполняет более чем в пять раз больше запросов SELECT и UPDATE, чем MySQL, выполняющий те же тесты на том же оборудовании.
По словам Саманта, команда Aurora достигла этих успехов, не жертвуя при этом традиционными обязательными элементами СУБД, поясняя, что Amazon добавила инновации в открытый исходный код.
«Итак, если вы написали что-то в коде MySQL, это будет работать для Aurora. Если вы пишете код Postgres, это будет работать для Aurora», – говорит он. «Контракты ACID имеют 100-процентную гарантию, как и в случае с вашими традиционными реляционными базами данных».
Вся тяжелая работа выполняется за кулисами в рамках предложения управляемых баз данных AWS, защищая администраторов баз данных от тяжелой административной работы. Еще одна вещь, от которой их защищает Аврора, – это проблемы с провизией, говорит он. «Разделение вычислений и хранилища позволяет нам быть гибкими, увеличивая и уменьшая масштаб хранилища по мере необходимости», – объясняет он. «Когда вы создаете кластер Aurora, мы даже не спрашиваем вас, сколько памяти вам нужно».
Эволюция Авроры
AWS продолжает развивать Aurora с течением времени, более активно используя собственные облачные функции. Одним из примеров является бессерверная функциональность, которая позволяет масштабировать уровень вычислений по тем же параметрам, что и хранилище. В прошлом году AWS объявила о поддержке Amazon Aurora Serverless v2, которая позволяет масштабировать вычислительные ресурсы без отключения инстанса базы данных.
Бессерверная возможность следующего поколения, которая доступна в общедоступной предварительной версии прямо сейчас, устраняет необходимость переключать экземпляр на другую виртуальную машину, если вам нужно увеличить количество процессоров, чтобы справиться с пиковым количеством транзакций. «Мы думаем, что в большинстве развертываний будет использоваться Aurora Serverless v2», – прогнозирует Самант.
Оглядываясь назад, легко спросить, почему первые разработчики СУБД не использовали приемы из набора инструментов Авроры. Использование файлов журнала в качестве основного механизма записи кажется несложным из-за улучшения производительности. Но тогда облачной инфраструктуры, которая делала это возможным, не было. Базовая инфраструктура для поддержки этой модели будет дорогостоящей даже в современном центре обработки данных, но масштабируемость облака AWS делает его устойчивым. Он также прозрачно и без особых усилий дает администраторам баз данных некоторые из самых больших преимуществ облака, такие как масштабируемость и высокая доступность.
При поддержке AWS.
