Oracle *

ORM — Object-Relational Mapping — Объектно-реляционное отображение — это технология, позволяющая связывать SQL-ые БД с ООП кодом. Самая известная из них — Hibernate.

Hibernate — очень красивая технология. Она формирует ощущение магии.

Ты просто создаёшь объект, — хлабысь! — он уже в базе данных. Никакого SQL, никаких соединений, никаких ResultSet. Всё происходит как будто само собой. Прелесть.

Именно поэтому отказаться от Hibernate так тяжело.

Это напоминает Кольцо Всевластия из «Властелина колец». Оно не просто давало силу — оно меняло сознание своего владельца. Оно внушало мысль, что без него уже нельзя. Что именно оно даёт власть и контроль.

Hibernate действует очень похоже. Он формирует ощущение, что именно он управляет данными. Что именно он связывает код с базой. Что без него всё развалится.

И ты начинаешь бояться.

Бояться, что без Hibernate придётся писать бесконечный SQL. Бояться, что потеряешь контроль над данными. Бояться, что любая операция с базой превратится в мучение.

Ты уже не представляешь себе проект без этой магии. Ты настолько к ней привык, что мысль «выкинуть Hibernate» кажется почти кощунственной. Кажется, будто вместе с ним исчезнет и сама возможность нормально работать с базой данных.

Однажды я захотел узнать что-то новое по СУБД Postgres и структурировать уже имеющиеся знания. На помощь пришла программа сертификации. Рассказываю как подготовиться к прохождению теста от Posgres Professional и на что обратить внимание в первую очередь.

Мое имя Денис Непочитой, я уже несколько лет занимаюсь базами данных в ПСБ.

Администрировал разные системы, но в основном фокусе была АБС на Oracle (автоматизированная банковская система, «сердце» банка): от решения проблем с производительностью до обновлений на новую версию. В последнее время также сфокусирован на задачах по АБС, но уже на Postgres. 

Для кого эта статья: для тех, кто только начинает свой путь в ИТ, и для всех, кто задумывается о прохождении сертификации.

Как это было — читайте ниже.

HTAP — одна из главных тем в мире СУБД. Вокруг PostgreSQL массово появляются конструкции с внешними аналитическими движками со своими моделями хранения данных и ограничениями совместимости, однако бизнесу не совсем комфортно жить в архитектуре, где транзакционные данные находятся в одной системе, аналитика — в другой, а между ними — разного рода ETL, CDC и прочие parquet‑файлы.

В Tantor мы движемся по иному пути, развивая HTAP внутри PostgreSQL, а не рядом с ним. Вокруг этой идеи строятся СУБД Tantor Polar и машина баз данных Tantor XData Gen3, в которой OLTP и аналитика, не теряя совместимости с Postgres, работают поверх общего хранилища данных и общей видимости транзакций. В этой статье хочется поговорить не столько о самом термине HTAP, сколько о том, как меняется архитектура PostgreSQL, когда OLTP и аналитика начинают работать поверх общего хранилища данных.

Все, кто имел дело с базами данных, знают, что там можно хранить бинарные данные большого объема. Чаще всего, это загруженные в БД файлы. Достаточно давно меня стал посещать такой вопрос — а какие накладные расходы на хранения файлов в БД? Понятно, что они есть, но вот какие и от чего они зависят? Но каждый раз были вопросы и задачи поважнее. И вот недавно произошло то, что рано или поздно должно было произойти — одновременно у двух заказчиков возник вопрос, который, упрощая, выглядит так: «Почему мы загрузили такой‑то объем данных, а место на диске занято больше?». У одного из заказчиков был Oracle, у второго — Postgres. Конечно, можно было бы ответить уклончиво: «У каждой БД существую накладные расходы на хранение данных, вот у вас эти накладные расходы вот такие. Разработчикам СУБД виднее, как все должно быть.» И, может быть, заказчика такой ответ и устроил, но сам я понимал, что это просто отписка, так как у нас нет конкретного ответа. Несолидно как‑то. Поэтому, давайте разбираться.

