Гость
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Аналог Ассоциативных массивов ORACLE в PostgreSQL / 21 сообщений из 21, страница 1 из 1
16.05.2020, 08:47
    #39958277
VanDOS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
Здравствуйте.

Переходим с 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.
DECLARE
  
  TYPE t_var IS RECORD
  (
    value  VARCHAR2 (4000),
    source VARCHAR2 (10)
  );

  TYPE t_vars IS TABLE OF t_var INDEX BY VARCHAR2 (100);
  
  col_vars t_vars;
  
  ind VARCHAR2 (100);

BEGIN
  -- Заполняем массив
  col_vars ('city').value := 'Moscow';
  col_vars ('city').source := '1';

  col_vars ('request').value := '12345';
  col_vars ('request').source := '2';

  col_vars ('result').value := 'success';
  col_vars ('result').source := '2';
  
  -- Работаем с массивом
  ind := col_vars.first;
  LOOP
    EXIT WHEN ind IS NULL;
    DBMS_OUTPUT.PUT_LINE (ind || ' - ' || col_vars (ind).value || ' : ' || col_vars (ind).source);
    ind := col_vars.NEXT (ind);
  END LOOP;

END;



Есть ли в PostgreSQL возможность как-то воспроизвести этот функционал (здесь представлен просто анонимный PL/SQL блок, но вообще объявление типов происходит в пакете, для использования в пределах сессии).

А также сразу вопрос - использование TEMPORARY TABLE для этих целей, в которой была бы реализована необходимая структура данных, это 100% физическое чтение данных с диска? То есть работа как с обычной таблицей. Или TEMPORARY TABLE работают как-то по другому, например находятся в оперативной памяти?

Заранее благодарю.
...
Рейтинг: 0 / 0
16.05.2020, 09:57
    #39958285
Swa111
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
VanDOS,



Частично можно реализовать через hstore , но это только локально.
Другой вариант это jsonb

Глобальные переменные реализовать можно через временные таблицы, которые уничтожаются по коммиту. Временные талицы все равно пишутся на диск, особенно если писать часто. Но результат может кешироваться. Единственное что они пишутся быстрее, чем обычные таблицы, так как не проходят через журнал предзаписи .

Встречал еще такой вариант , но на практике не использовал.

В целом при переходе с оракла на пг придется пересматривать логику работы многих функций, и менять их с учетом специфики новой среды
...
Рейтинг: 0 / 0
16.05.2020, 10:21
    #39958290
Guzya
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
А если попробовать сделать табличное пространство в памяти (например tmpfs) и использовать его для временных таблиц.
...
Рейтинг: 0 / 0
16.05.2020, 10:44
    #39958292
Swa111
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
Guzya,

Хм, интересная мысль. Но по-моему опасно, при частой записи во временные таблицы последние разрастаются и можно словить не хватку места, особенно в случае если будет много пользователей.
...
Рейтинг: 0 / 0
16.05.2020, 11:04
    #39958298
Павел Лузанов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
VanDOS,

Напрямую такого функционала нет, но можете посмотреть на сторонние расширения:
pg_variables
pgtt
...
Рейтинг: 0 / 0
16.05.2020, 11:06
    #39958299
VanDOS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
Swa111, Guzya,

Вариант временных таблиц я сейчас рассматриваю как наиболее подходящий, только уничтожаются не по Коммиту, а по завершению сессии. (просто в начале каждой итерации таблица будет принудительно очищаться).

Меня интересует, возможны ли проблемы с производительностью системы и в целом с ее стабильностью. Если параллельных сессий обработки будет до 50 (читай - 50 таких таблиц), и каждая из этих таблиц будет ОЧЕНЬ активно использоваться своей сессией (INSERT, UPDATE, MERGE, DELETE).

Как вам кажется, велики ли риски?

Также, изучая эту тему, довольно часто видел следующие комментарии:
Такой способ определения глобальных сессионных переменных все-такие является костылем и использоваться должен лишь в крайних случаях.
При использовании временных таблиц возможно разрастание системного каталога и деградация производительности со временем.


Хотелось бы услышать мнение сообщества.
...
Рейтинг: 0 / 0
16.05.2020, 11:24
    #39958305
Guzya
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
Я не очень понимаю, у Вас каждая сессия будет создавать свои временные таблицы и доступны они будут только в пределах этой сессии,
т.е. из другой сессии обратиться Вы к ним не сможете о каком параллельном доступе Вы говорите?

