1

mysqlデータベースの設計に関する意見や考えを聞きたいです。

基本的に、私は、フィールドにある約1000のシステムからさまざまなタイプのデータを受信するTomcatサーバーを持っています。これらのシステムはそれぞれ固有であり、固有のデータを報告します。

送信されるデータは、頻繁なデータと頻繁でないデータに分類できます。頻度の低いデータは1日に1回だけ送信され、あまり変更されません。基本的には、構成ベースのデータです。

頻繁なデータは、システムの電源がオンになっている間、2〜3分ごとに送信されます。また、システムの現在の状態を表します。

このデータは、システムごとにデータベース化する必要があり、phpページからいつでもアクセスできます。基本的に、フィールド内のすべてのシステムで、PHPページはそのクライアントシステム上のすべてのデータにアクセスして表示できる必要があります。つまり、データベースはシステムの状態を表示する必要があります。

情報自体はすべてテキストベースであり、たくさんあります。構成データ（あまり変更されない）はキーと値のペアであり、現在約100個あります。

私の設計のアイデアは、100以上の列と、構成データを保持するシステムごとに1つの行を持つことでした。しかし、主に将来的に列を追加する必要がある場合、将来性があまりないため、列がこれほど多くなるのではないかと心配しています。そうすると挿入速度も気になります。これは、1秒間に約100回アクセスされる2000行x 200列のテーブルに吹き飛ばされる可能性があるため、最初の設計でこれに対応する必要があります。

また、エンジンに基づいて頻繁に変更され、めったに変更されないデータに対応する設計哲学があるかどうかも疑問に思います。INSERT / UPDATE時間を低く抑えたいので、これは理にかなっています。phpからのSELECT時間についてはあまり気にしません。

また、データを分割する方法も知りたいです。つまり、頻繁に変更されるデータをいくつかの異なる方法で分類できる場合、データを表す一連のテーブルを用意して、それらを選択に結合する必要がありますか？すべてのシステムに共通のプロパティを表示する（つまり、特定の条件を持つすべてのシステムを表示する）ためにレポートを作成する必要があるため、これについて心配しています。

誰かが私を正しい方向に向けるために十分な情報をここに提供したことを願っています。この問題に関するどんな助けも素晴らしいでしょう。または、誰かが似たようなことをしてアドバイスを提供できるなら、私はとても感謝しています。ヒープに感謝します:)

〜ダン

4

1 に答える 1

4

コメントにいくつか質問を投稿しました。何をしようとしているのかをよく知らずに、急速に変化するデータについてアドバイスを与えることは困難です。

構成データには、100列のテーブルを使用しないでください。幅の広いテーブルは、本番環境での取り扱いが難しいことで有名です。代わりに、次の列を含む4列のテーブルを使用してください。

SYSTEM_ID  VARCHAR    System identifier
POSTTIME   DATETIME   The time the information was posted
NAME       VARCHAR    The name of the parameter
VALUE      VARCHAR    The value of the parameter

これらの列の最初の3つは、複合主キーです。

この設計には、構成パラメーターセットに追加（または減算）するときに拡大（または縮小）するという利点があります。また、履歴データの保存も可能です。つまり、新しいデータポイントは、更新ではなく挿入できるため、より高速です。毎日または毎週のジョブを実行して、保持する必要がなくなった履歴を削除できます。

（本当に履歴が必要ない場合は編集し、POSTTIME列を削除して、INSERT ON DUPLICATE KEY UPDATE投稿するときにMySQLの優れた拡張機能を使用してください。http：//dev.mysql.com/doc/refman/5.0/en/insert-onを参照してください。 -duplicate.html）

急速に変化するデータの形式（名前/値のペア）が構成データと類似している場合は、類似のスキーマを使用してデータを格納できます。

このようなものにMEMORYアクセスメソッドを使用して「現在のデータ」テーブルを作成することをお勧めします。データはすべてMySQLサーバーのRAMにあるため、MEMORYテーブルの読み取りと書き込みは非常に高速です。欠点は、MySQLがクラッシュして再起動すると、以前の内容が失われた空のテーブルが表示されることです。（MySQLサーバーがクラッシュすることはめったにありませんが、クラッシュするとMEMORYテーブルの内容が失われます。）

履歴を保存する必要がある場合は、不定期のジョブ（数分または数時間ごと）を実行して、MEMORYテーブルの内容をディスク上のテーブルにコピーできます。

（編集：高い読み取り速度を処理するバージョン1のデータベース設計を構築するのではなく、将来、高い読み取り速度を処理するためにmemcachedhttp://memcached.org/をWebアプリケーションシステムに追加することを検討するかもしれません。そうすれば、アプリ全体の設計のどの部分でスケーリングに問題があるかを確認できます。初期のバージョンでは過剰に設計するのではなく、過去に誰かがこれを行うように説得してくれたらよかったのにと思います。）

于 2012-08-20T01:46:52.240 に答える