Платная функция Перенос собственной локальной базы данных в облако делает вашу инфраструктуру более гибкой. Переход на управляемую базу данных с открытым исходным кодом, о которой заботится поставщик облачных услуг, также экономит вашему администратору базы данных массу работы в долгосрочной перспективе. Однако в краткосрочной перспективе последнее связано с тяжелой работой. А как насчет всех существующих схем и транзакционного кода в вашей существующей установке? Перевод всего этого в новый формат в облаке требует значительных усилий.
До сих пор это могло заставить разработчиков и администраторов баз данных задуматься о переходе на Aurora, облачную реляционную базу данных Amazon Web Services. Разработанная с нуля с учетом облачных вычислений, эта услуга предлагает множество преимуществ, включая высокую доступность по умолчанию, гибкость и простую работу без лицензии.
Облачный гигант уже предлагает свою службу миграции баз данных (DMS), чтобы помочь с переходом, включая инструмент, который упрощает задачу преобразования схем между локальными и управляемыми базами данных. Теперь ожидается, что новая возможность под названием Babelfish значительно упростит этот процесс.
Amazon сравнивает Babelfish с обучением Aurora PostgreSQL диалекту SQL Server в качестве второго языка. Понимая диалект Microsoft SQL Server, Aurora может выполнять свои команды, не имея переводчика посередине. Babelfish гарантирует, что базовая база данных PostgreSQL ведет себя с транзакционной семантикой SQL Server, что значительно упрощает миграцию клиентского приложения.
Результат очень похож на Вавилонскую рыбу в Дугласе Адамсе. Автостопом по Галактике, заключается в том, что приложение, использующее MSSQL, может сделать себя понятным для Aurora, и наоборот. Это должно избавить от многих головных болей.
Головные боли миграции приложений
Инструмент миграции схемы Amazon упрощает перенос базы данных из локальной системы в Aurora. Однако разработчики приложений должны иметь дело с тонкими различиями при переносе своего кода между различными разновидностями реляционной базы данных, такими как PostgreSQL и MSSQL.
Например, типы данных в PostgreSQL и MSSQL могут тонко различаться, даже если они идентичны по имени. Это связано с тем, что поставщики часто разрабатывают свои типы данных, превышающие стандарты ANSI, чтобы предоставить своим клиентам больше функциональных возможностей.
Программист, работающий с типом данных Money в MSSQL, столкнется с проблемами при переходе на PostgreSQL. В базе данных Microsoft он имеет четырехзначную точность. В Postgres их всего два. Это может привести к изменениям в способах работы приложений, которые не всегда могут появиться без тщательного тестирования. Некоторые типы данных, существующие в одной базе данных, могут вообще не существовать в других, что требует серьезной работы по рефакторингу на стороне приложения.
Другая проблема возникает с транзакционной семантикой. MSSQL обрабатывает некоторые транзакционные аспекты иначе, чем [than?] Postgres. При вставке строк данных в таблицу и возникновении ошибки «дублированный ключ» первый откатит только оператор SQL, в котором возникла ошибка, но сохранит транзакцию открытой. PostgreSQL менее снисходителен и откатит всю транзакцию при обнаружении повторяющегося ключа. Это может повлиять на поведение приложения и привести к другим результатам во время выполнения.
Разработчики также быстро столкнутся с проблемами синтаксиса языка в своей базе данных. У каждого есть свой вариант языка, который часто отличается от стандартного SQL. Диалект Microsoft TSQL отличается от PostgreSQL, который предлагает собственный язык PL / pgSQL. Оба они являются процедурными языками, включая конструкции, которые позволяют базе данных возвращать сложные типы данных, но они включают в себя различные языковые примитивы.
Разработчики обычно используют инструменты преобразования синтаксиса для решения этой проблемы, автоматически генерируя код для устранения разрыва между языком одной базы данных и языком другой. Однако у этого есть недостатки. Это затрудняет чтение кода, особенно если он уже был автоматически сгенерирован инструментом объектно-реляционного управления (ORM). Это, в свою очередь, затрудняет проверку кода, особенно если исходного кодировщика больше нет. Более того, это может нарушить существующие спецификации кодирования организации.
Еще один способ преодолеть весь этот запутанный беспорядок – это перепроектировать вещи на стороне приложения. Однако это серьезное мероприятие, включающее переписывание и тестирование уже находящихся в производстве систем, которые могут иметь несколько зависимостей. Это было бы не так уж плохо, если бы вы работали с модульной средой на основе микросервисов, но компании, переходящие на Aurora, еще не всегда будут на этом этапе и будут работать с традиционными монолитными приложениями.
Снижение трений в процессе миграции базы данных
Amazon приложил все усилия, чтобы облегчить этот процесс миграции с помощью DMS и инструмента преобразования схем (SCT). После того, как клиент выбрал приложение для миграции, DMS помогает перенести приложение как есть в версию, которая может взаимодействовать с Aurora. AWS использует свой SCT для анализа устаревшего кода доступа к базе данных и оценки времени, которое потребуется для его миграции в среду Aurora, что дает дополнительное время для таких сложностей, как хранимые процедуры. Если у вас есть несовместимость между кодом вашей проприетарной базы данных и базой данных с открытым исходным кодом, компания предоставит экспертов для консультации с вами.
Babelfish – это попытка компании упростить и улучшить этот процесс, чтобы упростить миграцию для клиентов. Это возможность Aurora, которая понимает язык MSSQL и может выполнять команды непосредственно в PostgreSQL, обрабатывая соответствующие преобразования типов данных и заботясь о примитивах языка MSSQL при взаимодействии с Aurora.
Ваше приложение MSSQL все еще думает, что обращается к базе данных Microsoft, но вы указали его на сервер Babelfish, который понимает большую часть языка MSSQL и отвечает соответствующим образом. И что Amazon подразумевает под «большинством»?
В качестве ответа компания привела нам следующую аналогию: представьте, что вы американец из Амстердама. Большинство жителей свободно говорят по-английски и поймут, что вы говорите, что облегчает посещение города или проживание в нем. Иногда вы будете использовать английское слово или американский сленг, которые люди не поймут, и вам, возможно, придется использовать другое слово, чтобы донести свою идею. В конце концов, английский – второй или третий язык для большинства голландцев в Амстердаме.
Amazon заявляет, что такая двуязычная способность сократит время разработки для клиентов, которые перейдут к управляемой реляционной облачной базе данных. На практике часто приходится выполнять некоторую работу заранее. Вам необходимо определить, какие типы данных использует ваше приложение, а затем убедиться, что на сервере Babelfish установлены соответствующие расширения.
Мурали Брахмадесам, директор по программному обеспечению Aurora в Amazon, обещает серьезные преимущества от Babelfish. Система позволяет разработчикам использовать объекты MSSQL через интерфейс PostgreSQL, что упрощает развертывание существующих приложений, сохраняя при этом большую часть кода.
«Babelfish сократит объем кода, который необходимо переписать, на 90 процентов или более для большинства приложений», – говорит Мурали. Это также означает, что это сократит время разработки приложений, говорит он, позволяя клиентам быстрее переходить в облако и устраняя необходимость изменять тесты кода или клиентские драйверы. «Вместо года на перенос приложения с SQL Server на PostgreSQL, вы можете сделать это в гораздо более короткие сроки, возможно, за один или два месяца», – говорит он.
Переключение с помощью Babelfish
Исходный код Babelfish будет открыт на GitHub с лицензией Apache 2.0, чтобы компании могли размещать свои собственные версии, но AWS также будет предлагать его как управляемую услугу. Компания обновляет свой инструмент преобразования схемы, чтобы определить, какая часть схемы базы данных клиента поддерживает Babelfish, и оснастит SCT автоматическим внесением изменений в существующий код базы данных или предоставлением рекомендаций группе разработчиков.
«Инструменты останутся прежними, но качество обслуживания клиентов улучшится, – говорит Мурали.
Преимущество подключения к Babelfish заключается в том, что клиенты получают удобство посменной миграции, но с преимуществами управляемой базы данных. Они могут перейти на облачный движок базы данных, но ничего не меняя в своем стеке приложений, пока они не будут готовы. По словам Мурали, вы даже можете оставить свое приложение локально, если хотите, уменьшив задержку доступа с помощью сервиса Amazon Direct Connect.
Он добавляет, что ускоренный переход понравится клиентам, стремящимся сегодня избежать драконовских лицензионных сборов за проприетарные базы данных, не вкладывая средства в крупный проект рефакторинга.
«Теперь у них есть полный контроль над модификациями приложений в их собственном графике», – говорит он. «Они могут продолжить разработку на TSQL, используя Babelfish, если захотят, но со временем они могут перейти на pgSQL, если захотят – они могут решить, что более удобно».
Разработчики по-прежнему могут добавлять облачные функции на стороне Aurora. База данных может вызывать лямбды при вставке записей, что позволяет разработчикам расширять ее функциональные возможности с помощью бессерверных функций в облаке AWS без изменения существующего стека приложений. Они могут проводить транзакции, используя интерфейс и схему базы данных, к которой они привыкли, через клиентский драйвер MSSQL, и вызывать лямбды для дополнительной функциональности на стороне Aurora. В качестве примера использования Murali приводит интеграцию с сервисом машинного обучения AWS Sagemaker.
Babelfish от Amazon будет поддерживать разработчиков приложений, которые видят ценность перехода на альтернативный механизм баз данных, но беспокоятся о переносе своей бизнес-логики. Это упрощает процесс адаптации, снижает трение и позволяет клиентам лучше подготовиться к переходу.
Эта статья спонсируется AWS.
