Constraints или о том, как попытаться спокойно жить
Часто можно услышать, что ограничения целостности снижают производительность, все время мешают в работе и вообще в целом бесполезны, база - это всего лишь хранилище и вообще там не должно быть никакой логики. Я расскажу, почему это не так и чем может обернуться такой бездумный подход.
Слайды
Видео
Другие доклады
-
22 мин
Yana Krasteva Swarm64 VP Product and InnovationСовременное хранилище данных на основе PostgreSQL
Построение хранилища данных на основе PostgreSQL имеет долгую историю. Netezza, Redshift и Greenplum превратили определенные релизы PostgreSQL в решения для хранения данных. В настоящее время, с учетом тенденции к повышению производительности PostgreSQL (улучшение секционирования, статистики, JIT-компиляция и т. д.) и наличия продвинутых расширений, таких, как Swarm64 Data Accelerator, вы можете создать современное, надёжное и многофункциональное хранилище данных. В этом докладе будут рассмотрены тенденции PostgreSQL и хранилищ данных и затронуты ключевые аргументы в пользу выбора PostgreSQL для построения хранилища данных.
-
45 мин
Дмитрий Долгов Zalando SE Senior Software EngineerСколько нужно инженеров, чтобы скобки заработали?
Недавно появившийся в PostgreSQL, jsonb subscripting не выглядит так же захватывающе, как другие улучшения в jsonb. Но те изменения, которые видны пользователю - всего лишь верхушка айсберга. Как много людей было вовлечено в разработку, и какие решения были сделаны в дизайне? Как много времени это заняло, и какие хорошие/плохие идеи существуют для продвижения патча? Эти и несколько других вопросов будут целью это презентации.
-
22 мин
Максим Орлов Postgres Professional разработчикГорячее минорное обновление в Postgres Pro13
Обновление минорных версий Postgres Pro без остановки сервера и остановки активных сессий.
-
22 мин
Alicja Kucharczyk Microsoft EMEA Global Blackbelt OSS Data Tech Specialist
Sushant Pandey Microsoft 500032История одной миграции
В данном рассказе мы хотим рассказать о том, как команда Microsoft, созданная из двух различных команд, работала над проектом, решала проблемы миграции, используя ora2pg, и смогла доказать, что Postgres Single Server может демонстрировать хорошую производительность наравне с Oracle Exadata. Мы расскажем о наших методах работы, а также о ряде основных проблем технического характера, с которыми мы столкнулись, включая миграцию выражений BULK COLLECT, иерархических запросов, курсорных выражений REF CURSOR и других, более сложных конструкций Oracle.
Наша история о практическом подтверждении гипотезы, которое доказало, что Postgres может демонстрировать такую же производительность, как Oracle Exadata. Схема мигрируемой БД была не самой простой. Скорее, наоборот. Код был нагружен динамическими запросами, выражениями BULK COLLECT, вложенными циклами, операторами CONNECT BY, глобальными переменными и множеством зависимостей. Инструмент Ora2pg очень помог нам с преобразованием схемы БД, но всё равно осталось много работы, которую можно было сделать только вручную. Оценки, которые мы получили благодаря инструменту, также оказались очень далеки от истины, поскольку требовалась не просто миграция кода, а изменение его архитектуры. В рамках нашего доклада мы рассмотрим следующие подтемы:
- Как (не) работают оценки
- Как мы справились с миграцией выражений BULK COLLECT
- Почему мы избавились от выражений REF CURSOR
- Как мы застряли на фазе тестирования одного из пакетов и как помощь друга помогла нам в решении этой проблемы.
- Как мы справились с иерархическими запросами и детализацией иерархии