3

ここで私と一緒にふりをしましょう：

PHP/MySQL Web アプリケーション。1 つのサーバーと 1 つの MySQL DB を想定します。

私には1,000人の上司がいます。すべての上司には、その下に 10 人の従業員がいます。これらの 10 個のワーカー (1,000 倍、合計 10,000 個のワーカー) はそれぞれ、少なくとも 5 つのデータベース エントリ (work ordersこの目的のためにそれらを呼び出します) を WebApplication に毎日稼働させます。この作業指示テーブルでは、1 日あたり 50,000 エントリです。

サーバーの問題は別として、データベースの基本的なロジックを処理する主な方法が 2 つあります。

  1. 各ボスにはIDがあります。と呼ばれる 1 つのテーブルがあり、すべての作業指示書を上司に関連付けるworkordersという名前の列があります。BossIDこれにより、1 つのテーブルに 1 か月あたり約 100 万のエントリが残ります。

  2. 各ボスには、そのボスがサインアップしたときに作成される独自のテーブルwork_bossIDがありbossID = the boss' unique IDます。これにより、1,000 個のテーブルが残りますが、これらのテーブルははるかに管理しやすくなります。

  • 私が見落としている 3 番目のオプションはありますか?

  • より機能的な方法はどれですか?

  • テーブル内のエントリの数に対して大きすぎるのはどのくらいですか (列の数が少ないと仮定しましょう: 10 未満)? (これには次のものが含まれます: 次の場合は 2 番目のサーバーを取得する必要があります...)

  • データベース内のテーブルの数に対して大きすぎるのはどれくらいですか? (これには次のものが含まれます: 次の場合は 2 番目のサーバーを取得する必要があります...)

ある時点で、複数のサーバーとデータベースを相互にリンクすることについて話し合う必要があることはわかっていますが、ここでも、単一の MySQL DB を備えた単一のサーバーに焦点を当てましょう。

4

4 に答える 4

1

ボトルネックがどこにあるのか最初から常に明確であるとは限らないため、スケーリングは多くの場合実験のケースです。システムにかかる負荷の種類についてかなり良い考えを持っているように見えるので、最初に行うべきことの 1 つは、これをスプレッドシートに取り込んで、いくつかの仮説を立てられるようにすることです。これにより、多くの簡単な「what if」シナリオを実行し、最初のビルドでどこまでスケーリングする必要があるかについて合理的な上限を考え出すことができます。

大量のレコードを収集するには、いくつかの簡単なルールがあります。

  • 記述内容を表すには、最も効率的なデータ型を使用してください。より小さな整数型を使用して数バイトを削減したり、varchar を縮小したりすることについて心配する必要はありません。ここで重要なのは、数値には整数を使用し、日付には日付フィールドを使用するなどです。既に適切な型を持つデータに varchar を使用しないでください。
  • テーブルのインデックスを過剰に作成しないでください。厳密に必要なものだけを追加してください。インデックスの数が多いほど、テーブルが大きくなるにつれて挿入が遅くなります。
  • 不要になったデータをパージします。実際に削除してください。長期間保持する必要がある場合は、ダンプできる代替テーブルを作成します。たとえば、主要な注文テーブルを四半期または会計年度ごとにローテーションして、迅速に実行し続けることができる場合があります。レポートに必要な場合は、クエリをいつでも他のテーブルに対して実行するように調整できます。作業データ セットはできるだけ小さくしてください。
  • ベンチマーク、調整、調査、および実験により、MySQL サーバーを調整します。ここには魔法の弾丸はありません。一部の人々には機能する可能性がありますが、アプリケーションの速度が低下する可能性がある多くの変数があります。また、OS、ハードウェア、およびデータの構造とサイズにも大きく依存しています。InnoDB や MyISAM などのデータベース エンジンにより多くのメモリを割り当てることで、パフォーマンスを簡単に 2 倍または 4 倍にすることができます。
  • 大幅に役立つと思われる場合は、他の MySQL フォークを使用してみてください。通常の MySQL、特にPerconaよりも優れたパフォーマンスを提供するものがいくつかあります。
  • 大きなテーブルを頻繁に積極的にクエリする場合は、データの一部を非正規化して、実行する必要がある高価な結合の数を減らすことが理にかなっている場合があります。たとえば、メッセージ ボードでは、すべてのメッセージにユーザーの名前を含めることができますが、それはデータの無駄のように思えますが、メッセージの大きなリストを非常に高速に表示できます。

これらすべてを念頭に置いて、最善の方法は、スキーマを設計し、テーブルを構築してから、それらを実行することです。6 ～ 12 か月のデータで読み込みをシミュレートし、実際に読み込まれた後のパフォーマンスを確認します。EXPLAIN遅いクエリで使用すると、あらゆる種類の問題が見つかります。運用データベース サーバーよりも低速な開発システムでこれを行うと、展開時に驚くことがないようにすることをお勧めします。

スケーリングの黄金律は、実際に問題になっているものだけを最適化し、良いアイデアのように見えるという理由だけで調整することは避けることです。後で意図したこととは反対のことを行ったり、元に戻すのが非常に困難であることが証明されたりするソリューションを過度に設計することは非常に簡単です。

MySQL は、ロールアウトする前に慎重に実験を行い、ある程度の容量で機能することを証明すれば、数十億とは言わないまでも数百万の行を問題なく処理できます。

于 2012-08-18T04:20:22.593 に答える
-1

私のネットワークの1つでデータベースサイズの問題も発生したため、そのテーブルでクエリを実行するとサーバーの速度が低下しました..

私の意見では、データベースを日付に分割して、どのテーブルサイズが大きすぎるかを判断します.100万エントリとしましょう。次に、その量に達するまでにかかる時間を計算します。次に、その期間ごとにスクリプトを作成して、日付を含む新しいテーブルを作成し、現在のすべてのデータを移動するか、そのテーブルを元に戻して空にします。

古い素材をアーカイブに入れるようなものです。

最初のオプションを選択した場合は、そのテーブルを参照することで簡単にその日付にアクセスできます。

そのアイデアが役立つことを願っています

于 2012-08-18T03:13:40.660 に答える