К тому же не известны объемы данных с которыми Вы собираетесь работать и на каких вычислительных ресурсах,
поэтому нет возможности понять 50 сессий это тяжело будет или нет.
...
Рейтинг: 0 / 0
16.05.2020, 11:47
    #39958309
VanDOS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
Guzya,

Про параллельность, я имел ввиду что 50 сессий работают параллельно (каждая сессия прогоняет определенную последовательность хранимых объектов). Это понятно, что каждая сессия работает со своей таблицей. Но работа с каждой из этих таблиц увеличит общую нагрузку на систему.

Вряд ли сейчас получится четко описать ресурсы и активность использования данных в таблице. Из того что можно сказать точно, это то что переменных в таблице будет несколько тысяч. И каждый хранимый объект будет активно добавлять, изменять, удалять переменные.

Здесь больше интересовала теория, чем грозит такой кейс использования. На сколько вариант может быть рабочим.

Я не DBA, поэтому немного не понимаю что это:
"При использовании временных таблиц возможно разрастание системного каталога"
...
Рейтинг: 0 / 0
16.05.2020, 12:10
    #39958311
Guzya
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
"При использовании временных таблиц возможно разрастание системного каталога"

Видимо связанно с тем, что процесс autovacuum (очистка таблиц от не используемых строк, для переиспользования места в файле)
автоматом не обрабатывает временные таблицы.
Соответственно удаляемые\обновляемые строки физически не вычищаются из файлов и новые строки всегда увеличивают файл с таблицей.




Демон автоочистки не может прочитать и, как следствие, сжимать и анализировать временные таблицы.
По этой причине соответствующие операции очистки и анализа следует выполнять, вызывая SQL-команды в рамках сеанса.
Например, если временную таблицу планируется использовать в сложных запросах, будет разумным выполнить для неё ANALYZE
после того, как она будет наполнена.
...
Рейтинг: 0 / 0
16.05.2020, 12:46
    #39958316
Melkij
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
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.
...
Рейтинг: 0 / 0
16.05.2020, 14:02
    #39958343
Swa111
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
VanDOS
Guzya,

Про параллельность, я имел ввиду что 50 сессий работают параллельно (каждая сессия прогоняет определенную последовательность хранимых объектов). Это понятно, что каждая сессия работает со своей таблицей. Но работа с каждой из этих таблиц увеличит общую нагрузку на систему.

Вряд ли сейчас получится четко описать ресурсы и активность использования данных в таблице. Из того что можно сказать точно, это то что переменных в таблице будет несколько тысяч. И каждый хранимый объект будет активно добавлять, изменять, удалять переменные.

Здесь больше интересовала теория, чем грозит такой кейс использования. На сколько вариант может быть рабочим.


Вариант рабочий, но с некоторыми особенностями. Как можно реже создавать временные таблицы, если есть возможность точно сказать что в таблице больше нет данных, то лучше сделать truncate вместо drop, таблицу создавать командой create temp table if not exists.

После вставки большого объема данных делать analyze, для того что бы у PG было больше информации о эффективном использовании индексов. При этом часто analyze делать тоже нельзя, операция не самая быстрая. по наблюдениям vacuum для временных таблиц бесполезен, хотя для сжатия таблиц есть интересный вариант .

Если есть возможность передавать параметры через параметры функций, то нужно использовать его.
...
Рейтинг: 0 / 0
16.05.2020, 14:03
    #39958344
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
VanDOS
Пример того что сейчас используется на базе ORACLE

А где, простите, в этом примере "массивы с разной структуры"?
...
Рейтинг: 0 / 0
16.05.2020, 21:59
    #39958455
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
VanDOS,

Временные таблицы для вашей задачи подходят ОЧЕНЬ плохо.
в pl/pgsql тоже нет ничего удобного

но вот рекомендую почитать
https://www.postgresql.org/docs/12/plperl-global.html
оно специально сделано как раз для подобной задачи
и можно или вообще всю логику через pl/perl сделать или какие то хранимки-обертки для работы с %_SHARED из pl/pgsql сделать (но это сильно медленее будет чем напрямую из pl/perl к ним обращаться).


странно что никто не порекомендовал.
...
Рейтинг: 0 / 0
18.05.2020, 15:17
    #39958967
VanDOS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
Maxim Boguk,

