1

速度が重要な予測ダイヤラーを構築しています。番号をダイヤルするには、テーブルから顧客情報を取得し、pbx が処理する呼び出しファイルを作成します。

現在は市外局番ごとに表を作っており、市外局番ごとにダイヤルしていますが、複数の郵便番号にまたがる地域ごとにダイヤルするモデルに切り替えています。一部の市外局番は、複数の郵便番号に存在します。各テーブルには毎月新しい番号が追加され、数百万の番号の通話禁止リストと比較してスクラブされます。

私の質問は、このデータを最も効率的に整理するにはどうすればよいですか?

スクラブされたデータの何百万ものレコードについて話しているので、1 つの大きなテーブルは非生産的です。

私の現在の推論は、インポートとスクラブのために市外局番テーブルを維持し、スクラブされたレコードを地域テーブルにコピーすることです。このテーブルは、市外局番テーブルでその地域の郵便番号を検索することによって作成されます。

私は現在、auto_incremented INT プライマリ キー、一意の電話番号、および既に呼び出された番号または発信禁止リストにある番号を追跡するステータスによって、テーブルのインデックスを作成しています。通話ファイルを作成するときは、レコードをキューに登録済みとしてマークし、完了した通話の進行状況に応じてマークを付けます。そのため、通話ごとに検索と 2 回の更新が行われます。

検索では、市外局番テーブルで特定のステータスが検索されます。更新は、レコード ID に基づいて行われます。

質問の要点は次のとおりです。郵便番号で整理してステータスで検索するか、市外局番で整理してステータスと郵便番号で検索する方が速いでしょうか? それとも、市外局番テーブルから構築された地域を設定するたびに、新しいテーブルを作成する方がよいでしょうか?

これがばかげた質問のように思われる場合は、ご容赦ください。私はこれを構築しているときに SQL を独学してきました。データベースの設計とパフォーマンスのニュアンスは、私のスキルセットを少し超えています。

テーブルの合計サイズは 200 万行で、さらに増え続けています。

4

3 に答える 3

2

質問の要点は次のとおりです。郵便番号で整理してステータスで検索する方が速いですか、それとも市外局番で整理してステータスと郵便番号で検索する方が速いでしょうか? それとも、市外局番テーブルから構築された地域を設定するたびに、新しいテーブルを作成する方がよいでしょうか?

回答: 自分が何をしているのかを本当に理解していない限り、これらのいずれも実行しないでください。 代わりに、このエンティティのすべての行を保持する 1 つのテーブルを作成し、列の値を使用してさまざまな郵便番号と地域を区別します。おそらくテーブルを作成zipcodesし、territoryそれらを参照する外部キーを追加します。

属性値に基づいて個別のテーブルを作成することは一般的な解決策ではなく、さらに多くの問題が発生します (たとえば、郵便番号ごとにテーブルを編成する場合、すべての郵便番号で地域別に検索するにはどうすればよいでしょうか?)。

より一般的な解決策であり、データベースが得意とする解決策は、インデックスを使用することです。複数のインデックスを使用すると、データベースは、複数の異なる列で検索するためにテーブルへの高速アクセスを提供できます。

したがって、私が推奨する基本的な戦略は次のとおりです。

  1. 論理データ モデルを作成する
  2. 物理データ モデルを実装する
  3. パフォーマンスを分析する
    • explain <query>とても便利です
    • 十分でない場合は、インデックスを追加するか、既存のインデックスの使用を改善するか (クラスター化されたインデックスとカバーするインデックスを参照)、または選択的な非正規化を検討してください。
    • 選択と挿入のバランスは？インデックスは挿入を遅くする可能性があります

MySQL にとって 200 万行は大した量ではないことに注意することも重要です (もちろん、これは負荷によって異なります)。肝心なのは、最適化は非常にトリッキーなテーマであり、その答えは特定の状況に依存するということです。

于 2012-04-30T17:54:05.623 に答える
1

速度が必要な場合は、データを正規化する必要はありません。データが大きくなると速度性能が低下します。

この場合のパフォーマンスはハードディスクの速度に関係し、SSD はパフォーマンスを大幅に向上させる可能性がありますが、スペースの問題が発生し、より高価になります。

トレードオフは、回転ディスクを使用し、データを正規化しないことです。検索に使用するフィールドのインデックス作成。

他の戦略 (より巧妙) は、データセットで繰り返すことができるデータに整数コードを使用し、memcache からの郵便番号、都市などの実際の値を使用することができます (郵便番号、国名、都市はデータではないデータです)。ミュータブル) ですが、このアプローチは問題に新しい依存関係を追加します。

2 億 5000 万行のテーブルがあり、この情報は国と市、郵便番号、および ISP でタグ付けされています。メインデータを保存するためのssdがあり、地理データはmemcachedに保存されます。検索を行う必要がある場合、検索を実行してデータベース内のコードに変換するための論理レイヤーがあります。

于 2012-05-02T14:09:16.763 に答える
0

TaoNonnanes、のterritoryたびにテーブルを作成する必要はありませんarea code table。

area code tableテリトリーと市外局番テーブルのインデックスを作成し、少なくとも3NFまでデータベース全体を正規化するという外部キーを使用して、テリトリーテーブルを1つだけ作成しました。データベース全体の正規化が何であるかわかりません。

于 2012-04-28T04:59:42.460 に答える