問題タブ [sharding]

Railsでシャードデータベースを処理する最良の方法は何ですか? シャーディングは、アプリケーション レイヤー、アクティブ レコード レイヤー、データベース ドライバー レイヤー、プロキシ レイヤー、またはその他のレイヤーで処理する必要がありますか? それぞれの長所と短所は何ですか？

約 70 GB の InnoDB データベースがあり、今後 2 ～ 3 年で数百 GB に拡大すると予想しています。データの約 60% が 1 つのテーブルに属しています。現在、64 GB の RAM を備えたサーバーを使用しているため、データベースは非常にうまく機能しているため、データベース全体がほぼメモリに収まりますが、データ量がかなり大きくなる将来が心配です。現在、テーブル (特にデータの大部分を占めるテーブル) を分割する何らかの方法を検討しており、どのように行うのが最善の方法であるかを考えています。

私が現在知っているオプションは

• バージョン 5.1 に付属する MySQL Partitioning の使用
• データのパーティショニングをカプセル化するある種のサードパーティ ライブラリを使用する (休止状態のシャードなど)
• アプリケーション内に自分で実装する

私たちのアプリケーションは、J2EE と EJB 2.1 で構築されています (いつか EJB 3 に切り替えたいと思っています)。

何を提案しますか？

編集 (2011-02-11):
更新情報: 現在、データベースのサイズは 380 GB、「大きな」テーブルのデータ サイズは 220 GB、インデックスのサイズは 36 GB です。したがって、テーブル全体がメモリに収まらなくなりますが、インデックスはメモリに収まります。
システムはまだ (同じハードウェア上で) 正常に動作しており、データのパーティション化についてまだ検討中です。

編集 (2014-06-04): もう 1 つの更新: データベース全体のサイズは 1.5 TB で、「大きな」テーブルのサイズは 1.1 TB です。サーバーを 128 GB RAM の 4 プロセッサ マシン (Intel Xeon E7450) にアップグレードしました。システムはまだ正常に動作しています。次に計画しているのは、大きなテーブルを別のデータベース サーバーに配置することです (ソフトウェアで必要な変更を既に行っています) と同時に、256 GB RAM を備えた新しいハードウェアにアップグレードします。

このセットアップは 2 年間続くことになっています。その後、最終的にシャーディング ソリューションの実装を開始するか、1 TB の RAM を搭載したサーバーを購入する必要があります。

編集 (2016-01-18):

それ以来、大きなテーブルを別のサーバー上の独自のデータベースに配置しました。現在、このデータベースのサイズは約 1.9 TB で、他のデータベース (「大きな」テーブルを除くすべてのテーブルを含む) のサイズは 1.1 TB です。

現在のハードウェア設定:

• HP ProLiant DL 580
• 4 x Intel(R) Xeon(R) CPU E7- 4830
• 256GBのRAM

この設定でパフォーマンスは問題ありません。

大規模な Web サイトのスケーリングの問題を解決するために、「シャード」手法について何度か言及されているのを聞いたことがあります。この「破片」テクニックとは何ですか?なぜそれが優れているのですか?

私は、電子メール サービスとソーシャル ネットワークの間のどこかにある Web アプリに取り組んでいます。今後かなり大きくなる可能性を感じているので、スケーラビリティが気になります。

集中化された 1 つの MySQL/InnoDB データベースを使用し、その時が来たらそれを分割する代わりに、アクティブなユーザーごとに個別の SQLite データベースを作成することにしました。つまり、「シャード」ごとに 1 つのアクティブなユーザーです。

そうすれば、データベースのバックアップは、各ユーザーの小さなデータベース ファイルをリモートの場所に 1 日に 1 回コピーするのと同じくらい簡単になります。

スケールアップは、新しいファイルを保存するためにハードディスクを追加するのと同じくらい簡単です。

アプリが単一のサーバーを超えて成長した場合、GlusterFS を使用してファイルシステム レベルでサーバーをリンクし、アプリを変更せずに実行するか、各サーバーが隣接するサーバーの sqlite ファイルを操作できるようにする単純な SQLite プロキシ システムを装備できます。