А можно подробнее, почему не подходят?
Именно из-за постоянных INSERT/UPDATE/DELETE которые работают с диском? Я так понимаю, есть мнение, что они все равно будут жить в оперативной памяти/кэшэ.

Насчет PL/Perl и PL/Python читал, но дело в том, что основная логика будет реализована в процедурах/функциях нативного Постгреса, и эти глобальные переменные нужно получить именно из процедур PLPGSQL . Если глобальные данные хранить в PL/Perl, то и всю бизнес логику нужно писать на PL/Perl
...
Рейтинг: 0 / 0
18.05.2020, 17:03
    #39959038
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
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.
psql -q
maxim=> create  temp table a (id integer primary key, val int not null);
maxim=> create index a_val on a(val);
maxim=> insert into a values (1, 1);
maxim=> \dt+ a
                      List of relations
  Schema   | Name | Type  | Owner |    Size    | Description 
-----------+------+-------+-------+------------+-------------
 pg_temp_3 | a    | table | maxim | 8192 bytes | 
(1 row)

maxim=> select pg_size_pretty(pg_total_relation_size('a'));
 pg_size_pretty 
----------------
 40 kB
(1 row)

maxim=> explain analyze select * from a;
                                          QUERY PLAN                                           
-----------------------------------------------------------------------------------------------
 Seq Scan on a  (cost=0.00..32.60 rows=2260 width=8) (actual time=0.016..0.017 rows=1 loops=1)
 Planning Time: 0.188 ms
 Execution Time: 0.051 ms
(3 rows)

maxim=> select 'update a set val=val+1 where id=1;' from generate_series(1, 1000000)
maxim-> \gexec
maxim=> select pg_size_pretty(pg_total_relation_size('a'));
 pg_size_pretty 
----------------
 48 MB
(1 row)

maxim=> explain analyze select * from a;
                                              QUERY PLAN                                              
------------------------------------------------------------------------------------------------------
 Seq Scan on a  (cost=0.00..11204.62 rows=776762 width=8) (actual time=21.329..21.330 rows=1 loops=1)
 Planning Time: 0.102 ms
 Execution Time: 21.353 ms
(3 rows)



Если глобальные данные хранить в PL/Perl, то и всю бизнес логику нужно писать на PL/Perl
Я уже написал что это не обязательно можно сделать всего 2 хранимки set_global_hash_val / get_global_hash_val на pl/perl а все остальное на pl/pgsql
оно 100% будет работать быстрее чем временная таблица без настроенного вакума в вашем случае
(и возможно даже быстрее чем временная таблица с настроенным вакумом но тут уже надо тестировать будет).
...
Рейтинг: 0 / 0
16.09.2020, 23:54
    #39999603
Алекссс
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
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)
...
Рейтинг: 0 / 0
Период между сообщениями больше года.
06.10.2021, 18:16
    #40102438
Tata_K
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
VanDOS,

Добрый день,
подскажите пожалуйста, как решили вопрос с ассоциативным массивом при переходе с Oracle на Postgres?
...
Рейтинг: 0 / 0
06.10.2021, 19:00
    #40102449
SQL*Plus
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
Tata_K
VanDOS,

Добрый день,
подскажите пожалуйста, как решили вопрос с ассоциативным массивом при переходе с Oracle на Postgres?


Offtopic
Подумали, подумали, посчитали, посчитали и решили, решили не переходить с Oracle на Postgres :-)
...
Рейтинг: 0 / 0
06.10.2021, 19:23
    #40102451
Павел Лузанов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
SQL*Plus,

OfftopicВалера, если даже ты в этот форум заглядываешь, видать совсем у оракла дела плохо :-) (Хотя СУБД - отл).
...
Рейтинг: 0 / 0
06.10.2021, 20:19
    #40102464
SQL*Plus
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
Павел Лузанов,

Offtipic
Нет, Паша, у Oracle дела хорошо.
В этот форум заглянул впервые и увидел, что у постгреса, как СУБД, дела по-прежнему плохи :-)
...
Рейтинг: 0 / 0
07.10.2021, 10:11
    #40102574
yens_gjytk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналог Ассоциативных массивов ORACLE в PostgreSQL
Tata_K,

Мы использовали hstore и jsonb + для глобального доступа set_config / current_setting
...
Рейтинг: 0 / 0
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Аналог Ассоциативных массивов ORACLE в PostgreSQL / 21 сообщений из 21, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]