|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
Здравствуйте. Переходим с ORACLE на PostgreSQL, есть вопрос. Есть ли в PostgreSQL аналог Ассоциативных массивов ORACLE? Кейс использования сейчас такой: Объявляется массив в пакете, для того чтобы в рамках сессии работать с оперативным пулом данных (без необходимости постоянной вычитки данных из таблиц) и из разных хранимых объектов иметь оперативный доступ к этим данным. Ключевые требования: 1. Набор данных должен быть "глобальным", т.е. доступен из разных хранимых объектов в пределах сессии 2. Данные должны храниться в Оперативной памяти. Постоянная физическая вычитка из таблицы не подходит - хранимых объектов и операций над массивом огромное количество, постоянные INSERT и UPDATE в таблице не только замедлят работу, но и породят конкуренцию 3. Возможность задавать массивы с разной структуры Пример того что сейчас используется на базе ORACLE: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34.
Есть ли в PostgreSQL возможность как-то воспроизвести этот функционал (здесь представлен просто анонимный PL/SQL блок, но вообще объявление типов происходит в пакете, для использования в пределах сессии). А также сразу вопрос - использование TEMPORARY TABLE для этих целей, в которой была бы реализована необходимая структура данных, это 100% физическое чтение данных с диска? То есть работа как с обычной таблицей. Или TEMPORARY TABLE работают как-то по другому, например находятся в оперативной памяти? Заранее благодарю. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 08:47 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
VanDOS, Частично можно реализовать через hstore , но это только локально. Другой вариант это jsonb Глобальные переменные реализовать можно через временные таблицы, которые уничтожаются по коммиту. Временные талицы все равно пишутся на диск, особенно если писать часто. Но результат может кешироваться. Единственное что они пишутся быстрее, чем обычные таблицы, так как не проходят через журнал предзаписи . Встречал еще такой вариант , но на практике не использовал. В целом при переходе с оракла на пг придется пересматривать логику работы многих функций, и менять их с учетом специфики новой среды ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 09:57 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
А если попробовать сделать табличное пространство в памяти (например tmpfs) и использовать его для временных таблиц. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 10:21 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
Guzya, Хм, интересная мысль. Но по-моему опасно, при частой записи во временные таблицы последние разрастаются и можно словить не хватку места, особенно в случае если будет много пользователей. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 10:44 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
VanDOS, Напрямую такого функционала нет, но можете посмотреть на сторонние расширения: pg_variables pgtt ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 11:04 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
Swa111, Guzya, Вариант временных таблиц я сейчас рассматриваю как наиболее подходящий, только уничтожаются не по Коммиту, а по завершению сессии. (просто в начале каждой итерации таблица будет принудительно очищаться). Меня интересует, возможны ли проблемы с производительностью системы и в целом с ее стабильностью. Если параллельных сессий обработки будет до 50 (читай - 50 таких таблиц), и каждая из этих таблиц будет ОЧЕНЬ активно использоваться своей сессией (INSERT, UPDATE, MERGE, DELETE). Как вам кажется, велики ли риски? Также, изучая эту тему, довольно часто видел следующие комментарии: Такой способ определения глобальных сессионных переменных все-такие является костылем и использоваться должен лишь в крайних случаях. При использовании временных таблиц возможно разрастание системного каталога и деградация производительности со временем. Хотелось бы услышать мнение сообщества. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 11:06 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
Я не очень понимаю, у Вас каждая сессия будет создавать свои временные таблицы и доступны они будут только в пределах этой сессии, т.е. из другой сессии обратиться Вы к ним не сможете о каком параллельном доступе Вы говорите? К тому же не известны объемы данных с которыми Вы собираетесь работать и на каких вычислительных ресурсах, поэтому нет возможности понять 50 сессий это тяжело будет или нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 11:24 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
Guzya, Про параллельность, я имел ввиду что 50 сессий работают параллельно (каждая сессия прогоняет определенную последовательность хранимых объектов). Это понятно, что каждая сессия работает со своей таблицей. Но работа с каждой из этих таблиц увеличит общую нагрузку на систему. Вряд ли сейчас получится четко описать ресурсы и активность использования данных в таблице. Из того что можно сказать точно, это то что переменных в таблице будет несколько тысяч. И каждый хранимый объект будет активно добавлять, изменять, удалять переменные. Здесь больше интересовала теория, чем грозит такой кейс использования. На сколько вариант может быть рабочим. Я не DBA, поэтому немного не понимаю что это: "При использовании временных таблиц возможно разрастание системного каталога" ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 11:47 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
"При использовании временных таблиц возможно разрастание системного каталога" Видимо связанно с тем, что процесс autovacuum (очистка таблиц от не используемых строк, для переиспользования места в файле) автоматом не обрабатывает временные таблицы. Соответственно удаляемые\обновляемые строки физически не вычищаются из файлов и новые строки всегда увеличивают файл с таблицей. Демон автоочистки не может прочитать и, как следствие, сжимать и анализировать временные таблицы. По этой причине соответствующие операции очистки и анализа следует выполнять, вызывая SQL-команды в рамках сеанса. Например, если временную таблицу планируется использовать в сложных запросах, будет разумным выполнить для неё ANALYZE после того, как она будет наполнена. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 12:10 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
Guzya "При использовании временных таблиц возможно разрастание системного каталога" Видимо связанно с тем, что процесс autovacuum (очистка таблиц от не используемых строк, для переиспользования места в файле) автоматом не обрабатывает временные таблицы. Соответственно удаляемые\обновляемые строки физически не вычищаются из файлов и новые строки всегда увеличивают файл с таблицей. Нет, речь о том, что create temp table пишется в pg_class, pg_attribute и прочее что нужно. И если они вдруг начинают занимать пяток гигабайт - становится невесело всем. Поэтому времянки в postgresql нельзя создавать-удалять сотнями в секунду. Swa111 Временные талицы все равно пишутся на диск, особенно если писать часто relation extend всегда пишется на диск, место под данные резервируется. Сами данные - живут по мере возможности в temp_buffers private памяти backend'а. VanDOS А также сразу вопрос - использование TEMPORARY TABLE для этих целей, в которой была бы реализована необходимая структура данных, это 100% физическое чтение данных с диска? То есть работа как с обычной таблицей. Или TEMPORARY TABLE работают как-то по другому, например находятся в оперативной памяти? Используют temp_buffers Tom LaneWe *reserve space* on disk, typically by writing zeroes. But actual data would only get spilled there if we run out of temp buffer space. It's entirely possible for a temp table's data to stay in memory for its whole existence. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 12:46 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
VanDOS Guzya, Про параллельность, я имел ввиду что 50 сессий работают параллельно (каждая сессия прогоняет определенную последовательность хранимых объектов). Это понятно, что каждая сессия работает со своей таблицей. Но работа с каждой из этих таблиц увеличит общую нагрузку на систему. Вряд ли сейчас получится четко описать ресурсы и активность использования данных в таблице. Из того что можно сказать точно, это то что переменных в таблице будет несколько тысяч. И каждый хранимый объект будет активно добавлять, изменять, удалять переменные. Здесь больше интересовала теория, чем грозит такой кейс использования. На сколько вариант может быть рабочим. Вариант рабочий, но с некоторыми особенностями. Как можно реже создавать временные таблицы, если есть возможность точно сказать что в таблице больше нет данных, то лучше сделать truncate вместо drop, таблицу создавать командой create temp table if not exists. После вставки большого объема данных делать analyze, для того что бы у PG было больше информации о эффективном использовании индексов. При этом часто analyze делать тоже нельзя, операция не самая быстрая. по наблюдениям vacuum для временных таблиц бесполезен, хотя для сжатия таблиц есть интересный вариант . Если есть возможность передавать параметры через параметры функций, то нужно использовать его. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 14:02 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
VanDOS Пример того что сейчас используется на базе ORACLE А где, простите, в этом примере "массивы с разной структуры"? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 14:03 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
VanDOS, Временные таблицы для вашей задачи подходят ОЧЕНЬ плохо. в pl/pgsql тоже нет ничего удобного но вот рекомендую почитать https://www.postgresql.org/docs/12/plperl-global.html оно специально сделано как раз для подобной задачи и можно или вообще всю логику через pl/perl сделать или какие то хранимки-обертки для работы с %_SHARED из pl/pgsql сделать (но это сильно медленее будет чем напрямую из pl/perl к ним обращаться). странно что никто не порекомендовал. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 21:59 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
Maxim Boguk, А можно подробнее, почему не подходят? Именно из-за постоянных INSERT/UPDATE/DELETE которые работают с диском? Я так понимаю, есть мнение, что они все равно будут жить в оперативной памяти/кэшэ. Насчет PL/Perl и PL/Python читал, но дело в том, что основная логика будет реализована в процедурах/функциях нативного Постгреса, и эти глобальные переменные нужно получить именно из процедур PLPGSQL . Если глобальные данные хранить в PL/Perl, то и всю бизнес логику нужно писать на PL/Perl ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 15:17 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
VanDOS Maxim Boguk, А можно подробнее, почему не подходят? Именно из-за постоянных INSERT/UPDATE/DELETE которые работают с диском? Я так понимаю, есть мнение, что они все равно будут жить в оперативной памяти/кэшэ. будут то они будут но autovacuum на временные таблицы не работает и вам приедется свою логику делать когда вашу временную таблицу в процессе работы вакумить (а это надо делать часто но не слишком часто) иначе у вас там будут копиться старые tuples ровно как в обычной таблице и временная таблица а)будет пухнуть пока не начнет на диск физически писаться (потому что в temp buffers не будет влезать) б)просто будет все очень медленно работать просто как это выглядит на практике без рабочего vacuum по временной таблице: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40.
Если глобальные данные хранить в PL/Perl, то и всю бизнес логику нужно писать на PL/Perl Я уже написал что это не обязательно можно сделать всего 2 хранимки set_global_hash_val / get_global_hash_val на pl/perl а все остальное на pl/pgsql оно 100% будет работать быстрее чем временная таблица без настроенного вакума в вашем случае (и возможно даже быстрее чем временная таблица с настроенным вакумом но тут уже надо тестировать будет). ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 17:03 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
Maxim Boguk у вас там будут копиться старые tuples а если нет ни update ни delete, сессия перед отстрелом сервера (лимит 150 мб) выдает pg_relation_size около 8 мб? (длинных текстовых полей нет) (PostgreSQL 10.10 on x86_64-pc-linux-musl, compiled by gcc (Alpine 8.3.0) 8.3.0, 64-bit) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.09.2020, 23:54 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
VanDOS, Добрый день, подскажите пожалуйста, как решили вопрос с ассоциативным массивом при переходе с Oracle на Postgres? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 18:16 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
Tata_K VanDOS, Добрый день, подскажите пожалуйста, как решили вопрос с ассоциативным массивом при переходе с Oracle на Postgres? Offtopic Подумали, подумали, посчитали, посчитали и решили, решили не переходить с Oracle на Postgres :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 19:00 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
SQL*Plus, OfftopicВалера, если даже ты в этот форум заглядываешь, видать совсем у оракла дела плохо :-) (Хотя СУБД - отл). ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 19:23 |
|
Аналог Ассоциативных массивов ORACLE в PostgreSQL
|
|||
---|---|---|---|
#18+
Павел Лузанов, Offtipic Нет, Паша, у Oracle дела хорошо. В этот форум заглянул впервые и увидел, что у постгреса, как СУБД, дела по-прежнему плохи :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2021, 20:19 |
|
|
start [/forum/search_topic.php?author=alex_by_guest&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
others: | 9821ms |
total: | 9991ms |
0 / 0 |