各 HTTP リクエストは一度に 1 つまたは 2 つのデータベース ファイルにしかアクセスせず、SQLite は読み取り時にのみブロックするため、同時実行の問題は最小限に抑えられます。

このアプローチにより、アプリを適切にスケーリングし、多くのクールでユニークな機能をサポートできると確信しています。私は間違った賭けですか？何か不足していますか？

更新これまでのところ問題なく機能している、それほど極端ではないソリューションを使用することにしました。私は一定数のシャードを使用しています - 正確には256個のsqliteデータベースです。各ユーザーは、単純なハッシュ関数によってランダムなシャードに割り当てられ、バインドされます。

私のアプリのほとんどの機能では、1 回のリクエストで 1 つまたは 2 つのシャードにアクセスする必要がありますが、ユーザーによっては、256 個の異なるシャードのうち 10 ～ 100 個の異なるシャードに対して単純なクエリを実行する必要があるものがあります。テストでは、すべてのデータが RAM にキャッシュされている場合、約 0.02 秒以下かかることが示されています。私はそれで生きていけると思います！

UPDATE 2.0アプリを MySQL/InnoDB に移植し、通常のリクエストではほぼ同じパフォーマンスを得ることができましたが、シャード ウォーキングを必要とするその 1 つのリクエストでは、innodb が 4 ～ 5 倍高速です。この理由とその他の理由で、私はこのアーキテクチャを削除しますが、どこかで誰かがその用途を見つけてくれることを願っています...ありがとう。

短縮版

ユーザーをシャードに分割する場合、「ユーザー検索」を提供するにはどうすればよいですか? 明らかに、すべての検索がすべてのシャードにヒットすることは望んでいません。

ロングバージョン

シャードとは、複数のデータベースがあり、それぞれに全データの一部が含まれていることを意味します。(単純な) 例として、データベース UserA、UserB などには、名前が「A」、「B」などで始まるユーザーが含まれている可能性があります。データベース。戻ってきたユーザーがサインインすると、そのユーザーの名前をもう一度調べて、そのユーザーの情報を取得する正しいデータベースを判断します。

シャーディングと読み取りレプリケーションの利点は、読み取りレプリケーションが書き込みをスケーリングしないことです。マスターに送信されるすべての書き込みは、各スレーブに送信する必要があります。ある意味では、読み取り負荷が分散されていても、それらはすべて同じ書き込み負荷を担います。

一方、シャードは互いの書き込みを気にしません。Brian が UserB シャードにサインアップした場合、UserA シャードはそれについて知る必要はありません。Brian が Alex にメッセージを送信した場合、その事実を UserA シャードと UserB シャードの両方に記録できます。このようにして、Alex または Brian のいずれかがログインすると、すべてのシャードにクエリを実行することなく、送受信したすべてのメッセージを自分のシャードから取得できます。

ここまでは順調ですね。検索はどうですか？この例では、Brian が「Alex」を検索すると、UserA を確認できます。しかし、彼が姓の「Smith」で Alex を検索するとどうなるでしょうか。すべてのシャードにスミスがいます。ここから、次の 2 つのオプションが表示されます。

1. アプリケーションで各シャードで Smiths を検索します。これは、ゆっくり (各シャードを連続してクエリする) または迅速に (各シャードを並行してクエリする) 行うことができますが、いずれにしても、すべてのシャードがすべての検索に関与する必要があります。読み取りレプリケーションが書き込みをスケーリングしないのと同じように、検索がすべてのシャードにヒットしても、検索はスケーリングされません。検索ボリュームが各シャードを圧倒するほど高くなる時期に達する可能性があり、シャードを追加しても検索ボリュームは同じになるため役に立ちません。
2. それ自体がシャーディングに耐えられるある種のインデックス作成。たとえば、検索したい一定数のフィールドがあるとします: 名と姓です。UserA、UserB などに加えて、IndexA、IndexB などもあります。新しいユーザーが登録されると、そのユーザーを見つけてもらいたい各インデックスに追加します。そこで私は Alex Smith を IndexA と IndexS の両方に入れました。彼は "Alex" または "Smith" のいずれかで見つけることができますが、部分文字列はありません。この方法では、各シャードに対してクエリを実行する必要がないため、検索がスケーラブルになる可能性があります。