В любой промышленной системе обработки данных есть пласт регулярной работы, которую нужно просто запускать раз в день или раз в час и не думать о ней: ночные ETL-загрузки, пересчёт витрин, выгрузки в смежные системы, всякая техническая обвязка вроде чистки служебных таблиц. Всё это должно где-то стартовать по расписанию, уметь учитывать зависимости между потоками и принимать во внимание тот факт, что задачи у нас разнородные. Ниже — рассказ про то, как устроен наш планировщик на Oracle Data Integrator и PL/SQL: из чего он собран, как задачи попадают в очередь, как они распределяются по серверам, и как мы закрываем сценарий с зависаниями.

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

Бюджетирование – очень важная, интересная и нетривиальная задача, которую в современном мире принято решать при помощи автоматизации. Если еще 5 лет назад в системе бюджетирования видели инструмент консолидации и план-факт анализа, то сегодня это комплексная высокотехнологична модель бизнеса.

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

Привет, Хабр! Меня зовут Даша Александрова, я Java‑разработчик. Хочу поделиться опытом миграции данных из Oracle в PostgreSQL без простоя сервисов.

Причина миграции — импортозамещение.

Теперь немного про сам проект. В его основе — микросервисная архитектура на Java 11/17 и Spring Boot 2/3. В качестве основной базы данных использовалась Oracle с несколькими схемами. В коде сочетаются нативные SQL‑запросы и Hibernate, вся бизнес‑логика живет на уровне приложения — без процедур, триггеров и другой логики в базе. Идентификаторы генерируются через sequence. Проект активно развивается, регулярно выпускаются релизы. Система ориентирована на клиентские приложения — мобильное и веб, при этом нагрузка остается умеренной и не относится к highload‑сценариям.

Ключевое нефункциональное требование — выполнить миграцию без простоя системы и без заметного влияния на пользователей.

Может возникнуть логичный вопрос: если такие миграции уже делались не раз, почему просто не взять готовое решение? На практике универсального подхода не существует.

Где‑то допустим простой на несколько часов, где‑то — нет. В одних системах хватает простого переноса, в других приходится использовать сложные стратегии вроде двойной записи. Многие статьи подробно разбирают инструменты, но их применение в конкретном проекте — это отдельная инженерная задача. К тому же у каждой системы есть свои ограничения и нюансы. Поэтому дальше я разберу конкретный кейс и те решения, которые были приняли по ходу миграции.

Из всего многообразия оборудования, которое встречается в ЦОДе, ленточные библиотеки — единственный вид, работу которого можно увидеть. Ленточные библиотеки ворочают петабайты данных на магнитных лентах в картриджах, которые отдают лёгкой ностальгией по VHS, и делают это с помощью роботов. А роботы — это (почти) всегда круто. И в одной библиотеке их может быть несколько!

Ленточные библиотеки стыкуются из модулей, как огромные орбитальные станции, а их производители в погоне за максимальной плотностью хранения картриджей находят очень изобретательные решения — от хранения картриджей в несколько слоёв в одном слоте до револьверных механизмов высотой с холодильник и шаттлов, которые передают ленты между разными библиотеками. Это ли не круто?

Бывают ситуации, когда есть список значений, и нужно найти значения, которых нет в БД. Прямым SQL-запросом найти отсутствующие значения невозможно, так как из базы нельзя получить значения, которых там нет. В статье рассмотрим какие есть замены временным таблицам в SQL.

СУБД PostgreSQL давно закрепилась в топе благодаря открытости, надёжности и расширяемости, однако ее архитектурный консерватизм порождает ряд нерешённых проблем: отсутствие горизонтального масштабирования, деградация при тысячах соединений, узкое место WAL при высоком commit rate, невозможность полноценной HTAP-обработки и другие.

В статье рассказываем как в новом, третьем поколении машин баз данных Tantor XData Gen3 эти ограничения преодолеваются через глубокую переработку архитектуры — от полного разделения Compute и Storage с протоколом RDMA и распределённой файловой системой PFS до внедрения механизмов CSN для MVCC без блокировок, конвейерной обработки WAL и встроенного MPP‑движка, превращающего PostgreSQL в систему, способную конкурировать с Oracle Exadata уже по‑настоящему. И все это — со 100% сохранением совместимости с «обычным» PostgreSQL.

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



Привет! Мы – Дмитрий Харлан и Антон Ляшедько, представители команды развития системы бизнес-планирования ВТБ.

Наша история о том, как мигрировать монолитную систему с более чем 300 отчетами и объемом данных свыше 100 гигабайт за минимальное время простоя.

