Привет. Мне нужно хранить и изредка отдельной миграцией обновлять где-то миллион

довольно ветвистых объектов, в json они верят по 200 кб.
Для простоты решил затестить постгрес и в-общем, результаты неутешительные, такая миграция (просто постоянный поток цельных апдейтов jsonb поля) в один тред добавляет cpu где-то процентов 30-40 и в итоге миграция занимает почти сутки.
Так как с маленькими json все было ок, подозреваю, что проблема в размере и что база захлебывается операциями с toast'ами.
Вообще говоря, я нахожу это странным, заапдейтить миллион jsonов по 200кб (даже не по метру) не кажется большим хайлоадом, но вот так вот.
(база - амазон аврора, если интересно).
Сразу скажу, что идея переделать "большие" json на несколько маленьких мне не нравится, потому что тогда 1 лям строк превратится в 100.

Соответственно, вопрос, можно ли здесь что-то сделать? Подтюнить как-то базу или таблицу? Или постгрес совсем для этого не подходит?

Что пробовали:
1. bytea вместо jsonb - без изменений
2. Gzip + bytea вместо jsonb - раза в 2 быстрее
3. Mongodb - без оптимизаций оказалась в 2 раза быстрее pg

Думаем затестить large objects store в постгре пока, но что-то этот вариант не нравится.

больше 2К вызывает неименуемые оверхед

Двух килобайт, в смысле? Ну это же совсем мало :)

ну такие ограничения у postgres by design

А почему 2? Минимальный размер тоста же 8кб

думаю, что central имел ввиду, если без TOAST. Если с TOAST, то можете 200 кб хранить:) Просто будет обращение к стороннему месту хранения, а не в рамках страницы

Это как раз понятно. Я и говорю, что с ростом размера json растёт потребление cpu базой, в который она в итоге и упирается. И я подозреваю, что это как раз нарезка json'ов на тосты.

Для меня это объект среднего размера, мне тут нужно many2many агрегаты считать между несколькими большими таблицами и казалось, что сгенерить и записать один средний 200кб json проще, чем 100 маленьких.

ну, может просто в вашем случае не нужно хранить в jsonb, раз это не оптимальное решение для вас? иначе у вас все объекты в TOAST лежат

У меня ветвистый и вложенный объект и как раз в json его хранить суперудобно, иначе он превратится в кучу джоинов на х100 строк от текущего. Ок, спасибо все равно, буду посмотреть.

Размер страницы 8 КБ, но постгрес старается в одну страницу впихнуть хотя бы четыре строки (и toast-таблиц это тоже касается).

Вот эти все олапы это конечно то, чего я так хотел избежать :(

Мне не нужны отчёты. Короче, просто для бизнесовых нужд хочется посчитать агрегаты и просто записать их на диск, чтобы потом их быстро читать и за счёт этого быстро отдавать ответ пользователю. Ладно, это лирика уже. Попробую наверное действительно какие то другие базы для этого, по идее мне реляционки не нужны здесь, просто хочется фигачить по ключу и потом читать json'ы. Постгря просто всегда под рукой, были иллюзии, что она будет приемлемо быстро это делать.

попробуйте поменять pglz на lz4: https://www.postgresql.fastware.com/blog/what-is-the-new-lz4-toast-compression-in-postgresql-14 если станет лучше - отпишитесь плз о результатах

Мы уже лет 10 используем упаковку + bytea У нас настройки: if ($len < 262144) { ($ztype, $args) = (COMPRESS_ZSTD, {quality => 9}); } elsif ($len < 524288) { ($ztype, $args) = (COMPRESS_ZSTD, {quality => 8}); } elsif ($len < 2097152) { ($ztype, $args) = (COMPRESS_ZSTD, {quality => 7}); } else { ($ztype, $args) = (COMPRESS_ZSTD, {quality => 6}); } ZSTD - это https://ru.wikipedia.org/wiki/Zstandard В свое время мы уперлись в то что jsonb у нас упирался в сетевой интерфейс

Прикольно, спасибо.

А что вы хотели? 200кб это 25 страниц, итого получается 25 миллионов iop. Немало. Постарайтесь нормализовать максимально изменяемые данные.