では、検索はスケーリングできますか? もしそうなら、この索引付けアプローチは正しいものですか? 他にある？

スケーラビリティの問題が発生しているデータベース スキーマを使用しています。スキーマ内のテーブルの 1 つが約 1,000 万行に増えました。私は、このスキーマをより大きなデータセット (たとえば、10 億行から 1,000 億行) にスケーリングできるように、シャーディングとパーティション分割のオプションを検討しています。私たちのアプリケーションは、Oracle、MS SQL Server、MySQL を含むがこれらに限定されないいくつかのデータベース製品にも展開できる必要があります。

これは一般的に大きな問題であり、利用可能なオプションについて調べたいと思います。データベースのシャーディングとパーティショニングの戦略について、どのようなリソース (書籍、ホワイトペーパー、Web サイト) がありますか?

質問はそれをすべて言います。

例: データベース テーブルを分割する予定です。テーブルには、「アクティブ」、「完了」、および「削除済み」としてフラグが立てられた顧客注文が含まれています。また、フラグごとに 1 つずつ、合計 3 つのシャードがあります。

私が理解している限り、フラグが変更されたときに、行を正しいシャードに移動する必要があります。

私は正しいですか？これを行う最善の方法は何ですか？トリガーは使用できますか?

行をすぐに移動するのではなく、日/週/月の終わりにのみ移動することを考えましたが、特定のフラグを持つ行がどのシャードに存在し、すべてのシャードに対して常に検索を実行する必要があるかはわかりません。

編集:いくつかの明確化:

一般に、行が存在するシャードを決定する基準を選択する必要があります。この場合、上記のフラグにしたいと思います。これは、この種のデータを分割する最も自然な方法だからです。（私の意見では）非常に頻繁にアクセスされるアクティブな注文の数は限られています。めったにアクセスされない多数の完成した注文があり、ほとんどアクセスされない膨大な数のデータ行があります。

特定のデータ行が存在する場所を探したい場合、すべてのシャードを検索する必要はありません。ユーザーがアクティブな注文をロードしたい場合、どのデータベースを参照する必要があるかは既にわかっています。

現在、私のシャーディング基準であるフラグが変更されており、このケースに対処する最善の方法を知りたいと思っています。レコードを元のデータベースにそのまま保持すると、最終的にすべてのデータが 1 つのテーブルに蓄積されます。

私の Web アプリケーションは複数のデータベース シャードを使用する必要があり、場合によってはこれらのシャードを並行してクエリする必要があります。並列ノンブロッキング データベース アクセスを成熟して安定してサポートする Web スクリプト言語はありますか? もしそうなら、あなたは私を正しい方向に向けることができますか？無料のオープンソースが好まれますが、私は主に動作するものを望んでいます.

スレッドは私には問題ありませんが、本当のマルチスレッド サポートは必要ありません。私が望むのは、5 つの異なるデータベース サーバーに対する 5 つの 10 秒のデータベース クエリが、50 秒ではなく 10 秒かかることだけです。実際に使用された CPU の数は問題ではありません。

ASP.NET MVC でブログ ホスティング アプリを作成することを検討しています。私は .NET は初めてですが、LAMP の世界では十分な知識があります。私の質問は、ユーザー データの水平スケーリングに関するものです。

ブログを持つ各ユーザーは、データベースに 6 つのテーブルのようなものを持っています。ユーザーの 20% を 1 つのデータベース サーバーに配置し、20% を別のデータベース サーバーに配置できるように、水平方向のスケーリングを計画したいと考えています。ユーザーが使用していたデータベース サーバーを確認します。その後、アプリはその特定のデータベース サーバーとのみ通信します。

SqlMembershipProvider で使用されるデータベースを簡単に分割する方法がわかりません。任意のヒント？