JSONとメタデータテーブルのパフォーマンス

Question

私は、さまざまなセンサの読み値を含むシステムで作業しています。その中には、単一の読み込みよりも多くのキーを含むものがあります。これらのすべてがセンサーの読み取り値であるため、私は、これらの読み取り値を格納するテーブルを1つ用意し、主要な読み取り値のフィールドを探していますが、余分な情報はまだ格納する必要があります。

これらの余分な情報については、私は2つの解決策のいずれかを考えていますが、誰かが同様のことをしているかどうかを知りたいと思います。

オプション1

ストアセンサーの読み取りレコード自体の中JSONB列内の余分なデータ。私は、Postgres 9.4で追加されたJSONBの実装はパフォーマンスが優れていると読んだことがありますが、これは私のユースケースでどれくらいの速さであるか分かりません（実際にレコードの数はわかりません。まだ一生懸命ゲージに。）

オプション2

効果的に二次「メタデータ」テーブルのキーと値のストアを作成します。キーを表す1つの列と値を表す1つの列。これにより適切なインデックス作成を使用できるようになり、Postgresはより正確なクエリプランを作成できるようになります。

このうちどれが優れているか知っている人はいますか？私は読み込みよりも多くのレコードを挿入する傾向があります。読み込みを行うと、この決定に影響を与える可能性のある単一のレコードだけでなく、一度に多くのレコードになる可能性が高くなります。

オプション2は、実際には非構造化データではないという点で、より良い選択となるだろうと考えていましたが、それをインデックス化する機能は有益ですが、素晴らしいことだ。

Answer 1

私は両方を使用していますが、どのようにデータをクエリするかによって異なります。一般的に、PostgreSQLは結合に非常に適しています。

オプション2に行くのではなく、キー、値、センサーテーブルへの参照、およびタイムスタンプを使用してテーブルSensorReadingを完全に正規化します。タイムスタンプとsensor_idのインデックス。それが私のやり方です。うまくいきます。

私は本当に大きなテーブル（ブログ記事のタグなど）にオプション1を使用しました。その場合、JSONBフィールドまたは配列を定義することができます。それが悪いことを実行することは真実ではない、あなたはそれらのフィールドにGIN配列を定義することができます（btreeはかなり役に立たないでしょう）。したがって、両方のオプションをインデックスに登録できます。

私は完全に正規化を開始し、将来必要に応じて非正規化します。あなたがそれを提案する際には、オプション2は絶対にありません。