title

text

Юрий Плотников
Юрий Плотников ООО «РТК ИТ» Тимлид
Никита Левченко
Никита Левченко ПАО «Ростелеком» Старший инженер
: декабря
45 мин

Из Oracle в Postgres по российским рельсам. Неочевидные нюансы

Поговорим о наших подходах к выбору технических решений при проектировании архитектуры систем. Их преимущества и ограничения. Как менялась наша инженерная культура с учетом требований импортозамещения. История миграции системы с классической трехзвенной архитектурой с БД Oracle на PostgresPro. Большое внимание уделено инструментам переноса данных, а так же нюансам доработки Java/Kotlin приложений и совместимости SQL между двумя СУБД.

Слайды

Видео

Видео доступно участникам мероприятия, выполнившим вход в личный кабинет

Другие доклады

  • Павел Лузанов
    Павел Лузанов Postgres Professional Руководитель образовательных программ
    45 мин

    PostgreSQL 14. Финальный обзор

    На протяжении всего релизного цикла 14 версии мне довелось описывать принятые патчи в статьях посвященных каждому из пяти коммитфестов релиза. И даже в первых двух статьях о 15 версии нашлось что добавить про 14-ю. Эти статьи можно найти и прочитать на Хабре (и смело пропустить доклад :-)).

    30 сентября наступил тот день, когда PostgreSQL 14 вышел официально. Больше уже ничего не должно измениться. И теперь совершенно точно можно делать финальный обзор изменений.

    Однако рассказать обо всем новом в одном докладе - дело практически не реальное. Поэтому постараюсь составить свой собственный топ-лист.

  • Олег Бартунов
    Олег Бартунов Postgres Professional генеральный директор
    Никита Глухов
    Никита Глухов Postgres Professional Старший разработчик
    45 мин

    Элегантный поиск ближайших соседей в PostgreSQL

    С необходимостью эффективного поиска ближайших соседей можно встретиться в разных задачах, например, поиск ближайших к заданной точке объектов на карте. Задача, на непрограммистский взгляд кажущаяся тривиальной (действительно, человек довольно легко справляется с ней глядя на карту) , на самом деле не имеет общего и доступного решения, что приводит к головной боли разработчиков, которые придумывают ad hoc решения (вставляют костыли). Эти решения, обычно некрасивые, портят настроение творческой натуры программиста, которому требуется посещение пивной, чтобы пережить когнитивный диссонанс :)

    Действительно, если у человека есть карта, у которой есть определенный масштаб, и характерный размер поля зрения, то у программиста есть только координаты заданной точки и множество точек, которых может быть очень много (миллиарды звезд !), и к которому может идти большое количество конкурентных запросов, причем не только на чтение. Язык SQL позволяет очень красиво записать запрос, но реальный план его выполнения удручает - требуется прочитать всю таблицу, вычислить все расстояния от заданной точки, отсортировать по убыванию и оставить требуемое количество записей. Наличие индексов не спасает, а только приводит к полному обходу поискового дерева и чтения всей таблицы в случайном порядке, что гораздо медленнее простого чтения таблицы.

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

  • Федор Сигаев
    Федор Сигаев Postgres Professional технический директор, ведущий разработчик PostgreSQL
    22 мин

    Зачем еще 64-битные значения?

    Когда PostgreSQL только появлялся, значения идентификатора транзакции были выбраны 32х-битными. В то время это казалось запредельным числом - кто в здравом уме будет проводить 4 миллиарда транзакций? Но развитие техники привело к тому, что появились инстансы, где транзакции подбирались к этому пределу. Сообщество разработчиков ответило на это возможностью "оборота" счетчика транзакций (известный как wraparound). Но технический прогресс и рост количества данных поставили PostgreSQL перед новыми вызовами. В докладе я попытаюсь рассказать об этих вызовах, о том, как их можно преодолеть с помощью повышения разрядности счетчика, к каким следствиям это приведет и почему это надо делать сейчас, и почему это не было сделано раньше.

  • Дмитрий Васильев
    Дмитрий Васильев Postgres Professional DBA
    45 мин

    Мониторинг PostgreSQL: sampling plan и average active sessions своими руками

    Мы в ОЗОН делаем PostgreSQL as a service. На данный момент у нас уже тысячи кластеров. Мы знаем, какие вопросы мучают разработчиков, вот самые важные из них: как понять насколько нагружена база и почему запрос начал тормозить? В докладе я расскажу как мы помогаем разработчикам ответить на эти вопросы, просто взглянув в дашборд.