Затраты на процедурные языки в PostgreSQL (plpython / plsql / pllua…)

Я пытаюсь найти информацию о пользовательских функциях PostgreSQL в производительности процедурных языков для задач реального времени.

1. Как они сравниваются со встроенными функциями?
2. Есть ли какая-либо разница (в накладных расходах), как Postgres вызывает / управляет функциями plpython и plpgsql против pllua (меня интересует интеграция Postgres / сторона контекста / передачи данных, а не сама виртуальная машина)?
3. Является ли контекст большими накладными расходами? Могу ли я использовать его для отображения данных в реальном времени (скажем, 1000 запросов / с))
4. Есть ли какая-то польза от написания пользовательских функций в plpgsql, чем в других pg / language? В документации они перечисляют преимущества, но я думаю, что они применимы ко всем процедурным языкам postgresql.

Связанные выводы:

• Скорость языков PL для нетипичного использования
• Производительность языка функций PostgreSQL: C против PL / PGSQL

1. UDF в интерпретируемых языках почти всегда работают медленнее, чем UDF, написанные на C или встроенных функциях, при прочих равных.

2. Каждая языковая привязка имеет свой код для соединения PostgreSQL с языком, с разной степенью оптимизации, разными способами передачи некоторых типов данных и т. Д. Таким образом, вариации, безусловно, существуют. Он не должен быть огромным, если вы не передаете тип данных, который обрабатывается одним языком очень по-разному, например, один передает hstoreстроку как строку, а другой преобразует ее в форму dict.

3. Непонятно, что такое «контекст». Можете ли вы использовать его для «отображения данных в реальном времени» ... ну, это зависит от того, что делает функция, и достаточно ли быстро она работает на сервере, на котором она работает, для клиентов, для которых она предназначена, и для ваших требований. Как долго это кусок строки? Benchmark.

4. PL / PgSQL проще в написании и предлагает более быстрый доступ к SQL. Как правило, лучше, когда вам нужно обернуть немного логики вокруг большого количества SQL. Он очень медленный для математических операций и сложных алгоритмов, поэтому следует по возможности избегать чисто вычислительного кода в PL / PgSQL в пользу C или более быстрого процедурного языка.

Ускорения при повторной реализации кода PL / PgSQL в C могут варьироваться от незначительного до более 1000 раз. Все зависит от того, что на самом деле делает код.

(Этот тип вопросов не подходит для Stack Exchange, так как сложнее получить окончательный ответ)

это довольно сложно сказать. это действительно зависит от того, что вы делаете. например: PL / pgSQL - это замечательно, если в вас есть большие операторы SQL - это действительно сходит с ума, если вы получаете все виды ветвления, управления подстроками и все такое.

Вы действительно должны проверить от случая к случаю.

Является ли контекст большими накладными расходами? Могу ли я использовать его для отображения данных в реальном времени (скажем, 1000 запросов / с))

Производительность зависит от аппаратного обеспечения и сложности ваших функций. Я создал устройство, которое работало на небольшом 12-ядерном сервере и FusionIO-карте (общая стоимость 10000 евро) и выполняло около 2500 транзакций в секунду с 20 одновременными пользователями. Каждая транзакция вызывает 29 хранимых процедур для обработки данных и возврата некоторой полезной информации клиенту. Некоторые функции выполняют только один запрос, другие - пару запросов. Всего он выполняет около 200000 операторов INSERT, SELECT и UPDATE в секунду.

Все это написано на PL / SQL, PL / pgSQL и PL / PerlU. И я уверен, что система может работать даже быстрее, когда (некоторые) функции переписаны на C.

В этом устройстве большая часть производительности достигается благодаря плате SSD. На одном вращающемся диске мы никогда не получим такую ​​производительность. Дешевые SSD-накопители также выходят из строя, они работают в течение часа (из-за кеширования raid-карты), а затем игра заканчивается. Карта FusionIO стоит дорого, но это очень хорошая инвестиция, когда вы связаны с IO.