Существует опасное заблуждение, что «ванильный» Open Source — это серебряная пуля для энтерпрайза. Однако жесткий краш-тест последних лет показал: когда уходят привычные гиганты вроде Oracle, чистый Postgres превращается в тыкву под нагрузками крупного бизнеса. Руководитель отдела технического консалтинга Postgres Professional Марк Ривкин делится своим авторским видением того, почему нам приходится заново изобретать велосипеды, дописывая миллионы строк кода в ядро, и почему будущее за конвергентными системами. Дисклеймер: это частный взгляд эксперта.

Недавно у меня возникла задача по разбиению мульти-терабайтной таблицы на равные диапазоны по числовому полю id. Причём данные распределены по id крайне неравномерно, где-то есть большие "лакуны", где-то непоследовательная генерация и т.д., и т.п. Конечно, можно применить честное решение в лоб — использовать функцию NTILE, но я довольно быстро осознал, что это приведёт к многочасовому запросу с большой вероятностью упасть из-за недостатка TEMP. Но, к счастью, зачастую в таких задачах, как и в моём случае, идеальное разделение на диапазоны не требуется, достаточно более-менее приличного.

Я решил провернуть небольшой трюк для получения приблизительного разделения. Давайте посмотрим, что у меня получилось на модельном примере.

Слышали о ГИС ГМП? Скорее всего, мало кто слышал. Зато точно видели, если:

— вам на Госуслуги приходила пошлина на оплату нового загранпаспорта

— вы получали уведомление о штрафе ГИБДД в банковском приложении

— вы узнавали состояние своего единого налогового счёта (ЕНС)

Чтобы всё это стало возможным, Федеральное Казначейство создало Государственную информационную систему о государственных и муниципальных платежах (ГИС ГМП). Именно она аккумулирует все назначенные людям и компаниям платежи и контролирует их оплату, сверяя платёжные поручения банков с начислениями.

Как вы думаете, много ли там начислений? А платежей? Сотни миллиардов.

В рамках импортозамещения нам в РТЛабс поставили задачу — мигрировать ГИС ГМП с базы данных Oracle на другую подходящую. Да-да, нам предстояло мигрировать систему, которая хранит сотни терабайт данных — кому и что было начислено, как и когда это оплатили.

Как нам это удалось? Именно об этом я и хочу рассказать. На связи Михаил Денисов — технический директор блока развития казначейских проектов.

В интернете есть много статей на тему «как перевести старую систему с Oracle на PostgreSQL». Как мигрировать схему данных, сами данные и логику. Не буду повторять это, просто сравню две СУБД на небольшом вымышленном учебном примере. Я расскажу про то, как организовать процесс написания и проверки кода системы для PostgreSQL, чтобы на выходе получился продукт даже более качественный, чем он мог быть без смены СУБД.

Чтобы было интереснее, я решил объединить два жанра и сделать техническую статью в виде фантастического рассказа. Тут будет и мультивселенная, и путешествия во времени. Вся фантастика оформлена в виде цитат, чтобы те, кто хочет просто факты, могли не терять время.

Oracle снова в центре внимания. Компания, долгое время считавшаяся инфраструктурным элементом корпоративных ИТ-систем, внезапно оказалась в центре внимания ИИ.

Это история Oracle Ларри Эллисона, её многолетней трансформации и создания облака, идеально подходящего для эпохи искусственного интеллекта.

JOIN vs коррелированный подзапрос: мой разбор мифа «JOIN всегда быстрее»

Я проверил оба подхода (JOIN + GROUP BY и коррелированный подзапрос) на маленьком датасете и в ряде СУБД. Иногда подзапрос быстрее. Всё зависит от плана (Nested Loop vs Hash) и индексов. Слепо верить «JOIN всегда быстрее» не стоит. Смотрите EXPLAIN.

Всем привет! Меня зовут Алексей Кременьков, я старший разработчик в Яндекс Почте. В этой статье расскажу, как мы работаем с большим количеством шардов PostgreSQL: как создавали собственный сервис динамического шардирования Sharpei, как развивали инфраструктуру под него и как проходил переезд на облачное решение. В конце разберёмся, какие плюсы и минусы мы смогли найти в этом решении.

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

Статья описывает методику миграции приложения, содержащего множество SQL запросов из базы данных Oracle в Postgres. Будет интересна всем, кто собирается мигрировать или уже мигрировал приложение из Oracle в Postgres.