Привет, я - Алмаз Мустакимов, ведущий разработчик одного из бизнес-центров в компании «БАРС Груп». Мы более года работаем над мобильным приложением, которое фактически позволяет получить любые услуги здравоохранения в режиме единого окна, без многочасовых квестов по поликлиникам.
Несмотря на общую популярность и тренд, Massive Parallel Processing (MPP) РСУБД всё ещё очень редко используются для целей автоматизации маркетинга (платформы aCRM). Часто быстрее и удобнее использовать классическую РСУБД. Однако рано или поздно организации приходят к тому, что вертикальное масштабирование уже не спасает, а бизнес продолжает расти.
В рамках данной статьи хотим поделиться опытом использования Massive Parallel Processing (MPP) РСУБД на примере GreenPlum в проекте внедрения платформы aCRM для автоматизации маркетинговых процессов в крупном Retail.
С этого сообщения в мессенджере началось мое масштабное расследование вопроса, который давно не дает спать многим айтишникам — можно ли вот так взять и переехать с Oracle на «свободную» СУБД PostgreSQL?
Этот вопрос сначала бередил умы только тех, кто был в курсе стоимости закупок лицензий. В крупных компаниях бюджет на это мог составлять несколько десятков миллионов долларов. А потом каждый год поддержка вендора «съедала» ещё 22% от стоимости лицензий. Теперь та финансовая боль сменилась другой, и у компаний поменялся запрос: а можно ли заменить? И главное, можно ли организовать это в разумные сроки и по адекватной стоимости?
Скажу сразу, что в этом посте не будет технических аспектов миграции с СУБД Oracle на PostgreSQL. Как это делать и как обходить сложности — разберем в следующий раз. Тут же больше поговорим о целесообразности и возможности миграции. С этим мы разбирались в ходе одного проекта, а заодно развенчали строй существующих иллюзий.
Эта статья завершает цикл о миграции с СУБД Oracle на СУБД PostgreSQL. В первых двух статьях рассматривались проблемы и устоявшиеся способы переноса данных из одной СУБД в другую (часть 1, часть 2). В третьей статье была представлена часть особенностей, которые нужно учесть при переводе хранимого кода с PL/SQL на PL/pgSQL. В сегодняшнем материале рассматривается оставшаяся часть особенностей, адаптация и конвертация кода, включая выбор средств для конвертации.
Глобальные структуры данных уровня пакета
Для таких структур рекомендуется использовать модуль pg_variables. Он позволяет сохранять как скалярные значения, так и множество записей, массивы
При этом нужно понимать, требуется ли собирать статистику для планировщика. Если да, то придётся пользоваться временными таблицами. По возможности, их лучше не использовать слишком интенсивно. Создание и удаление временных таблиц ведёт к изменениям в системном каталоге и сообщениям об инвалидации. Может возникнуть ситуация, когда серверным процессам для своей работы придётся многократно перечитывать системный каталог.
Пример: у одного клиента процессы Postgres тратили большое количество времени на планирование запросов, поскольку они многократно пытались прочитать данные pg_statistic и pg_class и при этом взять соответствующие блокировки на самые распространённые объекты. Соответственно, от создания и удаления временных таблиц на каждую транзакцию пришлось отказаться.
pg_variables можно использовать на реплике – работа с модулем не приводит к изменениям в системном каталоге. Временные таблицы использовать не получится, поскольку реплика не позволяет делать изменения в словаре данных.
В предыдущих статьях о миграции с Oracle на Postgres мы рассматривали перенос данных из одной системы управления базами данных в другую (часть 1, часть 2). Сегодня разговор пойдёт об особенностях работы с кодом приложения при необходимости смены СУБД. В частности, будут рассмотрены следующие вопросы:
Пройдя много собеседований, выяснилось, что довольно приличная часть собеседующих, спрашивавших или как-то затрагивавших тему транзакций и их работы, не знают как работают транзакции и что означает для разработчика термин изоляция. Вплоть до архитектора в одной очень большой российской компании, для которого выводы, использованные мною для формулирования решения при прохождении архитектурной секции оказались чем-то вроде бреда. Пока готовится вторая статья (Миллиард абитуриентов МИРЭА 2), можно отвлечься и разобрать тему, продемонстрировать разработчикам что означает для них I в ACID.
Все об использовании шаблонов в Airflow с примерами кода. Продолжение серии публикаций astronomer.io
Меня зовут Якупов Азат, я дата-архитектор Quadcode, и с вами продолжение саги о типах таблиц в PostgreSQL. В этой части речь пойдёт про кластеризованные, внешние, партицированные и наследуемые таблицы. Посмотрим на примеры их создания, области применения, плюсы и минусы их использования.
Поскольку Airflow — это на 100% код, знание основ Python - это все, что нужно, чтобы начать писать DAG. Однако написание эффективных, безопасных и масштабируемых DAG требует учета некоторых моментов, специфичных для Airflow. В этом разделе мы рассмотрим некоторые передовые методы разработки DAG, которые максимально используют возможности Airflow.
В целом, большинство лучших практик, которые мы здесь рассматриваем, относятся к одной из двух категорий:
В предыдущей статье, была рассмотрена модель данных, необходимая для хранения информации об абитуриентах. Теперь пришло время показать, как используя реляционные БД можно обрабатывать модифицирующие запросы от миллиарда абитуриентов. А что бы расставить все точки над i, предлагаемая архитектура должна обрабатывать миллион модифицирующий запросов в секунду. Используя реляционные БД, гарантировать, что все возможные комбинации обрабатываются за сутки для миллиарда абитуриентов, каждому из которых предоставляется 20 вариантов! С ростом числа абитуриентов требования по железу должны рости линейно.
В дни майского HighLoad++ Foundation 2022 наша компания объявила о выпуске Postgres Pro Enterprise 14.2.1. С тех пор вышло несколько обновлений, мы расскажем о наиболее свежем из них - Postgres Pro Enterprise 14.4.1, основанном на PostgreSQL 14.4. Этот выпуск включает все новые возможности, появившиеся в PostgreSQL 14, а также исправления ошибок, вошедшие в недавние корректирующие выпуски PostgreSQL. В данной статье мы рассмотрим ключевые возможности Postgres Pro Enterprise 14.4.1 и «ванильной» СУБД PostgreSQL, также доступные пользователям нашего форка.
Операторы являются основными строительными блоками DAG Airflow. Это классы, которые содержат логику выполнения единичной работы.
Вы можете использовать операторы в Airflow, создав их экземпляры в задачах. Задача определяет работу, выполняемую оператором в контексте DAG.
Чтобы просмотреть и выполнить поиск по всем доступным операторам в Airflow, посетите Astronomer Registry. Ниже приведены примеры операторов, которые часто используются в проектах Airflow.
В PostgreSQL существует большое количество разных типов таблиц. Каждая из них предназначена для решения конкретных задач. Самая распространённая и известная — heap table или стандартная таблица. Про её структуру я рассказывал в прошлой статье. Стандартная таблица позволяет хранить строки, обновлять данные, делать OLAP и OLTP-запросы.
Тем не менее, существует ещё целый ряд таблиц, про которые просто забывают. На мой взгляд, интересные таблицы сейчас — это нежурналируемые и временные таблицы. В этой статье мы поговорим именно про них и сравним их с журналируемыми таблицами.
Полное руководство по созданию DAG в Apache Airflow DAG, позволяющих создать конвейер данных из разных источников, запускаемый в определенные периоды времени с заданной логикой. Первая часть. Источник: DAGs: The Definitive Guide от astronomer.io
Добро пожаловать в полное руководство по Apache Airflow DAG, представленное командой Astronomer. Эта электронная книга охватывает все, что вам нужно знать для работы с DAG, от строительных блоков, из которых они состоят, до рекомендаций по их написанию, динамической генерации, тестированию, отладке и многому другому. Это руководство, написанное практикующими для практикующих.
GreenPlum — популярное решение для масштабных аналитических систем и в небольших стартапах, и в крупных корпорациях. Оно предлагает понятный пользователям синтаксис ANSI SQL, хорошо ложится на облачный ландшафт, позволяет обучать и применять модели машинного обучения, а ещё поддерживает реляционную СУБД PostgreSQL. В статье поговорим, как связаны GreenPlum и PostgreSQL, разберём их сходства и отличия.
Разбираем интересный кейс использования Google Sheets API и Google Drive API на Python - подписываемся на изменения в Google-таблице и ведем по ним таблицу в СУБД PostgreSQL.
Вместе пройдем трек от создания сервисного аккаунта Google и копирования таблицы-источника до отслеживания изменений в ней с помощью планировщика.
Август в релизном цикле PostgreSQL месяц особенный. Еще не вышла официально 15-я версия, но уже закончился первый коммитфест 16-й версии. И мы можем посмотреть на самые интересные изменения.
Собираем сервер из исходного кода и вперед!
\dconfig server_versionList of configuration parameters
Parameter | Value
----------------+---------
server_version | 16devel