Как оптимизировать обработку `bytea` в Postgres - PullRequest
Новая
       25

Как оптимизировать обработку `bytea` в Postgres

0 голосов
/ 23 мая 2019

Я работаю над индексатором биткойнов , который сбрасывает данные блокчейна в Postgres.

У меня был предыдущий дизайн схемы БД, в котором использовались SERIAL идентификаторы, но сейчас я играю со схемой БД, в которой первичные ключи / идентификаторы используют тип BYTEA. Это гораздо более тяжелый подход для БД, но он упрощает многие вещи более высокого уровня, поскольку идентификаторы в БД совпадают с глобально уникальными криптографическими идентификаторами, используемыми в блокчейне (вроде - я усекаю 32 байта до 16Б, так как думаю, что это достаточно уникально). Во всяком случае ...

Я ищу способы оптимизировать производительность. Особенно INSERT операций.

Во-первых: bytea даже лучший тип для байтового массива фиксированного размера?

Второе: есть ли лучший синтаксис для INSERT ввода нескольких значений, чем этот: 

INSERT INTO block_tx(block_hash_id, tx_hash_id)VALUES(\'\\x5a88c1899a84b8292d35c735f5683dcd\'::bytea,\'\\x5b8428f57026e69b1d51aaafdf8cf669\'::bytea),(\'\\x5a88c1899a84b8292d35c735f5683dcd\'::bytea,\'\\xacfcbab38dc315adb698653d3429f449\'::bytea),(\'\\x4357082b70a8371437b6806cdf6202ce\'::bytea,\'\\x65e1bd91f04ff6fd92df70b6ab2ee455\'::bytea),(\'\\x4357082b70a8371437b6806cdf6202ce\'::bytea,\'\\x2970c8f15ac24141cd070c2b3155f257\'::bytea),(\'\\x4357082b70a8371437b6806cdf6202ce\'::bytea,\'\\x7a71cbdf9f1d9e7c2a4ad6aff7b82345\'::bytea),

Как видите, этот суффикс ::bytea повторяется без необходимости. Я использую многозначные вставки, и я вкладываю много вставок в огромные транзакции. Известно, что он улучшал производительность и хорошо работал в моем предыдущем дизайне, где я не использовал BYTEA везде.

В-третьих: поскольку я использую BYTEA (иногда их несколько) в качестве ключей / индексов - похоже, индексы стали намного тяжелее обновлять при вставке. Что я могу с этим поделать?

Любые другие идеи приветствуются. Я провел много исследований по общей оптимизации INSERT огромного количества данных - это в основном аспект типа BYTEA, с которым я незнаком.

1 Ответ

0 голосов
/ 19 июня 2019

Сколько у вас строк?Насколько большой стол?Сколько у вас оперативной памяти?

Я думаю, таблица намного больше, чем умещается в оперативной памяти.Случайность PRIMARY KEY приводит к каждой INSERT посадке в «случайных» местах таблицы - часто не кешируется.По мере того, как таблица будет становиться все больше и больше, проблема будет становиться все хуже и хуже.

В конечном счете, кэш будет бесполезен, и каждый INSERT будет нуждаться в ударе диска.То есть ваша обработка замедлится до скорости диска.

Что делать?Получите больше оперативной памяти, чем размер таблицы.Получите более быстрые диски.

(Между тем, сокращение до 16 байт вместо 32, вероятно, не стоит усилий.)

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

...