TLDR:整数の配列をPostgresテーブルに保存したい場合、配列列(integer[]
)を使用することとJSON列を使用することの長所または短所はありますか(たとえば、一方が他方よりもパフォーマンスが優れていますか)?
裏話:
私はPostgreSQLデータベースとそれを管理するためのNode / Knexを使用しています。KnexにはPostgreSQLのinteger[]
列タイプを直接定義する方法がないため、誰かがKnexのバグを報告してそれを要求しました...しかし、Knex開発者の1人がチケットを閉じ、本質的にPostgreSQL配列の列タイプをサポートする必要はないと述べました代わりに誰でもJSON列タイプを使用できる場合。
私の質問は、JSON列型を使用して整数の単純な配列を保持することにはどのような欠点がありますか?真の配列列を使用することでパフォーマンスが向上するなどの利点はありますか、それとも配列をJSON列内に格納するだけで同じようにうまくいきますか?
編集:明確にするために、私が答えで探しているのは次のいずれかです:
A)PostgreSQLのJSON列とinteger []列がどのように機能するかについての説明。一方が他方よりも優れているか、または2つが(少なくとも大まかに)等しいかを含みます。
B)説明はありませんが、少なくとも、一方の列タイプまたは他方の列タイプのパフォーマンスが優れている(または2つが等しい)ことを示すいくつかのベンチマークへの参照
Anint[]
は、必要なストレージの点ではるかに効率的です。500要素の配列のサイズを返す次のクエリについて考えてみます。
select pg_column_size(array_agg(i)) as array_size,
pg_column_size(jsonb_agg(i)) as jsonb_size,
pg_column_size(json_agg(i)) as json_size
from generate_series(1,500) i;
戻り値:
array_size | jsonb_size | json_size
-----------+------------+----------
2024 | 6008 | 2396
(JSON値がJSONBよりもはるかに小さいことに非常に驚いていますが、それは別のトピックです)
あなたはいつものように配列を使用する場合、単一の値には、クエリのパフォーマンスの面で本当に重要ものではありませんが、あればやる配列に調べる必要がありますが、特定の値(複数可)を検索し、それは、ネイティブ配列と多くの、より効率的になります。
JSON配列よりも、ネイティブ配列で使用できる関数と演算子がたくさんあります。JSON配列で単一の値を簡単に検索できますが、複数の値を検索するには回避策が必要です。
次のクエリは、次のことを示しています。
with array_test (id, int_array, json_array) as (
values
(1, array[1,2,3], '[1,2,3]'::jsonb)
)
select id,
int_array @> array[1] as array_single,
json_array @> '1' json_single,
int_array @> array[1,2] as array_all,
json_array ?& array['1','2'] as json_all,
int_array && array[1,2] as array_any,
json_array ?| array['1','2'] as json_any
from array_test;
配列に特定の値が1つ含まれている場合は、配列を簡単にクエリできます。これはJSON配列でも機能します。それらは式array_single
とjson_single
です。ネイティブ配列を使用すると、1 = any(int_array)
代わりに使用することもできます。
ただし、配列にリストのすべての値が含まれているかどうか、またはリストの値がJSON配列で機能しないかどうかを確認してください。
上記のテストクエリは次を返します。
id | array_single | json_single | array_all | json_all | array_any | json_any
---+--------------+-------------+-----------+----------+-----------+---------
1 | true | true | true | false | true | false
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加