回答:
物理データベースのサイズは重要ではありません。レコードの数は関係ありません。
私の経験では、実行する最大の問題はサイズではなく、一度に処理できるクエリの数です。ほとんどの場合、読み取りクエリをスレーブに対して実行し、書き込みクエリをマスターに対して実行できるように、マスター/スレーブ構成に移動する必要があります。ただし、この準備が整っていない場合は、実行中のクエリのインデックスをいつでも調整して、応答時間を短縮できます。また、Linuxのネットワークスタックとカーネルに対して行うことができる微調整もたくさんあります。
私は10 GBまで取得しましたが、接続数は中程度で、リクエストは適切に処理されました。
最初にインデックスに焦点を当て、次にサーバー管理者にOSを見てもらいます。それでも役に立たない場合は、マスター/スレーブ構成を実装するときかもしれません。
一般に、これは非常に微妙な問題であり、些細なことではありません。mysqlperformanceblog.comおよびHigh Performance MySQLを読むことをお勧めします。これには一般的な答えはないと思います。
私は、ほぼ1TBのデータを持つMySQLデータベースを持つプロジェクトに取り組んでいます。最も重要なスケーラビリティ要素はRAMです。テーブルのインデックスがメモリに収まり、クエリが高度に最適化されている場合、平均的なマシンで妥当な量のリクエストを処理できます。
テーブルの外観に応じて、レコード数は重要です。varcharフィールドが多数あるか、intまたはlongが数個しかないのは違いです。
データベースの物理的なサイズも重要です。たとえば、バックアップについて考えます。エンジンによっては、物理的なdbファイルは拡大しますが、たとえばinnodbの場合は縮小しません。したがって、多くの行を削除しても、物理ファイルを縮小するのには役立ちません。
この問題には多くの点があり、多くの場合、悪魔は詳細にあります。
データベースのサイズは重要です。100万を超えるレコードを含む複数のテーブルがある場合、実際にパフォーマンスが低下し始めます。もちろんレコード数はパフォーマンスに影響します。MySQLは大きなテーブルでは遅くなる可能性があります。100万件のレコードにヒットした場合、インデックスが正しく設定されていないと、パフォーマンスの問題が発生します（たとえば、結合の「WHEREステートメント」または「ON条件」のフィールドにインデックスがない場合）。1000万件のレコードをヒットすると、すべてのインデックスが正しくても、パフォーマンスの問題が発生し始めます。ハードウェアのアップグレード-メモリとプロセッサパワー、特にメモリを追加すると、パフォーマンスが再び少なくともある程度向上するため、最も深刻な問題を減らすことができます。例えばBasecampデータベースサーバーでは、37の信号が32 GB RAMから128GB RAMになりました。
サーバー管理者にOSを見てもらうよりも、まずインデックスに重点を置きます。それでも解決しない場合は、マスター/スレーブ構成の時間になるかもしれません。
それは本当だ。通常機能するもう1つのことは、繰り返し使用されるデータの量を減らすことです。「古いデータ」と「新しいデータ」があり、クエリの99％が新しいデータで機能する場合は、古いデータをすべて別のテーブルに移動します-見ないでください;）
-> パーティショニングをご覧ください。
私は現在、AmazonのクラウドインフラストラクチャでMySQLデータベースを管理しており、160 GBに成長しています。クエリのパフォーマンスは良好です。悪夢となっているのは、バックアップ、復元、スレーブの追加、またはデータセット全体、あるいは大きなテーブルでのDDLを処理するその他のことです。ダンプファイルのクリーンインポートを取得するのが問題になっています。プロセスを自動化するのに十分安定させるには、パフォーマンスよりも安定性を優先するために、さまざまな選択を行う必要がありました。SQLバックアップを使用して災害から復旧しなければならなかったとしても、何日もダウンすることになります。
SQLを水平方向にスケーリングすることも非常に骨の折れる作業であり、ほとんどの場合、SQLでデータを最初に配置することを選択したときにおそらく意図しない方法でSQLを使用することになります。シャード、リードスレーブ、マルチマスターなど、これらはすべて、本当にDBで行うすべてのことを複雑にするソリューションであり、どれも問題を解決しません。いくつかの方法でのみそれを軽減します。これらのタイプのものが問題となるサイズのデータセットに近づき始めたら、MySQL（または実際には任意のSQL）からデータの一部を移動することを検討することを強くお勧めします。
複雑な結合にも注意してください。トランザクションの複雑さは、トランザクション量に加えて大きな要因になる可能性があります。
重いクエリをリファクタリングすると、パフォーマンスが大幅に向上する場合があります。
私はかつて、「機能しなくなった」mysqlを見ることを求められました。DB2ファイルがNFS2でマウントされ、最大ファイルサイズが2GBのNetwork Applianceファイラーにあることを発見しました。そして確かに、トランザクションの受け入れを停止したテーブルは、ディスク上でちょうど2GBでした。しかし、パフォーマンスカーブに関しては、まったく機能しなくなるまで、それはチャンピオンのように機能していたと言われています。この経験は常に、あなたが自然に疑うものの上下に常に寸法があることを思い出させてくれます。
データベースのサイズは、バイト数とテーブルの行数の点で重要です。ライトデータベースとblobで満たされたデータベースのパフォーマンスに大きな違いがあることに気づくでしょう。ディスク上のファイルに画像を保持し、データベースにファイル名のみを配置する代わりに、バイナリ画像をフィールド内に配置したため、アプリケーションが動かなくなった。一方、多数の行を繰り返すことは無料ではありません。
クエリのパフォーマンスは主にスキャンする必要があるレコードの数に依存し、インデックスはその中で大きな役割を果たし、インデックスのデータサイズは行数とインデックスの数に比例します。
インデックス付きフィールド条件と完全な値を含むクエリは、通常1ミリ秒で返されますが、starts_with、IN、Between、条件が含まれていることは、スキャンするレコードが多いため、明らかに時間がかかる可能性があります。
また、ALTERなどのDDLで多くのメンテナンスの問題に直面します。インデックスや新しい列を追加しても、ライブトラフィックが増えるとDROPが遅くなり困難になります。
一般に、データベースを必要な数のクラスターにクラスター化することをお勧めします（他の人が言うように、500GBは一般的なベンチマークであり、多くの要因に依存し、ユースケースに応じて異なる可能性があります）。クラスター（B2Bの場合により適しています）