mysql - データベースシャーディングの設定-データベース間クエリはありません

Question

私は、クライアント（小規模から大規模の組織）ごとに、他のクライアントのレコードにクエリを実行できない（そしてできないはずの）Webアプリケーションを開発しています。

データを単一のデータベースに保持するのは簡単で、更新と保守が簡単になります（スケーラビリティの問題が発生するまで）。しかし、私は今、アプリケーションを将来にわたって利用できるようにしたいと思っています。各クライアントのデータが分離されたデータベースに含まれている場合、各クライアントのパフォーマンスは向上し、拡張性も向上するはずです。単一のスキーマを複数のデータベースに分割していないため、データベースの「シャーディング」と同等かどうかはわかりません。私は基本的に、すべてのデータベースで単一のスキーマを複製します（CDでソフトウェアを出荷する当時のように-それぞれが独自のデータベースを持っています）。

これを少し読んだので、一般的な概念がわかりました。しかし、頭の中にはたくさんの質問があります。このプロセスがどれほど透過的であるかは正確にはわかりません。または、変更をロールアウトするたびに何百ものスキーマを更新するというメンテナンスの悪夢に遭遇した場合。

本当に、私は単純な「完全な」例を探しています（うまくいけばspring / javaを使用しています）。

1. 単一のデータソースで開始する単一のアプリケーションサーバー、たとえば、ユーザーIDをデータベースにマッピングする単一のテーブルを持つmysqlインスタンスを持つことができると想像します。

   • ユーザーID
   • データベース/シャードID

   データベースキャッシングを無視して、すべてのリクエスト（クエリ）に対して、ユーザーのシャードIDを検索する必要がありますか？それとも、これはセッションごとに最初に1回実行して、ターゲットデータベースと直接通信できるものですか？（あなたは私がサーバーサイドのものに強くないと言うことができるかもしれないので）。

2. 誰かがこれが春にどのように配線される可能性があるかについての高レベルの概要を与えることができますか？現在、私のアーキテクチャは非常に単純です。jdbctemplateを使用する単純なSpringコンポーネントDAOがあります。DAOのデータソースが挿入されます（データソースはapplicationContext.xmlで構成されます）。DAOは私のサービスクラスに自動配線されています。かなり標準的なもの。

3. 前のステップが機能し、スキーマを変更する必要があるとしましょう。スキーマの変更を一度適用して、それを他の100個のデータベースに伝播させるために使用できる管理ツールはありますか？

MySQLを使用しています。「MySQLプロキシ」は問題1と2を解決できるかもしれないと私は信じています。誰かがこれについて何か経験がありますか？スキーマの更新の管理を処理できないと思うので、独自のソリューションをロールする必要があるかもしれません。

ありがとう！

Answer 1

私は会社でスプリングとシャーディングを使用しています。

1. ShardDataSourceManager基本的に接続プールのプールとなるを実装し、シャードIDでデータソースを検索します。
2. 独自のトランザクションアノテーションを定義し、それを使用してメソッドにアノテーションを付けます
3. メソッドのアノテーションといくつかのコンテキスト情報を読み取るインターセプターをdaoレイヤーに作成する必要があります。コンテキスト情報から、シャードIDとルックアップデータソースを検索し、ローカルスレッドに挿入します。
4. データソースを検索するときのdaoレイヤーは、ローカルスレッドを調べてjdbcテンプレートを構築し、それに対してクエリを実行します。

Answer 2

私はSpringを使っていないので、Springと話すことはできません。

Java EE の帽子をかぶった私なら、単純に JNDI データソースを使用し、クライアントごとに 1 つ作成し、クライアント名またはクライアントを区別するために使用している識別子を介して検索します。

さて、Spring でそれができると確信していますが、その方法はわかりません。

一般的なデータベース接続プールの実装が、接続数が多い「100 データベース」をどれだけうまく処理できるかは、別の問題です (数百の開いている接続ソケットのビジョンが思い浮かびます)。私もそれをしたことがないので、それと話すことはできません。

しかしその後は、各プールが個別のデータベースを指しているため、基本的にはすべて完了です。各プールには独自の構成を設定できるため、DB を別のホストなどに移動できます。

テストで失敗するまでは、それが問題の最初のカットになりますが、失敗ポイントはDBプールの実装またはそれに関連するものになると推測しています。それ以外はすべて一般的な DB サーバーと Java です。

Answer 3

私は春についてあまり知らないので、それについて多くを語ることはできません。ただし、データベースのシャーディングについては、高スケーラビリティに関するこの投稿をご覧になることをお勧めします

New Relic Architecture - 1 日あたり 200 億以上のメトリクスを収集

優れたシャーディング戦略と、負荷が変動する場合にそれがどのように役立つかについて説明しています。また、彼がシャーディングの詳細を説明しているコメントセクションも参照してください。

Answer 4

これは一種のシャーディング/マルチテナンシーの状況です。メンテナンスの悪夢に見舞われ、割り当てられたコードを書く必要があります。使用できるサードパーティがあります-ScaleBaseを試すことができます（開示：私はそこで働いています）。彼らは、アプリケーションに対して透過的な方法で、あなたが説明したことを正確に実行します。