web-dev-qa-db-ja.com

hstoreのユースケース

hstoreデータ型を使用する機会はこれが初めて（私は思う）ですが、私が考えていることが実際に良いアイデアであるかどうか、より経験豊富な人々から聞いてみたいと思います。

さて、このWebアプリがあり、給与データをXMLファイルの形式でインポートします。これはおおよそ次の簡略化されたバージョンのように見えます。

<Company>
    <Employee>
        <LastName>Smith</LastName>
        <FirstName>John</LastName>
        <HourlyWage>9999.99</HourlyWage>
        <!-- several other hundreds of tags -->
    </Employee>
    <Employee>
        <!-- ... -->
    </Employee> 
</Company>

各従業員は非常に詳細な情報を持っています。私が「他の数百のタグ」と言うのは、通常800から1400以上の範囲であるためです。これは毎月です。コアタグのセットとは別に、各従業員はそれらの異なる組み合わせを持つことができるため、上記で示した非常に変動しますが非常に現実的な数値です。

現在、このデータの一部は長く、遅く、非常に複雑なプロセスでインポートされています。頻度が高くなるにつれて、「常にインポートしていたとしたら、まあまあですその特定のタグ！ "。

インポートプロセスは高度に構成可能ですが、少数のデータセットに対して実行するのは遅く、非現実的で、実に苦痛です。架空の新しいタグをインポートするために必要なカスタマイズを追加するのはこれからはるかに簡単ですが、履歴データを常にインポートするかのように構築するには、乱雑でエラーが発生しやすい。

追加のボーナスとして、タスクは常にそれらの2人の男にあり、私はそのうちの1人であり、私たちの生活を少しシンプルにしたいと思っています。

これが、夜間にそれらのXMLファイルをクラックして開き、毎月および各従業員について、従業員のすべてを含むhstore列を持つレコードを作成するクイックツールを作成することを考えている理由です。その月のタグ。

hstoreの初心者であるため、これは非常に良いユースケースのように見えます。特に次のことを考慮すると、次のようになります。

  • タグは従業員ごとに異なる可能性があるため、これは基本的にスキーマのないデータです。

  • タグごとに1行のEAVとしてタグを保存すると、200人の従業員の会社では月に約24万行になります（年間280万行に相当します）。心配することは何もありませんが、顧客は1人だけではありません。そして、そのうちの1人には7,000人を超える従業員がいます（これは年間1億件のレコードになります）。

  • このデータを読み取る必要があるのは、決して変更するだけです。さらに、とにかくそれほど頻繁に読まれることさえありません。

  • 与えられたタグが何を意味するのか、私は本当に気にしません。将来使用するために保存したいだけです。どちらが必要かは、ドメインの専門家の仕事です。繰り返しますが、スキーマレスです。

私が設計するテーブルは、次のようになります。

- id bigserial
- user_id
- file_timestamp (it's embedded on the name of the file)
- employee_id_1 varchar
- employee_id_2 varchar
- month date
- file_id (id of the XML file, it gets logged in a table before being imported)
- tags hstore

（employee_id 1および2のうち、前者はUS SSNのように見え、後者は給与計算アプリから割り当てられます）。

また、(user_id, employee_id_1, employee_id_2, month, file_id)に一意のインデックスを作成します。列の順序について100％確実ではありませんが、データを段階的に絞り込みたいほとんどのSELECTsに対応できると思います。

また、顧客ごとにテーブルを複製したくないし、ユーザーに表示する必要もありません。専用のスキーマを作成してそこに貼り付けます。これは、将来のある時点でパーティションを作成したい場合に備えて、管理が少し簡単になります。これは巨大なテーブルになりますが（行数ではなく、各行に必要なスペース）、独自のスキーマを維持することで、ほとんどのバックアップから簡単に除外できるようになります。さらに、とにかく元のXMLファイルを保持しているので、問題が発生した場合でも再構築するのは難しくありません。

このような設計では、アドホックな1回限りのクエリを大量に使用して履歴データを生成するのは子供の遊びのように見えます。

しかし、私は専門家ではないので、次のことを考えていました。

  1. これは実際にはhstoreの良いユースケースです
  2. 私のデザインには明らかな欠陥があります
  3. hstoreがシーンに入ったときに、自分が隅に隠れないようにするために注意しなければならないことがあります
  4. タグはかなりの数ですが、行ごとにそれほど多くないので、hstoreにインデックスを作成する価値があります。キー？
postgresqlpostgresql-9.4hstore
4
s.m.

あなたが働いている範囲で。 JSONBが理想的だと思います。深くネストされた構造体と配列キーを持つ構造体を処理します。また、標準化されており、sql2016の仕様に含まれています。

さらに、 ここで回答しました のように、 [〜＃〜] zson [〜＃〜] と呼ばれるスペース消費に役立つ拡張機能があります。

[〜＃〜] zson [〜＃〜] は、透過的なJSONB圧縮用のPostgreSQL拡張機能です。圧縮は、特定のJSONBドキュメント（キーだけでなく、値、配列要素など）で最も頻繁に使用される文字列の共有ディクショナリに基づいています。

場合によっては、ZSONはディスク容量の半分を節約し、TPSを約10％増やすことができます。メモリも節約されます。 docs /benchmark.mdを参照してください。ただし、すべてはデータとワークロードに依存します。ベンチマークを信じないでください。データ、構成、ハードウェア、ワークロード、およびPostgreSQLバージョンのすべてを再確認してください。

ZSONを調べてみてください。

1
Evan Carroll