0

不動産リストの MySQL データベースを検索するシステムを作成中です。私はパフォーマンスを懸念しており、これを処理する方法について意見を求めていました。

最も頻繁に照会されるテーブルは「listings」テーブルで、86 列の 600,000 を超えるレコードが含まれます。この表も、リストの変更に伴い 30 分ごとに更新されます。

ほとんどすべての検索は、600k レコードの約 15k になる「アクティブ」のステータスを持つレコードに対して行われます。ただし、内部レポート用にすべての記録を保持する必要があります。また、各クエリはさまざまなパラメーター (#beds、#baths など) を検索する可能性が高いため、キャッシュが実行できない場合があります。

「アクティブ」とマークされたレコードの PK を含む 2 番目のテーブルを維持することを検討していました。リストの PK で結合されたテーブルのビューを作成します。ただし、特定の条件下では、ビューが非常に非効率になる可能性があることを私は知っています。

非アクティブなリストは頻繁に検索されず、メンテナンスが少なくて済むので、2 つのデータベースを維持することを考えました。

幸いなことに、まだ製品化されておらず、パフォーマンス テストを行う時間があります。もう1つ、これはPHPで書かれたフロントエンドを備えた専用のLinuxサーバーでホストされます. 提供された洞察は大歓迎です。

4

1 に答える 1

2

アーカイブ テーブルを作成することをお勧めします。要件に応じて、30 分ごとまたは 1 日 1 回実行するようにプロセスを設定できます。

アーカイブ テーブルには、元のテーブルと同じ列に加えて、EffDate と EndDate があり、レコードがアクティブな日付/日時が含まれます。

このようなテーブルがあれば、いつでも履歴を再作成できるようになります。これは役立つと確信しています。

これを作成するにはコードが必要です。基本的なロジックは、テーブル内の各レコードをアーカイブ内の最新バージョン (EndDate is nullおよびid = id) で検索することです。それで：

  1. 新しいレコードが存在しない場合は、現在の日付を として新しいレコードを作成しますEffDate。
  2. 存在し、すべての列が同じである場合は、何もしません。
  3. それ以外の場合EndDateは、アーカイブ レコードを更新して (1) を実行します。
  4. 新しいレコードがまったくないアーカイブ レコードはEndDate、現在の日付に設定されているはずです。

通常、このようなテーブルは 1 日に 1 回更新されます。

これを行うコードには、比較を行い、どのレコードが「新規」、「変更済み」、「削除済み」であるかを判断する大きな醜いクエリがあります (Excel が作成に役立ちます)。"Removed" および "Modified" レコードには、EndDates現在の日付が設定されています。EffDate「New」および「Modified」レコードは、現在の日付に設定された新しいレコードを取得します。

EndDateおよびの値はEffDate、更新が実際にどのように機能するかに応じて、記載されている値よりも 1 つ多いまたは少ない場合があります。たとえば、夜間の更新の場合は、EffDate明日に設定するか、リストが有効になる日付に設定することもできます。

于 2013-02-07T17:30:04.997 に答える