Здравствуйте, хабровчане.
Занятия в первой группе курса начинаются сегодня.
В связи с этим мы хотели бы рассказать вам о том, как проходил открытый вебинар по данному курсу.
В следующий открытый урок мы говорили о проблемах, с которыми сталкиваются базы данных SQL в эпоху облаков и Kubernetes. В то же время мы рассмотрели, как базы данных SQL адаптируются и мутируют под влиянием этих проблем.
Вебинар состоялся Валерий Безруков , менеджер по внедрению облачных технологий Google в EPAM Systems.
Когда деревья были маленькими.
Для начала вспомним, как начался выбор СУБД в конце прошлого века.
Однако это не составит труда, ведь выбор СУБД в те времена начинался и заканчивался Оракул .
В конце 90-х и начале 2000-х годов выбора промышленных масштабируемых баз данных практически не было.
Да, приходили и уходили IBM DB2, Sybase и некоторые другие базы данных, но в целом они были не так заметны на фоне Oracle. Соответственно, навыки инженеров того времени как-то были привязаны к единственному существовавшему выбору.
Администратор базы данных Oracle должен был уметь: установить Oracle Server из дистрибутива; настроить сервер Oracle: инициализация.
ора; слушатель.
ора; - создавать: табличные пространства; схема; пользователи; — выполнять резервное копирование и восстановление; — осуществлять мониторинг; — работать с неоптимальными запросами.
При этом особых требований со стороны Oracle DBA не было: уметь выбрать оптимальную СУБД или другую технологию хранения и обработки данных; обеспечить высокую доступность и горизонтальную масштабируемость (это не всегда было проблемой администратора базы данных); хорошее знание предметной области, инфраструктуры, архитектуры приложений, ОС; загружать и выгружать данные, мигрировать данные между разными СУБД.
В целом, если говорить о выборе в те времена, то он напоминает выбор в советском магазине конца 80-х: 
Настоящее время
С тех пор, конечно, деревья выросли, мир изменился и стал примерно таким:Рынок СУБД тоже изменился, что хорошо видно из последнего отчета Gartner:
И здесь следует отметить, что облака, популярность которых растет, заняли свою нишу.
Если мы прочитаем тот же отчет Gartner, то увидим следующие выводы: Многие клиенты находятся на пути переноса приложений в облако.
Новые технологии сначала появляются в облаке и не факт, что они когда-нибудь перейдут в необлачную инфраструктуру.
Модель ценообразования с оплатой по факту использования стала обычным явлением.
Каждый хочет платить только за то, чем пользуется, и это даже не тенденция, а просто констатация факта.
Что теперь?
Сегодня мы все в облаке.И вопросы, которые у нас возникают, — это вопросы выбора.
И это огромно, даже если говорить только о выборе технологий СУБД в формате On-premises. У нас также есть управляемые услуги и SaaS. Таким образом, с каждым годом выбор становится только сложнее.
Наряду с вопросами выбора существуют также ограничивающие факторы : цена .
Многие технологии по-прежнему стоят денег; навыки .
Если мы говорим о свободном программном обеспечении, то возникает вопрос о навыках, поскольку свободное программное обеспечение требует достаточной компетентности от людей, которые его развертывают и эксплуатируют; функциональный .
Не все сервисы, доступные в облаке и построенные, скажем, даже на том же Postgres, обладают теми же возможностями, что и Postgres On-premises. Это важный фактор, который необходимо знать и понимать.
Более того, этот фактор становится более важным, чем знание некоторых скрытых возможностей отдельной СУБД.
Что ожидается от DA/DE сейчас: хорошее понимание предметной области и архитектуры приложения; умение правильно выбрать подходящую технологию СУБД с учетом поставленной задачи; возможность выбора оптимального метода реализации выбранной технологии в условиях существующих ограничений; возможность выполнения переноса и миграции данных; способность внедрять и использовать выбранные решения.
Ниже пример на основе GCP демонстрирует, как работает выбор той или иной технологии работы с данными в зависимости от их структуры: 
Обратите внимание, что PostgreSQL не включен в схему, и это потому, что он скрыт под терминологией Облачный SQL .
И когда мы доберемся до Cloud SQL, нам снова нужно будет сделать выбор: 
Следует отметить, что этот выбор не всегда однозначен, поэтому разработчики приложений часто руководствуются интуицией.
Общий: Чем дальше, тем актуальнее становится вопрос выбора.
И даже если смотреть только на GCP, управляемые сервисы и SaaS, то некоторое упоминание о СУБД появляется только на 4-м шаге (а там Spanner рядом).
Плюс на 5 шаге появляется выбор PostgreSQL, а рядом еще MySQL и SQL Server, то есть всего много, но надо выбирать .
Нельзя забывать об ограничениях на фоне искушений.
В основном всем нужен гаечный ключ, но он дорогой.
В результате типичный запрос выглядит примерно так: «Пожалуйста, сделайте нам Spanner, но по цене Cloud SQL вы профессионалы!»
Что я должен делать?
Не претендуя на истину в последней инстанции, скажем следующее: Нам необходимо изменить наш подход к обучению: нет смысла преподавать так, как раньше учили администраторов баз данных; знания одного продукта уже недостаточно; но знать десятки на уровне единицы невозможно.Вам необходимо знать не только и не сколько стоит товар, а: вариант использования его применения; разные методы развертывания; преимущества и недостатки каждого метода; аналогичные и альтернативные товары, чтобы сделать осознанный и оптимальный выбор, причем не всегда в пользу знакомого товара.
Вам также необходимо уметь переносить данные и понимать основные принципы интеграции с ETL.
Реальный случай
В недавнем прошлом возникла необходимость создать бэкенд для мобильного приложения.К моменту начала работы над ним бэкенд уже был разработан и готов к внедрению, а команда разработчиков потратила на этот проект около двух лет. Были поставлены следующие задачи: построить CI/CD; просмотреть архитектуру; ввести все это в эксплуатацию.
Само приложение представляло собой микросервисы, а код Python/Django разрабатывался с нуля и непосредственно в GCP. Что касается целевой аудитории, то предполагалось, что будет два региона — США и ЕС, а трафик распределялся через Global Loadbalancer. Все рабочие нагрузки и вычислительная нагрузка выполнялись на Google Kubernetes Engine. Что касается данных, то было 3 структуры: Облачное хранилище; Хранилище данных; Облачный SQL (PostgreSQL).
Можно задаться вопросом, почему был выбран Cloud SQL? Честно говоря, такой вопрос в последние годы вызвал какую-то неловкую паузу - есть ощущение, что люди стали стесняться реляционных баз данных, но тем не менее продолжают их активно использовать ;-).
Что касается нашего случая, Cloud SQL был выбран по следующим причинам: Как уже упоминалось, приложение было разработано с использованием Django и имеет модель сопоставления постоянных данных из базы данных SQL с объектами Python (Django ORM).
Сам фреймворк поддерживал довольно ограниченный список СУБД: ПостгреСБЛ; МарияДБ; MySQL; Оракул; SQLite. Соответственно, из этого списка довольно интуитивно был выбран PostgreSQL (ну не Oracle выбирать, правда).
Чего не хватало: приложение было развернуто только в 2-х регионах, а в планах появился 3-й (Азия); База данных располагалась в североамериканском регионе (Айова); со стороны заказчика были опасения по поводу возможного задержки доступа из Европы и Азии и перерывы в сервисе в случае простоя СУБД.
Несмотря на то, что сам Django может работать с несколькими базами данных параллельно и разделять их на чтение и запись, записи в приложении было не так много (более 90% — чтение).
И вообще, и вообще, если бы можно было сделать чтение-реплика основной базы в Европе и Азии , это было бы компромиссное решение.
Ну и что тут сложного? Сложность заключалась в том, что заказчик не хотел отказываться от использования управляемых сервисов и Cloud SQL. А возможности Cloud SQL на данный момент ограничены.
Cloud SQL поддерживает высокую доступность (HA) и реплику чтения (RR), но один и тот же RR поддерживается только в одном регионе.
Создав базу данных в американском регионе, вы не сможете сделать реплику чтения в европейском регионе с помощью Cloud SQL, хотя сам Postgres не мешает вам это сделать.
Переписка с сотрудниками Google ни к чему не привела и закончилась обещаниями в стиле «мы знаем проблему и работаем над ней, когда-нибудь вопрос будет решен».
Если кратко перечислить возможности Cloud SQL, то это будет выглядеть примерно так: 1. Высокая доступность (HA): в пределах одного региона; через репликацию диска; Движки PostgreSQL не используются; возможно автоматическое и ручное управление - аварийное переключение/восстановление; При переключении СУБД недоступна несколько минут. 2. Чтение реплики (RR): в пределах одного региона; горячий резерв; Потоковая репликация PostgreSQL. Кроме того, как принято, при выборе технологии всегда сталкиваешься с некоторыми ограничения : заказчик не хотел создавать сущности и использовать IaaS, кроме как через GKE; заказчик не желает самостоятельно развертывать PostgreSQL/MySQL; Ну в целом Google Spanner вполне бы подошел, если бы не его цена, однако Django ORM с ним работать не может, но это и хорошо.
Учитывая ситуацию, заказчику был задан уточняющий вопрос: «Можете ли вы сделать что-то подобное, чтобы оно было похоже на Google Spanner, но при этом работало с Django ORMЭ»
Вариант решения №0
Первое, что пришло на ум: оставаться в CloudSQL; не будет встроенной репликации между регионами ни в каком виде; попробуйте прикрепить реплику к существующему Cloud SQL от PostgreSQL; запустить экземпляр PostgreSQL где-нибудь и как-нибудь, но хотя бы не трогать master. Увы, оказалось, что этого сделать нельзя, так как нет доступа к хосту (он вообще в другом проекте) — pg_hba и так далее, а также нет доступа под суперпользователем.
Вариант решения №1
После дальнейшего размышления и принимая во внимание предыдущие обстоятельства ход мыслей несколько изменился: Мы по-прежнему пытаемся оставаться в рамках CloudSQL, но переходим на MySQL, поскольку у Cloud SQL by MySQL есть внешний мастер, который: — является прокси для внешнего MySQL; - выглядит как экземпляр MySQL; — изобретен для переноса данных из других облаков или локально.Так как для настройки MySQL-репликации не требуется доступ к хосту, то в принципе все работало, но было очень нестабильно и неудобно.
А когда мы пошли дальше, стало совсем страшно, потому что мы развернули всю структуру терраформом, и вдруг оказалось, что внешний мастер не поддерживается терраформом.
Да, у Google есть CLI, но здесь почему-то все работало то и дело — иногда создается, иногда не создается.
Возможно потому, что CLI был придуман для внешней миграции данных, а не для реплик.
Собственно, в этот момент стало понятно, что Cloud SQL совершенно не подходит. Как говорится, мы сделали все, что могли.
Вариант решения №2
Поскольку остаться в рамках Cloud SQL не удалось, мы попытались сформулировать требования к компромиссному решению.Требования оказались следующими: работа в Kubernetes, максимальное использование ресурсов и возможностей Kubernetes (DCS,.
) и GCP (LB,.
); отсутствие балласта от кучи ненужных вещей в облаке типа HA proxy; возможность запуска PostgreSQL или MySQL в основном регионе HA; в других регионах - ХА из РР основного региона плюс его копия (для надежности); мультимастер (не хотелось с ним связываться, но это было не очень важно) .
В результате этих требований п.
подходящие СУБД и варианты привязки : MySQL Галера; ТараканДБ; Инструменты PostgreSQL : - пгпул-II; — Патрони.
MySQL Галера
Технология MySQL Galera была разработана Codership и представляет собой плагин для InnoDB. Особенности: мультимастер; синхронная репликация; чтение с любого узла; запись на любой узел; встроенный механизм высокой доступности; Есть диаграмма Хелма от Битнами.
ТараканДБ
По описанию вещь абсолютно бомбическая и представляет собой проект с открытым исходным кодом, написанный на Go. Главный участник — Cockroach Labs (основана людьми из Google).Эта реляционная СУБД изначально проектировалась как распределенная (с горизонтальным масштабированием «из коробки») и отказоустойчивая.
Его авторы из компании обозначили цель «объединить богатство функциональности SQL с горизонтальной доступностью, знакомой NoSQL-решениям».
Приятный бонус — поддержка протокола подключения post-gress.
Пгпул
Это надстройка к PostgreSQL, по сути, новая сущность, которая берет на себя все соединения и обрабатывает их.Имеет собственный балансировщик нагрузки и парсер, лицензированный по лицензии BSD. Оно предоставляет широкие возможности, но выглядит несколько устрашающе, ведь присутствие новой сущности может стать источником некоторых дополнительных приключений.
Патрони
Это последнее, на что упал мой взгляд, и, как оказалось, не зря.Patroni — это утилита с открытым исходным кодом, которая по сути представляет собой демон Python, позволяющий автоматически обслуживать кластеры PostgreSQL с различными типами репликации и автоматическим переключением ролей.
Вещь оказалась очень интересной, так как хорошо интегрируется с кубером и не вносит никаких новых сущностей.
Что вы выбрали в итоге?
Выбор был непростым: ТараканДБ - огонь, но темно; MySQL Галера - тоже неплохо, используется во многих местах, кроме MySQL; Пгпул — много ненужных сущностей, интеграция с облаком и К8с так себе; Патрони - отличная интеграция с K8s, нет лишних сущностей, хорошо интегрируется с GCP LB. Таким образом, выбор пал на Патрони.
выводы
Пришло время подвести краткие итоги.Да, мир ИТ-инфраструктуры существенно изменился, и это только начало.
И если раньше облака были просто еще одним видом инфраструктуры, то теперь все по-другому.
Более того, инновации в облаках появляются постоянно, они будут появляться и, возможно, появятся только в облаках и только потом усилиями стартапов будут перенесены на On-premises. Что касается SQL, SQL будет жить.
Это значит, что вам необходимо знать PostgreSQL и MySQL и уметь с ними работать, но еще важнее уметь их правильно использовать.
Теги: #облачные сервисы #postgresql #sql #MySQL
-
Асит 2 Шага
19 Oct, 24 -
Если Seagate Запылится...
19 Oct, 24 -
Обучение Через Обмен Наблюдениями
19 Oct, 24 -
Любопытство Приведет К Sdk
19 Oct, 24
