可能な方法の1つは、JSONB配列です。その要素の任意の型を格納することができ、検索速度向上のためにインデックスを作成することができます
create table t as
select '["first item", 2, 3.14]'::jsonb as x
from generate_series(1,100000);
insert into t values('["second item", 3, 2.72]');
create index idx on t using gin(x);
explain analyse select * from t where x @> '3';
┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ QUERY PLAN │
╞═══════════════════════════════════════════════════════════════════════════════════════════════════════════════╡
│ Bitmap Heap Scan on t (cost=36.78..327.18 rows=100 width=47) (actual time=0.055..0.056 rows=1 loops=1) │
│ Recheck Cond: (x @> '3'::jsonb) │
│ Heap Blocks: exact=1 │
│ -> Bitmap Index Scan on idx (cost=0.00..36.75 rows=100 width=0) (actual time=0.028..0.028 rows=1 loops=1) │
│ Index Cond: (x @> '3'::jsonb) │
│ Planning time: 0.188 ms │
│ Execution time: 0.121 ms │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
explain analyse select * from t where x @> '[3, "second item"]';
┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ QUERY PLAN │
╞═══════════════════════════════════════════════════════════════════════════════════════════════════════════════╡
│ Bitmap Heap Scan on t (cost=68.78..359.18 rows=100 width=47) (actual time=0.087..0.089 rows=1 loops=1) │
│ Recheck Cond: (x @> '[3, "second item"]'::jsonb) │
│ Heap Blocks: exact=1 │
│ -> Bitmap Index Scan on idx (cost=0.00..68.75 rows=100 width=0) (actual time=0.048..0.048 rows=1 loops=1) │
│ Index Cond: (x @> '[3, "second item"]'::jsonb) │
│ Planning time: 0.248 ms │
│ Execution time: 0.187 ms │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
短所:値によって要素を削除する機能/演算子を使用して何の準備はありませんを
- 、インデックスのみで
- 要素の一意性をチェックするための準備ができた方法はありません。自分で作成する必要があります。
リンク:
JSON Types
jsonb Indexing
JSON Functions and Operators
最後のカウントでは、すべてのセットのセットは、600Kの要素を持っています。それを別の列に分割するのは実際には実現可能ではありませんか? –
600K行のテーブルで問題はありません。スペース効率(あなたの質問からはっきりしていなかった)を懸念しているなら、あなたのJSON提案は、ほぼ同じくらいのスペースを取る可能性が高いと思います。 – BoarGules
要素数については、600k * distinct *要素がありますか?そうではなく、テーブルスペースが懸念される場合(または冗長性を避けたい場合)、結合テーブルにIDのリストを格納するだけです。私は2番目の@BoarGulesの引数は、可能であれば、SQLデータをSQLで管理できるようにしてください(JSONはPITAですが、バイナリ形式でデータを格納することは決して問題ありません)。 – Arminius