☰

およそ 1,000 ドルの MySQL サーバーからどの程度の用途を引き出せると予想されますか?

tag-icon • tag-icon mysql scaling database-performance
およそ 1,000 ドルの MySQL サーバーからどの程度の用途を引き出せると予想されますか?

これはひどい、一般論的な質問で、良い答えがないことは承知しています。あらかじめお詫びしますが、誰か非常に大まかな見積もりを出していただけないでしょうか。

約 1,000 ドル相当の最新ハードウェア上で専用の MySQL サーバーを実行しているとします。

平均的なユーザーが 1 分間に 20 件の読み取り要求と 5 件の書き込み要求を行うとします。これらはすべて単純なクエリで、結合はありません。ほとんどは、約 10,000,000 行のインデックス付きテーブルから「UUID でこの行を選択する」というものです。

このようなサーバーを「プッシュ」する前に、同時ユーザーを大まかに何人まで処理できると予想しますか。

答え1

ご指摘のとおり、これは非常に大まかな見積もりです。

大きな問題は、その 1000 ドルを何に使うかです。平均的なハード ディスクで、メモリを少し増やし、プロセッサ パワーを少なくすることを前提とすると、それらのパラメータを使用して、適切にコーディングされたアプリケーション (適切とは、主に言語が提供する抽象化ライブラリを使用する) は、約 500 人の同時ユーザーを処理できるはずです。行セットのサイズを除けば、もっと多くのユーザーを処理できると予想していました (RAM に直接収まる行が多いほど、即時書き込みの場合でもディスクへの書き込みが少なくなるため)。

このシナリオでは、行に含まれるデータのタイプと、使用できる RAM の量が、間違いなく最大の要因になります。書き込み回数を減らし、インデックス テーブルのサイズを小さくすることができれば、1,000 人のユーザーを同時に処理できると思います。

発生する 2 つの問題:

  1. RAM にキャッシュできるデータの量、つまり基本的な OS とデータベース サーバーの操作を実行するために最低限必要な量を超える RAM の量によって、何ができるかが決まります。RAM を増やし、OS の要件を減らし、クエリと書き込みのために RAM に保持する必要がある有用なデータの量を減らすことで、許容できるパフォーマンスと大量のスラッシングの違いが生じます。

  2. ここでは、アプリの設計が極めて重要です。1 回の書き込みが 500 ～ 1,000 人のユーザーに分散されると、非常に大きな影響が生じます。同様に、呼び出しが単純で効率的でない場合は、すぐに大惨事を引き起こすことになります。私は、動作の仕組みについて多少の知識を持ちながら、実際に動作しているいくつかの MySQL アプリを基に見積もりを立てました。アプリに根本的な問題がある場合は、40 人のユーザーにも到達できない可能性があります。効率的にコーディングし、ハードウェアの制限を考慮すれば、2,000 を超える規模に簡単に拡張できる可能性があります。

答え2

答えはわかります。私はちょうどその乗り物を降りたばかりですが、また乗ります。

650～800 ドルで、1 TB SATA2 ドライブを搭載した、8 GB RAM の中速クアッドコア AMD を購入できます。170 ドルで、2 台目の比較的高速な 1 TB ドライブを購入できます。これは、ほとんどの電気店、オフィス ストア、ベスト バイ タイプの場所で購入できる既製のハードウェアであることに注意してください。他の場所では、より優れた製品が手に入りますが、価格に見合った価値はあります。もう少しお金を出せば、より高速なクアッドコアを入手できます。

さて、アプリに関しては、OS として Linux/BSD/Unix を実行していると仮定し、MS 対 Unix の議論は避けます。私が見つけたのは次のとおりです。

弊社のアプリケーションがどんなに弱くても、200 人以上のアクティブ ユーザー/セッションを瞬きなしで指定することは問題ありません。実際、弊社がしばらく運用してきたクアッド コア サーバーでは、アプリケーションをドロップ/クラッシュ/停止させることはできませんでした... しかし、シングル コア 200 MHz の時代にいくつかの教訓を学びました。

たとえば、当社の姉妹会社は、マシンあたり 1,300 人以上のユーザーと、1 時間あたり平均数百の同時セッションを備えた、MySQL ベースの通信監視システムを多数販売しています。ログ記録とレポートはリアルタイムで行われ (バッファリングは発生します)、3Ghz デュアルコア マシンで [驚いたことに] 低速 PATA ドライブで実行されています... 実際、133Mhz P-ata ドライブです。これまでで最も長いユーザー インターフェイスの遅延は約 2 秒でした。10 年前に MSSQL を廃止して MySQL に乗り換えたところ、すぐに成果が出ました。

覚えておいてください、これらのマシンは Web アプリケーションとデータベースを実行しています... 計算してみてください。うまくいきます。また、私はいくつかの Oracle/MS/xxxx アプリケーションをこれらに置き換えましたが、決して力不足に陥ることはありませんでした。また、DBA の観点から他の人が言ったことを詳しく説明しましょう... 現場から得た 6 つのヒントを紹介します。

  1. 特にロックペナルティがコーダーにとって馴染みのない概念である場合、書き込みによってパフォーマンスが低下します。
  2. すべてを 1 つの巨大なテーブルで実行すると、失敗します。
  3. 過度な正規化は好ましくありません。コーダーが完全な第 3 正規形を採用すると、アプリの動作が悪くなります。非正規化されたデータはより多くのスペースを必要としますが、単純なクエリで優れた成果を達成できます。
  4. 1 つの大きなテーブルでは、頻繁な書き込みによって処理が追いつかなくなります。1 を参照してください。
  5. データ表示用に 1 つ (または複数) のテーブルを使用し、書き込み用に別のテーブル (システムの負荷が許せば読み取りテーブルと同期可能) を使用するようにアプリを作成すると、さまざまな問題を回避することができます。書き込みをバッファリングするために少数のテーブルを使用し、誰も踏み込まれないため、驚くほど多くのトランザクションに対処できます。
  6. インデックスを使用します。とにかく、クエリのどの部分がキーとして使用されるかがわかっている場合。
  7. メモリに基づいてデータベースのインストールを調整します。MySQL のドキュメントをオンラインで参照してください。実際のところ、アクティブなセッションが 1,000 未満であれば、接続数を増やすだけで済む場合が多いです。 http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html

ほとんどの WordPress などのプラグインを見れば、愚かな SQL が実際に動作しているのがわかります。そのほとんどは SQL を理解していない人々によって書かれており、ほんの一握りのユーザーですぐにサーバーがダウンしてしまいます。

答え3

884 ドルのサーバー、8 GB RAM、デュアル クアッドコア Xeon、300 GB 7200 rpm SATA ドライブ、アイドル 40%、iowait 5%

Uptime: 780727  Threads: 276  Questions: 1884267879  Slow queries: 3964303  Opens: 60474
Flush tables: 1  Open tables: 440  Queries per second avg: 2413.478

220mb/秒の速度で

関連情報