6

私は postgres を初めて使用し、hstore 拡張機能を試しています。ガイダンスを探しています。販売するさまざまな製品の時系列データに関する基本的なレポートをサポートする必要があります。製品ごとに「タイムスタンプ、値」形式の大量のデータがあります。このデータは、各製品の csv ファイルで入手できます。

このデータをキー値形式で格納するために hstore を使用することを考えています。1 つの製品のすべての時系列データを 1 つの hstore オブジェクトに格納できると仮定します。このデータを特定の時間でクエリできるようにする必要があります。たとえば、特定の時間での製品の価値は何でしたか? また、製品の価格が 100 ドルを超えた時間を取得するなど、単純なクエリを実行する必要もあります。製品 ID 列と hstore 列を持つテーブルを作成する予定です。しかし、これを機能させる方法についてはあまり明確ではありません。

  1. hstore 列は、csv に存在する数千のタイムスタンプ、値レコードからロードする必要があります。新しい csv を取得するたびに、hstore を追加する必要があります。
  2. テーブルには、productId と対応する Timeseries データを格納する必要があります。hstore の使用が役立つかどうか教えてください。はいの場合、上記で説明したように csv からデータをロードするにはどうすればよいですか。また、hstore での挿入/更新のパフォーマンスに影響がある場合は、データが大きくなるにつれて、経験を共有してください。
4

1 に答える 1

5

特にPostgreSQLを初めて使用する場合は、単純で正規化されたスキーマから始める必要があると思います. 何かのようなもの:

CREATE TABLE product_data
(
    product TEXT,  -- I'm making an assumption about the types of your columns
    time TIMESTAMP,
    value DOUBLE PRECISION,

    PRIMARY KEY (product, time);
);

hstoreデータが十分に大きくなり、効率がより重要でシンプルになる場合は、同様のオプションを確実に念頭に置いてください。ただし、すべてのオプションには効率のトレードオフがあることに注意してください。

どのくらいのデータをサポートするか知っていますか? 製品の数、各製品の個別のタイムスタンプの数?

他に実行したいクエリは何ですか? 単一の製品の価格が 100 ドルを超える時間のクエリは(product, value)、製品に多数の個別のタイムスタンプがある場合、 のインデックスからメリットがあります。

その他のオプション

hstore任意のキーと値のペアのテーブル セットを行に格納する場合に最も便利です。ここでは、各製品の行と、その製品の個別のタイムスタンプを製品のテーブルのキーとして使用できます。欠点は、キーと値hstoreがテキストであるのに対し、キーはタイムスタンプであり、値は何らかの数値であることです。そのため、型チェックがある程度減少し、必要な型キャスト コストがある程度増加します。別の考えられる欠点は、hstoreインデックスをあまり効率的に使用できない可能性があります。上記のテーブルでは、範囲クエリに単純な btree インデックスを使用できます (たとえば、製品の 2 つの日付間の値を取り出したいとします)。しかし、hstore インデックスははるかに制限されています。hstore 列で gist または gin インデックスを使用して、特定のキーを特徴とするすべての行を見つけることができます。

もう 1 つのオプション (いくつかのデータベースで試し、実験的に使用しています) は配列です。基本的に、各製品には値の配列があり、各タイムスタンプは配列内のインデックスにマップされます。タイムスタンプが完全に規則的であれば、これは簡単です。たとえば、すべての製品に毎日、1 時間ごとに値がある場合、次のようなテーブルを使用できます。

CREATE TABLE product_data
(
    product TEXT,
    day DATE,
    values DOUBLE PRECISION[], -- An array from 0 to 23.

    PRIMARY KEY (product, day);
);

ビューとインデックスを構築して、このテーブルのクエリを適度に簡単にすることができます。(私はhttp://ejrh.wordpress.com/2011/03/20/vector-denormalisation-in-postgresql/でこの手法に関するブログ記事を書きました。)

しかし、私のアドバイスは、単純なテーブルから始めて、必要になることがわかっているときに効率を改善する方法を検討することです。

于 2012-11-14T00:06:44.243 に答える