Spring также поддерживает это и с JdbcTemplate и с JPA. Напоминаю, что для получения текущего коннекта в Spring нужно использовать DataSourceUtils. См исходный код для понимания того, как именно это нужно делать.
Кстати для JPA, если вы хотите хранить массивы Java в таблице как есть, используя нативные типы Postgres, то можно не тратить время на написание TypeDescriptor-ов самому, а просто взять готовую библиотеку от славного Vlad Mihalcea, использование которой он описал тут: https://vladmihalcea.com/how-to-map-java-and-sql-arrays-with-jpa-and-hibernate/
Просто в вашей практике хинты не были нужны. Когда решение тиражируется на десятки и сотни инстансов, а на местах нет грамотных DBA, то хинты зачастую это единственный выход. Бывает что сбор статистики по какой-то причине вообще отключен.
Кроме того, бывает что система разворачивается в секретном контуре и доступ к ней имеют только федеральные агенты, которые однако ничего не смыслят в IT.
Ещё вариант — нет доступа к исходникам, а есть запрос, который нужно оптимизнуть. Тогда можно сохранить для него специальный план. Был такой случай, когда в топ AWR на огромном федеральном проекте постоянно вылезал запрос, выполняемый ядром Oracle Application Server, и даже у самих сотрудников Oracle не было возможности это починить иначе чем сохраненным планом.
Вообще, все дело в наличии актуальной статистики. Иногда, однако, в течение дня характер и распределение данных меняются кардиально. Например, система принимает и обрабатывает миллионы бизнес объектов, и в какой-то момент запускается операция обработки полученных данных (консолидация, аналитика, matching и т.п.), а статистика собиралась 8 часов назад, т.к. на больших БД это довольно длительная и затратная операция. Результат — оптимизатор выбирает неверный алгоритм соединения таблиц или неверный индекс и т.п.
Поэтому все мои знакомые DBA и senior developers, в том числе сотрудники Oracle, используют хинты не просто иногда, а как обыденный инструмент каждый день.
Ни один оптимизатор не может сравниться с человеком, имеющим десятки лет опыта, знающим всю подноготную этого алгоритма.
Больше того, иногда очень хочется помочь оптимизатору, хотя бы указав с какой таблицы или индекса начинать. И это тоже боль — чувствовать себя беспомощным не имея хинтов в Постгресе.
Касательно моего повествования о неработающем автодополнении нужно, конечно, пояснить, что я исхожу из предположения, что предзагрузка метаданных не активирована. Но, по моему мнению, это не должно исключать автодополнение полностью, а лишь замедлять его.
Кроме того, предзагрузка метаданных по определению не может учитывать доступность объектов для разных ролей. Если в одном окне роль X даёт грант на объект роли Y, то в другом окне (сессии) для роли Y должно заработать автодополнение. И это работает во многих GUI.
Таким образом, для подобных моему сценариев использования было бы неплохо иметь возможность переключаться в режим real-time интроспекции, с возможностью быстрого сброса кэша по хоткею.
Пункт 2.
Как я написал выше, «Возможно, эту фичу уже завезли, тогда прошу прощения». Давно не работал с этим функционалом.
Далее по пункту 3.
Честно говоря, как-то все чересчур запутанно, непрозрачно. Концепция выбора активных data source/database/schema для консоли просто убивает.
У меня много PostgreSQL баз, в каждой из них несколько десятков схем, доступные разным ролям. Есть схемы с только с хранимыми процедурами (для эмуляции пакетов Oracle). Я обычно имею открытыми около 10 окон с кодом для разных бизнес-областей (например, для разных микросервисов или их кусков). Все окна имеют отдельные коннекты и разные настройки (авто-коммит, уровень изоляции и т.п.). Я постоянно переключаюсь между несколькими кластерами/базами с похожими схемами (но всё-же они отличаются).
1) Когда я переключаюсь на новую БД, я делаю это глобально. Это означает что я хочу чтобы все окна сразу закрыли коннект, и после этого, когда я отправляю первый запрос в любом окне, то это окно открывает новый коннект с текущей выбранной БД.
Да, вы поддерживаете возможность подключения к нескольким БД параллельно, но из моего опыта — это является источником граблей. Я и сам наступал, и много раз видел как другие по ошибке изменяют не ту БД, с которой, как им кажется, в данный момент работают. Цветные метки помогают, конечно, но не сильно.
2) Я не хочу кликать мышкой десятки схем только для того, чтоб заработало авто-дополнение. Если же я отмечаю только «Current schema», то авто-дополнение не будет работать для других схем, даже если всегда указывать имя схемы. И как установить эту текущую схему, не кликая мышкой? Кажется, никак. Это, наверное, самый неприятный момент. С другой стороны, мне совсем не нужны все схемы, особенно системные, поэтому вариант «All schemas» меня не устраивает. Слишком много лишней информации.
3) Если я выполню запрос «set role xxx», я хочу чтоб для текущей сессии автодополнение работало для всего, что доступно этой роли. До тех пор пока я не переключился на другую (set role yyy).
Я пишу «select * from xxx.» и теперь при нажатии на Ctrl+Space я хочу видеть доступные мне объекты схемы xxx и только. А если я не указал схему явно, что ж, для этого есть search_path (по умолчанию search_path = '"$user", public').
Даже если я знаю имя таблицы, все равно автодополнение не работает! Пример: «select * from xxx.yyy as t where t.» -> «ctrl+space» -> вываливается огромный список встроенных функций. В конце списка присутствуют некоторые системные поля типа ctid, а больше ничего! В общем, интроспекция просто не работает. Не могу же я каждый раз лазить по интерфейсу, менять настройки схем, потом нажимать refresh и ждать.
Нет времени больше писать, но есть и другие претензии. Поэтому из GUI тулзов я остаюсь на «SQL Workbench/J» как на наиболее адекватной из всех сред под Linux, что я пробовал. Там все работает ровно так, как это ожидается, без сюрпризов.
Ну и конечно, без консольных клиентов никуда, у меня всегда открыто несколько терминальных окон к разным БД (для Postgres это psql, pgcli). Они работают намного быстрей любых GUI сред, особенно что касается показа метаданных объектов и автодополнения кода.
И ещё одно пожелание: кнопочка «развернуть/свернуть все узлы» инвертирует каждый узел в отдельности. Если часть из них уже развернута, то они сворачиваются и наоборот. Хорошо бы чтоб ее поведение зависело от глобального флага, и я не против кликнуть лишний раз, если флаг не отражает результат моих ручных действий. Что думаете?
Эту табличку вскоре будут партиционировать среди прочих, по хэшу индексного ключа из обсуждаемого узла, а кластеризацию уже выполнили, это вы верно подметили :)
«Таблица сильно разрежена, рекомендуется произвести очистку с помощью VACUUM [FULL]». На самом деле этот план получен на staging машине, где только что развернули свежий дамп в единой транзакции, и не выполнили ни единого DML запроса. То есть таблица ну никак не может быть разреженной.
3) Жалко, хотелось бы поделиться с коллегами. С другой стороны, правильно, пускай учат великий могучий, будет стимул :)
Круто! Хотя и немного непривычно после explain.depesz.com, которым вы явно вдохновлялись.
1) Под Firefox мелкие косячки, потестируйте, пожалуйста. Например, размножающиеся диаграммы и т.п.
2) Рекомендации попадаются из разряда «пальцем в небо», вот прям совсем мимо.
3) Планируется ли английская версия интерфейса? Это ведь бета для хабратестеров?
И это будет означать что у нас не одна проблемная строка, а несколько. В этом случае мы проходим по обеим ветвям, которые, в свою очередь, могут также породить новые ветви. Написать простенький скрипт с рекурсией на Bash, Python, PL/pgSQL и т.п. займет минут 15. Запустить, подождать несколько минут — и вуаля.
Чтоб не ждать так долго, можно было бы использовать метод половинного деления, каждый раз делая INSERT FROM SELECT во временную таблицу. Табличка небольшая, всего 1.6 миллиона записей.
Делим диапазон ID пополам (1..800K; 800K..1.6M) и копируем данные во временную таблицу. Запрос для одной из половинок завершится с ошибкой. Берём эту половину диапазона и выполняем два запроса для четвертинок (напр, 800K..1.2M;1.2M..1.6M) и так далее. Несколько минут — и вы получили бы ответ.
PostgresPro переводят самую обычную официальную документацию. Плюс расширенные версии для двух своих форков (Pro Standard и Enterprise). Итого доступны три перевода. Там даже можно открывать параллельно рус и англ версии.
Патологий нет, проверялся вдоль и поперек у докторов перед началом тренировок. Даже носил прибор для записи кардиограммы несколько дней.
Интервалы значит «пешком»-«бегом»-«пешком»-«бегом», причем продолжительность повторов и их количество со временем меняются, пока не доходят до 5км бега без остановки. К примеру, план первой тренировки: поочередно, 60 секунд бега и 90 секунд ходьбы на протяжении 20 минут + разминка и заминка.
Программа была разработана тренером для своей мамы, которая никогда не занималась спортом.
Дык и я бегал с пульсомером на груди. Никогда не превышал допустимый предел для своего возраста. И теорию всю прочёл вдоль и поперек. Но бег всегда был для меня пыткой. Каждый раз преодоление себя.
Пару раз бегали с сыном, он пытался со мной разговаривать. Куда там, я даже «да» и «нет» не мог ответить, сразу темнота в глазах :) И это после трех месяцев регулярных пробежек через день.
Вот вам мой опыт. В 35 лет начал бегать по по пулярной программе "Couch to 5K". Это программа интервальных тренировок разработанная для тех, кто никогда не занимался спортом и хочет бегать 5 км для укрепления здоровья. Начал я ранней весной, 5 км достиг через 3 месяца и бегал пол лета, через день. Потом в один прекрасный день во время бега у меня в глазу лопнул сосуд на сетчатке. Теперь этот глаз имеет слепую зону, которая восстановлению не подлежит. Врач ещё предупредил что может совсем сетчатка отслоится, целиком, но обошлось. Мозг перестроился со временем, конечно, и это меня не беспокоит и даже не мешает работать. Но бег категорически запрещен.
Так что подумайте — оно вам надо? :)
Мерять производительность способом, описанным в статье совершенно неверно.
Автор, погугли "JMH", эта библиотека является частью JDK. В сети куча примеров и видео, в том числе на русском от её автора — Алексея Шипилёва.
Кроме того, присоединяюсь к предыдущим комментаторам. В целом, посыл статьи правильный, описывает известный антипаттерн. Но приведённый код из раздела "как надо" не прошёл бы ревью.
Common table expressions are supported by Teradata, DB2, Firebird, Microsoft SQL Server, Oracle (with recursion since 11g release 2), PostgreSQL (since 8.4), MariaDB (since 10.2), MySQL (since 8.0), SQLite (since 3.8.3), HyperSQL and H2 (experimental).
В течение 12 лет я ежедневно работал с Oracle и писал тонны серверного кода для крупных финансовых систем. Подолгу использовал все перечисленные IDE, знал их сильные и слабые стороны, но основным инструментом всегда оставался «PL/SQL Developer», а остальные были про запас, just for fun. На мой взгляд, для разработчика — это лучший выбор. Если, конечно, вы работаете на Windows. Если её грамотно настроить и установить нужные плагины, то скорость работы в этой IDE становится просто умопомрачительной. Всё на хоткеях, код буквально сам пишется при помощи автозамен и сниппетов, абсолютно все настраивается и великолепно расширяется. А если всё равно чего-то не хватает, написать свой плагин — раз плюнуть. Я написал 5 штук на Delphi и был просто счастлив.
Теперь хочу бросить маленький камушек в сторону DataGrip. Среда отличная, конечно же, и я использовал в редких случаях её немного урезанную версию в составе IntelliJ IDEA Ultimate. Но именно для работы с Oracle она мне в своё время не подошла по двум причинам.
1. Тормоза при работе с большими схемами
Например, в системах на основе OeBS бывают сотни тысяч объектов в схеме (в моей продакшн БД в то время было более 300.000 объектов). DataGrip при старте пытается все это дело закешировать и поэтому надо сидеть и ждать пока она прогреется. Потом, все работает очень медленно и железка заметно напрягается и греется. Это и понятно, ведь основная фишка всех сред от JetBrains — это понимание контекста и инспекции. Но иногда это вредит.
PL/SQL Developer, в свою очередь, достает метаданные из БД (и кеширует их) по запросу, в первый момент обращения к объекту, так что ждать ничего не нужно.
2. Не поддерживает Java-source пакеты в БД
Возможно, эту фичу уже завезли, тогда прошу прощения. Но проверить возможности нет, т.к. с Oracle больше дел не имею. Уже лет 5 и на работе и дома на 100% только open source и, соответственно, основная производственная СУБД это Postgres. А моя рабочая кросс-СУБД среда теперь «SQL Workbench/J» и несколько консольных для работы в терминале. Единственный «закрытый» продукт, который я использую, это IntelliJ IDEA, в которую я влюбился 15 лет назад и с удовольствием плачу за лицензию :)
Честно говоря, ни разу не сталкивался с таким. Чаще всего проблема либо решается за 5 минут в чате, либо созвон для поиска в 2 головы и 4 руки с шарами экрана.
В моей команде индусы, китайцы, латиносы и предствители прочих этнических групп. Иногда бывает нереально сложно из-за того, что люди плохо говорят по английски. Они просто недослышивают и недопонимают, поэтому объяснение на пальцах и whiteboard работает гораздо эффективнее.
Перевести жену на удаленку. Вытащит не только на кофе, но и погулять.
Жена работает 100% времени из дома и мечтает об офисе по тем же причинам :)
Не всем это годится. По себе могу сказать, что больше 2х дней в неделю из дома работать не могу, очень тяжело. Потому что то, что можно обсудить с коллегами устно за пару минут с использованием whiteboard, превращается в час жевания соплей в чате, потом неминуемый созвон и повторение того же самого. К тому же, дома тебе никто не скажет: чувак, пошли попьем кофе. Не с кем пойти на обеденный перерыв. В итоге к вечеру с больной головой, спиной и красными глазами спохватываешься что в суматохе забыл позавтракать. Я уж не говорю про митинги — 10% информации проходит мимо, и не слышно о чем шепчутся коллеги, особенно если митинг спонтанно разбивается на параллельные секции.
JDBC позволяет работать с массивами нативно, и не нужно городить огород с сериализацией и временными таблицами.
https://jdbc.postgresql.org/documentation/head/arrays.html
Spring также поддерживает это и с JdbcTemplate и с JPA. Напоминаю, что для получения текущего коннекта в Spring нужно использовать DataSourceUtils. См исходный код для понимания того, как именно это нужно делать.
Кстати для JPA, если вы хотите хранить массивы Java в таблице как есть, используя нативные типы Postgres, то можно не тратить время на написание TypeDescriptor-ов самому, а просто взять готовую библиотеку от славного Vlad Mihalcea, использование которой он описал тут: https://vladmihalcea.com/how-to-map-java-and-sql-arrays-with-jpa-and-hibernate/
Просто в вашей практике хинты не были нужны. Когда решение тиражируется на десятки и сотни инстансов, а на местах нет грамотных DBA, то хинты зачастую это единственный выход. Бывает что сбор статистики по какой-то причине вообще отключен.
Кроме того, бывает что система разворачивается в секретном контуре и доступ к ней имеют только федеральные агенты, которые однако ничего не смыслят в IT.
Ещё вариант — нет доступа к исходникам, а есть запрос, который нужно оптимизнуть. Тогда можно сохранить для него специальный план. Был такой случай, когда в топ AWR на огромном федеральном проекте постоянно вылезал запрос, выполняемый ядром Oracle Application Server, и даже у самих сотрудников Oracle не было возможности это починить иначе чем сохраненным планом.
Вообще, все дело в наличии актуальной статистики. Иногда, однако, в течение дня характер и распределение данных меняются кардиально. Например, система принимает и обрабатывает миллионы бизнес объектов, и в какой-то момент запускается операция обработки полученных данных (консолидация, аналитика, matching и т.п.), а статистика собиралась 8 часов назад, т.к. на больших БД это довольно длительная и затратная операция. Результат — оптимизатор выбирает неверный алгоритм соединения таблиц или неверный индекс и т.п.
Поэтому все мои знакомые DBA и senior developers, в том числе сотрудники Oracle, используют хинты не просто иногда, а как обыденный инструмент каждый день.
Ни один оптимизатор не может сравниться с человеком, имеющим десятки лет опыта, знающим всю подноготную этого алгоритма.
Больше того, иногда очень хочется помочь оптимизатору, хотя бы указав с какой таблицы или индекса начинать. И это тоже боль — чувствовать себя беспомощным не имея хинтов в Постгресе.
Кроме того, предзагрузка метаданных по определению не может учитывать доступность объектов для разных ролей. Если в одном окне роль X даёт грант на объект роли Y, то в другом окне (сессии) для роли Y должно заработать автодополнение. И это работает во многих GUI.
Таким образом, для подобных моему сценариев использования было бы неплохо иметь возможность переключаться в режим real-time интроспекции, с возможностью быстрого сброса кэша по хоткею.
Как я написал выше, «Возможно, эту фичу уже завезли, тогда прошу прощения». Давно не работал с этим функционалом.
Далее по пункту 3.
Честно говоря, как-то все чересчур запутанно, непрозрачно. Концепция выбора активных data source/database/schema для консоли просто убивает.
У меня много PostgreSQL баз, в каждой из них несколько десятков схем, доступные разным ролям. Есть схемы с только с хранимыми процедурами (для эмуляции пакетов Oracle). Я обычно имею открытыми около 10 окон с кодом для разных бизнес-областей (например, для разных микросервисов или их кусков). Все окна имеют отдельные коннекты и разные настройки (авто-коммит, уровень изоляции и т.п.). Я постоянно переключаюсь между несколькими кластерами/базами с похожими схемами (но всё-же они отличаются).
1) Когда я переключаюсь на новую БД, я делаю это глобально. Это означает что я хочу чтобы все окна сразу закрыли коннект, и после этого, когда я отправляю первый запрос в любом окне, то это окно открывает новый коннект с текущей выбранной БД.
Да, вы поддерживаете возможность подключения к нескольким БД параллельно, но из моего опыта — это является источником граблей. Я и сам наступал, и много раз видел как другие по ошибке изменяют не ту БД, с которой, как им кажется, в данный момент работают. Цветные метки помогают, конечно, но не сильно.
2) Я не хочу кликать мышкой десятки схем только для того, чтоб заработало авто-дополнение. Если же я отмечаю только «Current schema», то авто-дополнение не будет работать для других схем, даже если всегда указывать имя схемы. И как установить эту текущую схему, не кликая мышкой? Кажется, никак. Это, наверное, самый неприятный момент. С другой стороны, мне совсем не нужны все схемы, особенно системные, поэтому вариант «All schemas» меня не устраивает. Слишком много лишней информации.
3) Если я выполню запрос «set role xxx», я хочу чтоб для текущей сессии автодополнение работало для всего, что доступно этой роли. До тех пор пока я не переключился на другую (set role yyy).
Я пишу «select * from xxx.» и теперь при нажатии на Ctrl+Space я хочу видеть доступные мне объекты схемы xxx и только. А если я не указал схему явно, что ж, для этого есть search_path (по умолчанию search_path = '"$user", public').
Даже если я знаю имя таблицы, все равно автодополнение не работает! Пример: «select * from xxx.yyy as t where t.» -> «ctrl+space» -> вываливается огромный список встроенных функций. В конце списка присутствуют некоторые системные поля типа ctid, а больше ничего! В общем, интроспекция просто не работает. Не могу же я каждый раз лазить по интерфейсу, менять настройки схем, потом нажимать refresh и ждать.
Нет времени больше писать, но есть и другие претензии. Поэтому из GUI тулзов я остаюсь на «SQL Workbench/J» как на наиболее адекватной из всех сред под Linux, что я пробовал. Там все работает ровно так, как это ожидается, без сюрпризов.
Ну и конечно, без консольных клиентов никуда, у меня всегда открыто несколько терминальных окон к разным БД (для Postgres это psql, pgcli). Они работают намного быстрей любых GUI сред, особенно что касается показа метаданных объектов и автодополнения кода.
«Таблица сильно разрежена, рекомендуется произвести очистку с помощью VACUUM [FULL]». На самом деле этот план получен на staging машине, где только что развернули свежий дамп в единой транзакции, и не выполнили ни единого DML запроса. То есть таблица ну никак не может быть разреженной.
3) Жалко, хотелось бы поделиться с коллегами. С другой стороны, правильно, пускай учат великий могучий, будет стимул :)
1) Под Firefox мелкие косячки, потестируйте, пожалуйста. Например, размножающиеся диаграммы и т.п.
2) Рекомендации попадаются из разряда «пальцем в небо», вот прям совсем мимо.
3) Планируется ли английская версия интерфейса? Это ведь бета для хабратестеров?
Чтоб не ждать так долго, можно было бы использовать метод половинного деления, каждый раз делая INSERT FROM SELECT во временную таблицу. Табличка небольшая, всего 1.6 миллиона записей.
Делим диапазон ID пополам (1..800K; 800K..1.6M) и копируем данные во временную таблицу. Запрос для одной из половинок завершится с ошибкой. Берём эту половину диапазона и выполняем два запроса для четвертинок (напр, 800K..1.2M;1.2M..1.6M) и так далее. Несколько минут — и вы получили бы ответ.
PostgresPro переводят самую обычную официальную документацию. Плюс расширенные версии для двух своих форков (Pro Standard и Enterprise). Итого доступны три перевода. Там даже можно открывать параллельно рус и англ версии.
Интервалы значит «пешком»-«бегом»-«пешком»-«бегом», причем продолжительность повторов и их количество со временем меняются, пока не доходят до 5км бега без остановки. К примеру, план первой тренировки: поочередно, 60 секунд бега и 90 секунд ходьбы на протяжении 20 минут + разминка и заминка.
Программа была разработана тренером для своей мамы, которая никогда не занималась спортом.
Пару раз бегали с сыном, он пытался со мной разговаривать. Куда там, я даже «да» и «нет» не мог ответить, сразу темнота в глазах :) И это после трех месяцев регулярных пробежек через день.
Вот вам мой опыт. В 35 лет начал бегать по по пулярной программе "Couch to 5K". Это программа интервальных тренировок разработанная для тех, кто никогда не занимался спортом и хочет бегать 5 км для укрепления здоровья. Начал я ранней весной, 5 км достиг через 3 месяца и бегал пол лета, через день. Потом в один прекрасный день во время бега у меня в глазу лопнул сосуд на сетчатке. Теперь этот глаз имеет слепую зону, которая восстановлению не подлежит. Врач ещё предупредил что может совсем сетчатка отслоится, целиком, но обошлось. Мозг перестроился со временем, конечно, и это меня не беспокоит и даже не мешает работать. Но бег категорически запрещен.
Так что подумайте — оно вам надо? :)
Мерять производительность способом, описанным в статье совершенно неверно.
Автор, погугли "JMH", эта библиотека является частью JDK. В сети куча примеров и видео, в том числе на русском от её автора — Алексея Шипилёва.
Кроме того, присоединяюсь к предыдущим комментаторам. В целом, посыл статьи правильный, описывает известный антипаттерн. Но приведённый код из раздела "как надо" не прошёл бы ревью.
Wikipedia утверждает следующее:
Common table expressions are supported by Teradata, DB2, Firebird, Microsoft SQL Server, Oracle (with recursion since 11g release 2), PostgreSQL (since 8.4), MariaDB (since 10.2), MySQL (since 8.0), SQLite (since 3.8.3), HyperSQL and H2 (experimental).
Теперь хочу бросить маленький камушек в сторону DataGrip. Среда отличная, конечно же, и я использовал в редких случаях её немного урезанную версию в составе IntelliJ IDEA Ultimate. Но именно для работы с Oracle она мне в своё время не подошла по двум причинам.
PL/SQL Developer, в свою очередь, достает метаданные из БД (и кеширует их) по запросу, в первый момент обращения к объекту, так что ждать ничего не нужно.
Жена работает 100% времени из дома и мечтает об офисе по тем же причинам :)
Не всем это годится. По себе могу сказать, что больше 2х дней в неделю из дома работать не могу, очень тяжело. Потому что то, что можно обсудить с коллегами устно за пару минут с использованием whiteboard, превращается в час жевания соплей в чате, потом неминуемый созвон и повторение того же самого. К тому же, дома тебе никто не скажет: чувак, пошли попьем кофе. Не с кем пойти на обеденный перерыв. В итоге к вечеру с больной головой, спиной и красными глазами спохватываешься что в суматохе забыл позавтракать. Я уж не говорю про митинги — 10% информации проходит мимо, и не слышно о чем шепчутся коллеги, особенно если митинг спонтанно разбивается на параллельные секции.