Привет. Кто-Нибудь делал бенчмарки между разными способами извлечения текстовых значений из

Question

Привет. Кто-Нибудь делал бенчмарки между разными способами извлечения текстовых значений из

тяжёлых JSONB? (улетают в TOAST, точный размер не принципиален)

Какой из этих вариантов предпочтительнее и почему?

1. jsonb -> ключ1 -> ключ2 ->> ключ3
2. jsonb #>> '{ключ1, ключ2, ключ3}’
3. jsonb_extract_path_text(jsonb, ключ1, ключ2, ключ3)
4. jsonb_path_query_first(jsonb, '$.ключ1.ключ2.ключ3')::text

На своих данных завтра сам замеры сделаю, но вдруг у кого-то есть опыт или аргументы за/против по этим способам.

#backend #devops #pgsql #programming #russian

0

15.05.2023

6 ответов

34 просмотра

Nick Nalbantov Автор вопроса

Большое спасибо за ответ, сохраню в памятки 👍

0

15.05.2023

Nikita Glukhov

Nick Nalbantov
Большое спасибо за ответ, сохраню в памятки 👍

Кстати, вот сам доклад "Understanding JSONB Performance", прошедший в Нью-Йорке в конце 2021 года: http://www.sai.msu.su/~megera/postgres/talks/jsonb-pgconfnyc-2021.pdf

0

15.05.2023

Yuriy

Опыт показывает, пиши функциями сложные множественные выборки, с кешированием и индексированием. Одинаково хорошо работает как с json, jsonb. По скорости - с базой до нескольких терабайт, почти равнозначно, без особых тормозов. Бенчмарки не юзал, но прямые выборки из приложений намного медленнее, нежели подготовленные функциями view-представления

0

15.05.2023

Nikita Glukhov

Nikita Glukhov
Кстати, вот сам доклад "Understanding JSONB Perfo...

У Олега в той же директории talks/ лежит куча докладов по теме JSONB, в которых можно найти много полезного.

0

15.05.2023

Nikita Glukhov

Nikita Glukhov
На тяжёлых JSONB в TOAST основное время будет уход...

Забыл еще уточнить, что цепочка операторов -> на больших размерах начинает отставать от всех остальных вариантов из-за оверхеда копирования промежуточных значений, растущего вместе с ростом этих значений, при их передаче между операторами (поэтому там нигде нет красных прямоугольников справа за исключением nesting = 0).

0

15.05.2023

Nikita Glukhov · Accepted Answer

На тяжёлых JSONB в TOAST основное время будет уходить на первоначальное извлечение из TOAST (поиск чанков по индексу, их склеивание, декомпрессию значения), поэтому заметной разницы в скорости между этими функциями, скорее всего, не будет. А для коротких JSONB или предварительно извлеченных из TOAST c помощью какого-то jsonb-оператора в подзапросе разница уде должна быть заметна. jsonb_path_query_first() будет самой медленной из-за оверхеда интерпретации jsonpath, а также из-за оверхеда создания скалярного JSONB и лишнего cast в text на конце. У #>> основной оверхед в извлечении элементов из массива, а у -> -- в интерпретации нескольких операторов и передачи промежуточных результатов. jsonb_extract_path_text() -- это то же самое, что и #>>. Помимо этих вариантов, есть еще и пятый вариант с subscripting, у которого, как и у jsonb_path_query_first(), будет оверхед jsonb::text: 5. jb['ключ1']['ключ2']['ключ3']::text Для одного из докладов мы с Олегом Бартуновым исследовали скорость этих вариантов в зависимости от вложенности и размера JSONB. На приведенном графике изображен наилучший вариант для каждого из сочетаний вложенность/размер.

172 похожих чатов

Привет. Кто-Нибудь делал бенчмарки между разными способами извлечения текстовых значений из

6 ответов

Похожие вопросы