私はビジネスプランを書いており、私のWebサイトが500.000のユニークビジターから到達するときのコストをシミュレーションする必要があります。
各ページは50クエリ+-
この計算を実行すると、2番目に3,000クエリが必要になります...どの種類のサーバーで処理できますか?
問題は、実際には私のサイトは1日あたり2,000回の訪問を行っており、+/150/200クエリ/秒です...この時点から、50,000クエリ/秒と予想されます。
クラスタまたはレプリケーションで必要なサーバーは何台ありますか?
私はかつて、1日に数百万のページヒットがあったWebサイトを持つeコマース会社で働いていました。 2つのシングルコアCPUと2GBのRAMを備えた単一のDell PE 1750があり、データベースのサイズはおよそ。 4ギガバイト。ピーク時には、このサーバーは1秒あたり最大5万件以上のクエリを処理しました。
つまり、データベースは適切に構造化されており、すべてのクエリが微調整され(低速のクエリログを分析してクエリとインデックスを修正するセッションが毎週行われていました)、サーバーのセットアップも微調整されました。キャッシングは間違いなく良い考えですが、MySQLはとにかくパフォーマンスを分析し、メモリの使用方法(クエリキャッシュと他のオプション)を微調整するだけです。
その経験から、最も大きな影響は、インデックスの欠落、間違ったインデックス、不適切なデータベース設計(主キーとしての長い文字列フィールドなどのナンセンス)が原因であることがわかります。
それはすべて、クエリの複雑さ、サーバーのメモリ容量、ディスクの速度に依存します。
クエリが非常に単純な場合、または非常によく調整されている場合は、単一の大規模なデータベースサーバーで処理できます。ただし、クエリが非常に複雑な場合(または単純だが調整が不十分な場合)は、複数のサーバーが必要になります。
これは、実行中の特定のクエリ、データベーススキーム、およびそのサイズについて何も知らなければ、実際には推定できません。
インデックス付きの列の単純なSELECTはquiteインデックスのないものに基づいたいくつかのJOINとは異なる獣です。 。もちろん、関係するテーブルに1Kレコードまたは1Mレコードが含まれている場合、状況は大きく変化します。
また:
イグナシオが述べたように、キャッシュを調べたいと思うかもしれません。 cmsで、あるいはスタックの前でさえ。すべての(すべての!)ページに対する50以上のクエリは、本当に大量です。
大規模な「ホット」データセットの場合、「ビッグデータ」スキームに変換することは、時間をかけて投資する価値があると思われます。たとえば、膨大な量のデータを取得する必要があるが、書き直さずに新しいデータを追加するだけの場合は、Apache Hiveを見てください。ブラウジングしてください。通常、これらは既存のコードに簡単にインターフェースできるフレーバーであり、キャッシュスペース不足による胸焼けも防ぎます。
1秒あたりのクエリに影響する可能性のあるものが多すぎます。自分でテストしない限り、私のデータを信頼しないでください。私は速度テストの結果をここに投稿して、誰かが現在の(2018-09)mysqlデータベースとマシンでqpsを推定できるようにします。私のテストではデータサイズはサーバーメモリよりも小さい(IOが大幅に削減され、パフォーマンスが大幅に向上しています)。
私は1つのCPU 3.75GBメモリ、100GB ssd、gcpクラウドmysqlサーバーインスタンスを使用して、以下を取得します。
コメントから判断すると、最大の要因はデータセットのサイズ、または少なくとも「ホット」データセットのサイズです。 16コアサーバーで3,000qpsまたは8,000qpsであっても、サーバーがクエリを実行するためにディスクにアクセスする必要がほとんどない限り、まったく問題ありません。アクティブデータセットがInnoDBがそれをキャッシュするために使用しているメモリの量を超えると、パフォーマンスは急速に低下します。