SQL *

Эта статья завершает цикл о миграции с СУБД Oracle на СУБД PostgreSQL. В первых двух статьях рассматривались проблемы и устоявшиеся способы переноса данных из одной СУБД в другую (часть 1, часть 2). В третьей статье была представлена часть особенностей, которые нужно учесть при переводе хранимого кода с PL/SQL на PL/pgSQL. В сегодняшнем материале рассматривается оставшаяся часть особенностей, адаптация и конвертация кода, включая выбор средств для конвертации.

Глобальные структуры данных уровня пакета

Для таких структур рекомендуется использовать модуль pg_variables. Он позволяет сохранять как скалярные значения, так и множество записей, массивы

При этом нужно понимать, требуется ли собирать статистику для планировщика. Если да, то придётся пользоваться временными таблицами. По возможности, их лучше не использовать слишком интенсивно. Создание и удаление временных таблиц ведёт к изменениям в системном каталоге и сообщениям об инвалидации. Может возникнуть ситуация, когда серверным процессам для своей работы придётся многократно перечитывать системный каталог.

Пример: у одного клиента процессы Postgres тратили большое количество времени на планирование запросов, поскольку они многократно пытались прочитать данные pg_statistic и pg_class и при этом взять соответствующие блокировки на самые распространённые объекты. Соответственно, от создания и удаления временных таблиц на каждую транзакцию пришлось отказаться.

pg_variables можно использовать на реплике – работа с модулем не приводит к изменениям в системном каталоге. Временные таблицы использовать не получится, поскольку реплика не позволяет делать изменения в словаре данных.

В предыдущих статьях о миграции с Oracle на Postgres мы рассматривали перенос данных из одной системы управления базами данных в другую (часть 1, часть 2). Сегодня разговор пойдёт об особенностях работы с кодом приложения при необходимости смены СУБД. В частности, будут рассмотрены следующие вопросы:

Всем привет! Меня зовут Хусрав, я бэкенд разработчик в компании Bimeister.

В этой статье я бы хотел бы поговорить о способе поиска родительских и дочерних элементов структуры посредством PostgreSQL Materialized Path.

Статья является вводной и рассчитана на людей, незнакомых с темой.

Простой и декларативный способ выполнять SQL запросы в JUnit тестах.

Есть вещи, которые не нравятся, есть вещи, которые бесят, есть вызывающие жгучий гнев, и есть ситуация с NULL в SQL.

Давайте немножко похоливарим по этому поводу.

В продолжение статей Приключения при настройке сервисов машинного обучения в MS SQL Server 2019 и Используем R lang в SQL Server разбираемся как работать с Python в сервисам машинного обучения. С Python ситуация несколько лучше, чем с R, так как достаточно много предустановленных библиотек и версия Python не так сильно отстает от актуальной, как в случае с R.

Для работы с Python крайне важно писать код без отступов, что достаточно нетривиально, так как код вы пишите в SQL строке.

Для разбора примеров используется созданная в статье про R база данных с датасетом из соревнования Kaggle Титаник.

Август в релизном цикле PostgreSQL месяц особенный. Еще не вышла официально 15-я версия, но уже закончился первый коммитфест 16-й версии. И мы можем посмотреть на самые интересные изменения.

Собираем сервер из исходного кода и вперед!

\dconfig server_version

List of configuration parameters
   Parameter    |  Value  
----------------+---------
 server_version | 16devel

Поскольку тема «переезда» c СУБД Oracle на СУБД Postgres не теряет актуальности, продолжаем наш цикл о миграции. Это вторая статья о переносе данных из Oracle в Postgres (первая доступна по ссылке). На этот раз мы подробнее остановимся на секционировании и временных таблицах, а такжe рассмотрим существующий инструментарий для конвертации данных и сокращения времени простоя.

IOT-таблицы в Oracle

В СУБД Oracle есть так называемые IOT-таблицы, Index-Organized Tables. В обычных таблицах данные хранятся в любом порядке. IOT-таблицы хранят данные в структуре B-tree, которая логически отсортирована в порядке, указанном в полях первичного ключа. Данные лежат в листьях индекса и при его обходе и извлечении данных последние будут упорядочены. Стоит отметить, что этот порядок сохраняется. После добавления, обновления или удаления записей данные всё равно будут упорядочены.

Обычно два входных набора данных классифицируются как левый и правый на основе их расположения по отношению к пункту/оператору Join.

Очень часто приходится слышать, что Sqoop — это серебряная пуля для загрузки данных большого объёма с реляционных БД в Hadoop, особенно с Oracle, и Spark-ом невозможно достигнуть такой производительности. При этом приводят аргументы, что sqoop — это инструмент, заточенный под загрузку, а Spark предназначен для обработки данных.

