![Henrietta Dombrovskaya Henrietta Dombrovskaya](/media/2021/01/27/IMG_4133 (1).jpg.180x180.jpg)
NORM - фреймворк без ORM
Хорошо известно, что, хотя производительность базы данных велика и каждый запрос выполняется за миллисекунды, общее время отклика приложения может быть медленным, поэтому пользователи могут долго ждать ответа. Мы знаем, что проблема не в базе данных, а в том, как разработчики приложений с ней общаются. В частности, речь идет об ORM - Object-Relational Mappers. Разработчики баз данных ненавидят их, но разработчики приложений любят их, потому что они позволяют разрабатывать приложения без каких-либо знаний о внутреннем устройстве СУБД. В результате производительность системы часто оказывается неприемлемо низкой.
Единственный способ изменить это - предоставить разработчикам приложений такой же простой в использовании инструмент, как ORM, но позволяющий избежать распространенных ошибок ORM. Вот почему мы разработали NORM - No-ORM Framework. Во время этой презентации мы рассмотрим примеры кода из репозитория https://github.com/hettie-d/NORM и узнаем, как создавать «транспортные объекты» для эффективной передачи данных между приложениями и базами данных.
Видео
Другие доклады
-
Николай Самохвалов Nombox LLC Основатель
Бесшовная оптимизация запросов PostgreSQL, версия 2.0
Существует два способа анализировать SQL-запросы:
На макроуровне: в этом случае мы анализируем рабочую нагрузку как единое целое (есть три основных подхода: использование метрик из pg_stat_statements или аналогичного модуля, анализ логов с помощью pgBadger или другого похожего решения и запрос выборки в представлении pg_stat_activity).
На микроуровне: в этом случае мы погружаемся в детали исполнения одного конкретного запроса (тут главную роль играет команда EXPLAIN).
Между этими двумя подходами есть немало "белых пятен", которые обнаруживаются с ростом нагрузки. Главные проблемы:
- Нужно переключаться между макро- и микроуровнем без больших накладных расходов.
- Требуется надёжная проверка гипотез относительно возможных оптимизаций.
- Есть необходимость минимизации рисков при развёртывании новой функциональности.
Чтобы справляться с этими задачами в растущем проекте, требуется продвинутый опыт в качестве администратора баз данных, и – иногда – интуиция. Также могут помочь новые инструменты, которые (к счастью для нас!) не так давно начали появляться.
В рамках данного мастер-класса мы разберёмся, как можно настроить процесс беспроблемной и бесшовной оптимизации SQL-запросов в вашей организации: а) какие инструменты следует выбрать в вашем конкретном случае? б) как эффективно заполнить вышеупомянутые пробелы в сфере анализа запросов?
-
Павел Борисов Postgres Professional программист
Ускорение быстрого текстового поиска с помощью индекса RUM
Быстрый текстовый поиск в PostgreSQL существенно ускоряется, если использовать обратные составные индексы по лексемам внутри типа tsvector. Индекс RUM - это свободное расширение, основанное на индексе GIN. Оно индексирует не только лексемы, но и их положение в текстовом поле, а также включает дополнительную информацию - вес лексемы, это позволяет полнее поддерживать возможности tsvector.
До недавних пор запросы с весами лексем в индексе RUM требовали перепроверки по таблице. Моя модификация (2020) в разы ускоряет такие запросы, делая их index-only.
В докладе будут представлены различные сценарии использования быстрого текстового поиска и применение индекса RUM для его существенного ускорения, а также бенчмарки по сравнению с встроенным в PostgreSQL индексом GIN.
-
Дмитрий Долгов Zalando SE Senior Software Engineer
Сколько нужно инженеров, чтобы скобки заработали?
Недавно появившийся в PostgreSQL, jsonb subscripting не выглядит так же захватывающе, как другие улучшения в jsonb. Но те изменения, которые видны пользователю - всего лишь верхушка айсберга. Как много людей было вовлечено в разработку, и какие решения были сделаны в дизайне? Как много времени это заняло, и какие хорошие/плохие идеи существуют для продвижения патча? Эти и несколько других вопросов будут целью это презентации.
-
Daniele Varrazzo Codice Lieve Директор
psycopg3: как Питон полюбил Постгрес
На сегодняшний день Python является одним из наиболее часто используемых языков программирования в мире. Он прост в изучении и использовании и легко совместим с любыми известными сервисами и протоколами. psycopg2 - наиболее часто используемый драйвер PostgreSQL для Python: он обеспечивает хорошую производительность и делает взаимодействие между ЯП и СУБД максимально удобным.
За последние годы Python существенно изменился, и его первоклассная поддержка асинхронного программирования меняет способ написания новых программ. В PostgreSQL также было внесено множество изменений, поэтому требуется новое поколение драйвера, который позволит питонистам использовать все возможности Postgres по максимуму.
psycopg3 - это новое поколение наиболее часто используемой библиотеки-адаптера Python-PostgreSQL: она предлагает знакомый интерфейс и удобный процесс обновления, кроме того, она спроектирована для получения максимальной производительности от базы данных и ЯП: она поддерживает асинхронное программирование, связываемые переменные (prepared statements), двоичные параметры.
psycopg3 также экспериментирует с инновационной поддержкой JSONB и конвейерной обработкой запросов! Приходите и узнайте, что нового происходит на стыке вашего любимого языка программирования и базы данных!