1

状況：当社では、データフィードをデータベースに読み込むプロジェクトに取り組んでいます。これらのデータフィードには、多数のフィールドを含めることができます。これらのフィールドを特定の列と照合します。

現在、約120種類のフィールドがあります。それらはすべて列が必要です。すべての列をフィルタリングして並べ替えることができる必要があります。

問題は、これに最適なデータベース設計がわからないことです。私は仕事にMySQLを使用していますが、提案を受け付けています。現時点では、120列すべてのテーブルを作成することを計画しています。これが、最も自然な方法だからです。

オプション：他のオプションは、キーと値を格納するメタテーブルです。または、ドキュメントベースのデータベースを使用して、可変スキーマにアクセスし、必要に応じてスケーリングできるようにします。

質問： このすべてのデータを保存するための最良の方法は何ですか？行数は最大10万行になる可能性があり、非常に高速に選択、並べ替え、フィルタリングできるストレージが必要です。

更新： 使用法に関する詳細情報。XMLフィードは、このテーブルからライブで生成されます。1時間あたり100〜500のリクエストについて話していますが、これは増え続けるでしょう。フィールドは定期的に変更されることはありませんが、6か月に1回変更される可能性があります。また、データフィードも毎日更新されます。したがって、アイテムが更新されているかどうかを確認し、古いアイテムを削除して新しいアイテムを追加します。

4

2 に答える 2

1

10万行の120列は十分な情報ではなく、実際にはメトリックの1つであるサイズのみを提供します。もう1つはトランザクションです。ここで話しているのは1秒あたり何回のトランザクションですか？

マネージャーが週に1回レポートを実行する夜間の更新ですか、それとも1時間に100万ページのリクエストがありますか？

私は通常、10mのレコードテーブル、または1秒あたり数百のクエリに到達するまで、「賢い」ソリューションを検討し始める必要はありません。

ああ、キーと値のペアテーブルは使用しないでください。それらはリレーショナルデータベースでは優れていないので、適切な型付きフィールドに固執します。

私は個人的に、従来のフィールドごとに1列のアプローチに固執することをお勧めします。テストで実際に正しくないことが示された場合にのみ、これから逸脱します。

取得に関しては、INSERTS / UPDATESが毎日のみ発生する場合は、サーバー側で慎重にインデックスを作成し、XMLが生成される場所で適切なキャッシュを行うことで、サーバーのヒットを大幅に減らすことができると思います。たとえば、「データフィードを毎日更新する」と言った場合、毎回データベースにクエリを実行する必要はありません。ただし、1時間あたり1000は、1分あたりわずか17です。それはおそらく何にも切り捨てられません。

于 2012-04-05T08:57:29.643 に答える
0

私は現在、同様のプロジェクトに取り組んでおり、ネットからダンプをダウンロードしてデータベースにロードし、変更をメインテーブルにマージし、ディクショナリテーブルを適切に調整しています。

まず、使用するデータがわかっています。したがって、事前に分析して、最適なテーブル/列のレイアウトを選択する必要があります。120列すべてにテキストデータが含まれている場合、1行に数Kバイトのディスク容量が必要になります。このような状況では、すべてのクエリを高度に選択して、IOを最小化するためにインデックスが使用されるようにする必要があります。このような設計では、フルスキャンにかなりの時間がかかる場合があります。500 / hのリクエストの大きさについては何も言われていませんが、各リクエストは1つの行、小さな行の束、または大きな部分（テーブル全体まで）を抽出しますか？

次に、データを見ると、値のセットが制限されているいくつかの列の概要を示している可能性があります。私はそのような列に対して次の変換を行うことを好みます：

  • ディクショナリテーブルを設定し、その整数PKを作成します。
  • マスターテーブルの列の実際の値をディクショナリのPKに置き換えます。

変換はCで記述されたトリガーによって行われるため、アップロードのペナルティが発生しますが、いくつかの利点があります。

  • データベースとマスターテーブルの合計サイズが減少しました。
  • 頻繁にアクセスされるデータブロックをキャッシュするためのデータベースとOSのより良いオプション。
  • クエリのパフォーマンスが向上します。

第三に、実行する抽出に従ってデータを分割してみてください。通常、テーブル内のフィールドの30〜40％のみがすべてのクエリで使用され、残りの60〜70％はすべてのクエリに均等に分散され、部分的に使用されていることがよくあります。この場合、それに応じてメインテーブルを分割することをお勧めします。常に使用されるフィールドを単一の「マスター」テーブルに抽出し、残りのフィールド用に別のテーブルを作成します。実際、複数の「別のデータ」を使用して、データを個別のテーブルに論理的にグループ化することができます。

私の実践では、名前の詳細、住所の詳細、ステータスの詳細、銀行の詳細、請求の詳細、財務の詳細、および一連のカスタムコメントなどの顧客の詳細情報を含むテーブルがあります。このようなテーブルに対するすべてのクエリは、レポートの大部分で使用されていたため、高価なものでした（レポートは通常、フルスキャンを実行します）。このテーブルを小さなテーブルのセットに分割し、その上にルールを含むビューを構築して（外部アプリケーションを満足させるため）、パフォーマンスを快適に向上させることができました（申し訳ありませんが、数字はもうありません）。

要約すると、作業するデータと、それに応じてデータベースにアクセスし、分析および設計するために使用されるクエリを知っています。

于 2012-04-05T11:45:22.100 に答える