Меня зовут Максим Петров, я руководитель департамента "Чаптер инженеров данных и разработчиков", и я решил написать инструкцию о том, как правильно и быстро загружать данные Spark, основываясь на принципах загрузки Sqoop.

Первичное сравнение технологий

В нашем примере будем рассматривать загрузку данных из таблиц OracleDB.

Рассмотрим случай, когда нам необходимо полностью перегрузить таблицу/партицию на кластер Hadoop c созданием метаданных hive.

В PostgreSQL есть "волшебный" тип индекса GiST, который позволяет быстро искать разные сложные вещи - от интервалов до массивов и даже реализовывать полнотекстовый поиск.

Про его внутреннее устройство и возможности подробно рассказывал Егор Рогов, а я в статье "PostgreSQL Antipatterns: работаем с отрезками в «кровавом энтерпрайзе»" показал, как с помощью расширения btree_gist он позволяет решать типовые бизнес-задачи.

Одной из таких задач является поиск отрезков внутри сегмента со скалярным идентификатором. И если для btree очевидно, что поле с меньшей кардинальностью должно стоять в индексе раньше - индекс от этого и меньше и быстрее (см. "DBA: находим бесполезные индексы"), то так ли это однозначно для btree_gist?

За два года с момента релиза GPT-3 эту языковую модель использовали в множестве интересных задач — например, для сочинения поэзии, написания футурологических эссе и подготовки научных статей. Но как алгоритм обработки естественного языка может быть полезен программистам?

На этот вопрос в своей новой статье отвечает британский разработчик Саймон Уиллисон* — директор по архитектуре Eventbrite и один из создателей веб-фреймворка Django. Среди различных вариантов применения языковой модели GPT-3 Уиллисон особенно подчеркивает ее способность объяснять, что делает код. По словам специалиста, в этом GPT-3 поразительно эффективна, поскольку явно обучалась на огромном количестве исходного кода.

Под катом — наш перевод материала, в котором автор демонстрирует недавние примеры из своей практики: объяснение кода на Python, JavaScript, SQL, а также работу в рамках GPT-3 с математическими формулами.

*Обращаем ваше внимание, что позиция автора не всегда может совпадать с мнением МойОфис.

Недавно нам прилетело большое тестовое задание от Тиньков-Банка на должность аналитика данных. Там очень много задач, но сегодня мы разберем несколько — остановимся на мелочах и обратим внимание на тонкие моменты.

И, конечно, попишем SQL-запросы!

Статья направлена на решение проблемы "зависания" выгрузки результатов опросов при использовании модуля Vote 1С-Битрикс в случае, если в опросе много вопросов или ответов. Так-же в статье реализована выгрузка в Excel SQL-запроса при заранее неизвестном количестве полей, т.е. каждое поле формируется динамически.

Пошаговая инструкция о том, как установить и использовать расширение PostGIS для PostgreSQL в Docker.

Включает в себя: установка и настройка Docker-контейнера, загрузка данных в базу данных, извлечение и визуализация данных, анализ геоданных с помощью PostGIS функционала.

С момента первой же хабрапубликации о возможностях нашего сервиса визуализации планов запросов PostgreSQL explain.tensor.ru (а было это уже больше 2 лет назад) пользователи задавали резонный вопрос: "Все у вас круто, но у нас в запросах и планах есть коммерческая инфа, которую отправлять куда-то наружу низзя... Можно как-то ваш сервис развернуть на своей площадке?"

Ну, а почему бы и нет, подумали мы - тем более, некоторые пользователи уже интересовались возможностью интеграции нашего сервиса в свои системы.

В настоящее время тема миграции с СУБД Oracle на СУБД PostgreSQL (и разработанную на её основе СУБД Postgres Pro) является очень актуальной. В этой области у команды Postgres Professional накоплен многолетний опыт, которым мы решили поделиться. На основе наших материалов для внутреннего обучения мы подготовили серию статей для Хабра о миграции данных в PostgreSQL из «оракловой» базы.

Также на близкие темы можно посмотреть следующие доклады и мастер-классы.

В этой статье я расскажу как на Rust написать расширение для SQLite. В частности мы поговорим о том, что такое виртуальные таблицы, и как мы можем их реализовать на Rust.

К концу статьи у нас должно получиться расширение, которое можно динамически загрузить в SQLite. И хотя, данная статья не претендует на звание полного руководства по написанию плагинов для SQLite, автор надеется, что у читателя появится общее понимание принципов работы расширений.

Исходный код на GitHub

В PostgreSQL несложно написать запрос, который уйдет в глубокую рекурсию или просто будет выполняться гораздо дольше, чем нам хотелось бы. Как от этого защититься?

А чтобы еще и полезную работу сделать? Например, набрать следующий сегмент данных при постраничной навигации со сложным условием фильтрации.