[解決済み] MySQLのスケーリングソリューション(レプリケーション、クラスタリング)

質問

において 起動 で働いている私たちは今、データベースのスケーリングソリューションを検討しています。MySQL では、（少なくとも私にとっては）やや混乱します。 MySQL クラスタ , レプリケーション および MySQL クラスタレプリケーション (ver. 5.1.6 から)、これは MySQL クラスタの非同期バージョンです。MySQL のマニュアルでは、その違いのいくつかを説明しています。 クラスタFAQ でいくつかの違いを説明していますが、そこから一方を使用するか他方を使用するかを確認することは困難です。

これらのソリューションの違いや、長所と短所、また、それぞれをいつ使うのがお勧めなのか、詳しい方からのアドバイスをお願いします。

どのように解決するのですか？

私は、利用可能なオプションについて多くの本を読みました。また、「High Performance MySQL 2nd edition」を手に入れましたが、これは非常にお勧めです。

これは、私が何とかまとめたものです。

クラスタリング

一般的な意味でのクラスタリングは、外部のアプリケーションからは1つのサーバに見える多くのサーバに負荷を分散させることです。

MySQL NDB クラスタ

MySQL NDB Cluster は、同期レプリケーションと自動データ分割を備えた、分散、インメモリ、シェアードナッシングストレージエンジンです（失礼、ハイパフォーマンスブックから文字通り借用しましたが、そこでは非常にうまく表現されています）。これは、一部のアプリケーションでは高性能なソリューションとなり得ますが、一般に Web アプリケーションはうまく動作しません。

主な問題は、非常に単純なクエリ (1 つのテーブルにのみ触れるもの) 以外では、一般にクラスタは複数のノードでデータを検索する必要があり、ネットワーク遅延が忍び込んでクエリの完了時間を大幅に遅らせることです。アプリケーションはクラスターを 1 台のコンピューターとして扱うため、どのノードからデータを取得するかを指示することができないのです。

さらに、インメモリ要件は、多くの大規模データベースでは実行不可能です。

コンティニュアスセコイア

MySQLのもう一つのクラスタリングソリューションで、MySQLサーバの上でミドルウェアとして動作します。同期レプリケーション、ロードバランシング、フェイルオーバーを提供します。また、最新のデータを持つノードを自動的に選択し、リクエストが常に最新のコピーからデータを取得することを保証します。

私はいくつかの 良いこと を読みましたが、全体的にかなり期待できそうです。

フェデレーション

フェデレーションはクラスタリングと似ているので、ここにも引っ張ってきました。MySQL は、フェデレーテッド ストレージ エンジンを介してフェデレーションを提供します。NDB クラスターソリューションと同様に、単純なクエリのみではうまくいきますが、複雑なクエリではクラスターよりさらに悪くなります（ネットワーク遅延がはるかに大きくなるため）。

レプリケーションとロードバランシング

MySQL には、異なるサーバ上にデータベースの複製を作成する機能が組み込まれています。これは、サーバー間の負荷分散、ホットバックアップ、テストサーバーの作成、フェイルオーバーなど、さまざまなことに使用できます。

レプリケーションの基本的な設定は、1つのマスターサーバーが主に書き込みを処理し、1つ以上のスレーブが読み込みのみを処理することです。より高度なバリエーションとして マスター・マスター この構成では、複数のサーバーが同時に書き込みを行うことで、書き込みの規模も拡大することができます。

MySQL のレプリケーションは非同期なので、すべてのノードが常に最新のデータを持っているわけではありません。このため、アプリケーションがレプリケーションを認識し、レプリケーションを考慮したクエリを組み込んで、期待通りに動作させることが必要です。一部のアプリケーションではこれは問題ではないかもしれませんが、常に最も新しいデータが必要な場合は、やや複雑になります。

レプリケーションは、ノード間の負荷を分割するために何らかのロードバランシングを必要とします。これは、アプリケーション コードへのいくつかの修正、または専用のソフトウェアおよびハードウェア ソリューションの使用と同じくらい簡単なことです。

シャーディングとパーティショニング

シャーディングは、データベースソリューションを拡張するために一般的に使用されるアプローチです。データをより小さなシャードに分割し、異なるサーバーノードに分散させます。このため、アプリケーションは、必要な情報をどこで見つけるかを知る必要があるため、効率的に動作するためにデータストレージの変更を認識する必要があります。

データ シャーディングに対処するために、次のような抽象化フレームワークが利用可能です。 Hibernate シャード は、Hibernate ORMの拡張機能です(残念ながらJavaです。私はPHPを使っています)。 HiveDB もそのようなソリューションで、シャードのリバランシングもサポートしています。

その他

スフィンクス

スフィンクス は全文検索エンジンで、テスト検索よりもはるかに多くのことに使用することができます。多くのクエリにおいて、MySQL よりもはるかに高速で (特にグループ化やソートにおいて)、リモートシステムに並行してクエリを実行し、結果を集約することができます - そのため、シャーディングと併用すると非常に有用です。

一般的にsphinxは、利用可能なハードウェアとインフラをより多く活用するために、他のスケーリングソリューションと一緒に使用されるべきです。欠点は、賢く使うために、アプリケーションコードがsphinxを認識する必要があることです。

概要

スケーリングソリューションは、それを必要とするアプリケーションのニーズによって異なります。私たちやほとんどの Web アプリケーションでは、ロード バランサーで負荷を分散しながらレプリケーション (おそらくマルチマスター) を行うのがよい方法だと考えています。特定の問題領域（巨大なテーブル）のシャーディングも、水平方向に拡張できるようにするために必要です。

また、Continuent Sequoia を試してみて、アプリケーション コードへの変更が最も少ないので、それが本当に約束したことを実行できるかどうか見てみようと思っています。