語幹は、確固たる提案をするのに十分具体的ではありませんが、実行できることの完全なリストは次のとおりです。
- データベースクラスター ：アプリケーション層を変更したくない状況に適しており、データベースに触れるだけです。データベースクラスターから取得できる量には制限があります。リクエストの量が増え続けると、このソリューションも最終的に失敗します。しかし、幸いなことに、通常のシングルインスタンスMySQLですでに持っているすべての機能を利用できます。
- シャーディング ：質問はMySQLでタグ付けされており、それ自体ではシャーディングをサポートしていないため、このソリューションを使用する場合は、アプリケーション層に実装する必要があります。このソリューションでは、データを複数のデータベース（できれば別々のハードウェア上の複数のMySQLインスタンス）に論理的に分散させます。指定されたデータを保持する適切なデータベースを見つけるのはあなたの責任です。これはこれまでで最も効果的なソリューションの1つですが、常に実行可能であるとは限りません。その最大の欠点は、2つ以上のデータベースに散在するデータをトランザクションに含めることができないことです。
- 複製 ：シナリオによっては、データベースレプリケーションを組み込んで、データのコピーを作成できる場合があります。このようにして、マスターデータベースの代わりにそれらに接続し、その負荷を減らすことができます。デフォルトのレプリケーション定義は、データフローがマスターからスレーブへの一方向であるマスター/スレーブシナリオです。したがって、スレーブに加えた変更が軟膏に適用される場合、それらはマスターに影響を与えません。ただし、データフローが双方向であるマスター/マスターレプリケーション構成もあります。ただし、両方のマスター間で同時にデータが変更された場合に、アトミックな整合性を想定することはできません。最終的に、このソリューションは、マスター/スレーブモードで使用し、読み取り専用アクセスにスレーブを使用する場合に最も効果的です。
- キャッシュ ：おそらくこの解決策はここに含まれるべきではありませんが、あなたのステムはそれを拒否しないので、ここに行きます。データベースの負荷を軽減する方法の1つは、抽出されたデータをキャッシュすることです。このソリューションは、データの抽出に費用がかかる場合に特に役立ちます。 memcached
のように、多くのキャッシュサーバーがあります。 または
- その他のストレージエンジン ：現在のエンジンで必要なものが提供されない場合は、いつでもパフォーマンスの高いエンジンに切り替えることができます。もちろん、これはあなたのニーズがあなたに許す場合にのみ実行可能です。現在、ネイティブにシャーディングをサポートし、最小限の労力で線形にスケーリングできるRDBMSよりもはるかにパフォーマンスの高いNoSQLエンジンがあります。同じ自動シャーディングを提供する強力な全文検索機能を備えたLuceneベースのソリューションもあります。実際、従来のRDBMSを使用する必要がある唯一の理由は、トランザクションのアトミックな動作です。ただし、トランザクションが必須ではない場合は、RDBMSよりもはるかに優れたソリューションがあります。