3

データベースを正しく設計したい。誰かが私を助けてくれるかもしれません。

テーブルに約 100 個のキー/値を 3 秒ごとに書き込むデバイスがあります。誰かが次のように保存することを提案しました：

^ タイムスタンプ ^ キー 1 ^ キー 2 ^ [...] ^ キー 150 ^

| | 12/06/12 | null | null | 2243466 | [...] | ヌル ^

しかし、それは完全に間違っており、動的ではないと思います。多くの null 値を持つ可能性があるためです。だから私は最善を尽くそうとし、学校で学んだ方法でデザインしました: http://ondras.zarovi.cz/sql/demo/?keyword=tempidi

これは、すべての値に対してタイムスタンプを書き込むという問題です。これは、100 値以内では常に同じであり、大量のデータが生成されることを意味します。

データベースのサイズを小さくする方法を教えてください。私の ERM は基本的に正しいですか?

4

2 に答える 2

1

データベースのサイズについてはあまり心配しません。あなたのより大きな問題は、メンテナンスと柔軟性です。

これが私がすることです。まず、このテーブルを定義して、デバイスが書き込める可能性のあるキーを入力します。

tblDataKey
(
    ID int primary key (auto-increment - not sure how mysql does this)
    Name varchar(32)
)

次に、「データ イベント」テーブルを定義します。

tblEvent
(
    ID int primary key (auto-inc)
    TimeStamp
    ...anything else you need - device ID's? ...
)

次に、イベントをキーとその値と照合します。

tblEventData
{
    EventID INT FK-to-tblEvent
    KeyID INT FK-to-tblDataKey
    DataValue varchar(???)
)

データが入ってくる毎秒ごとに、tblEvent に 1 つのエントリを作成し、必要に応じてキー値を使用して tblEventData に複数のエントリを作成します。すべてのイベントにすべてのキーが必要なわけではなく、将来的にキーの数を増やすことができます。

これは、スペースが無駄にならず、特定のデータ キーと値を使用して evnet のクエリを簡単に実行できるという点で非常に優れています。この種の構造がうまくいかないのは、イベントとデータ項目の「クロス集計のような」テーブルを作成する必要がある場合です。それが問題かどうかを判断する必要があります。

于 2012-12-06T18:51:28.980 に答える
0

MySQL にキーと値のストアを実装する必要がある場合、これ以上複雑にする意味はありません。

create table key_value_store (
  run_time datetime not null,
  key_name varchar(15) not null,
  key_value varchar(15) not null,
  primary key (run_time, key_name)
);

キーと値の両方の平均長が 10 バイトの場合、1 か月あたり約 8600 万行と 2.5 GB であり、結合は必要ありません。すべての値 (列 key_value) が整数または浮動小数点数の場合、データ型を変更してスペースをもう少し減らすことができます。

SQL でキー値ストアを実装する際の主な問題の 1 つは、すべての値が同じデータ型でない限り、すべての値に対して varchar(n) などを使用する必要があることです。タイプ セーフと宣言的制約が失われます。(key3 の値が 1 から 15 の間であり、key7 の値が 0 から 3 の間であることを確認することはできません。)

これは実現可能ですか？

この種の構造 (「EAV」--Google として知られている) は、よく知られたテーブル設計のアンチパターンです。問題の一部は、基本的に列を行として格納していることです。(列名を key_value_store.key_name に格納しています。)通常のテーブルの形式でデータを書き出す必要がある場合は、3 つのことがわかります。

  1. 適切な形式で出力するクエリを作成するのは困難です。
  2. 実行するには永遠に時間がかかります。何百もの列を作成する必要がある場合、実行が完了しない可能性があります。
  3. もっと高速なハードウェアがあればいいのにと思うでしょう。はるかに高速なハードウェア。

私が探しているもの

  • キーを論理テーブルにグループ化する機会。これは最初のデザインに関係しており、あなたには当てはまらないかもしれません。あなたのアプリケーションは基本的にログ ファイルを保存しているように思えますが、実行のたびにどのキーが値を持つかわかりません。
  • 行数を減らす機会。「書く頻度を減らすことはできますか？」と尋ねます。そのため、3 秒ごとではなく、5 秒または 6 秒ごとにデータベースに書き込むことを検討します。これは、書き込む行が少ないことを意味すると仮定します。(本当の目標は、書き込みを減らすことではなく、行を減らすことです。)
  • 適切なプラットフォーム。これには、PostgreSQL 9.2 の方が適している可能性があります。バージョン 9.2 にはインデックスのみのスキャンがあり、キー値ストアを実装する hstore モジュールがあります。

決める前にテストする

私があなたの立場なら、MySQL と PostgreSQL の両方でこのテーブルを構築します。それぞれに約 100 万行のランダムなデータをロードします。次に、それぞれについていくつかのクエリとレポートを試します。(レポートは重要です。) パフォーマンスを測定します。負荷を 1000 万行に増やし、サーバーと dbms を再調整し、同じクエリとレポートを再度実行します。再度測定します。

1 億行で繰り返します。自信がついたらやめましょう。これには数日かかると予想してください。

于 2012-12-06T19:20:52.023 に答える