我正在处理将区块链数据转储到Postgres的比特币索引器。
我有一个使用SERIAL IDS的DB架构设计，但是我现在正在使用DB模式，其中主键/IDS使用BYTEA类型。对于DB来说，这是更重的方法，但是它使许多更高级别的事情变得更加容易，因为DB中的ID与区块链上使用的全球独特的加密ID相同(一种 - 我将32 byther thccy to Shofe toss 16B截断，因为我是我的。认为它足够独特(。无论如何...
我正在寻找优化性能的方法。特别是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类型方面。
您有几行？桌子有多大？你有多少ram？
我猜想桌子比RAM中的桌子要大得多。PRIMARY KEY的随机性导致每个INSERT降落在桌上的"随机"位置 - 通常没有缓存。随着桌子越来越大，问题将变得越来越糟。
最终，缓存将没有用，每个INSERT都需要磁盘命中率。也就是说，您的处理速度会放慢速度。
该怎么办？获得比桌子尺寸更多的RAM。获取更快的磁盘。
(与此同时，缩小到16个字节而不是32个字节可能不值得努力。(
您可以通过收集大量行，对它们进行排序，然后将它们插入大批批量，从而获得轻微的改进。这为您提供了使用缓存的更好机会。