問題タブ [sharding]

Userユーザーレコードが異なるデータベース/テーブルに配置されるように、Django モデルをどのように分割しますか?

どのモジュール、モデル、およびビューを変更する必要がありますか? カスタム認証バックエンドを作成する必要がありますか? これを行うための比較的痛みのない方法はありますか？

ありがとう。

マルチテナントシステムを設計しており、データベースではなくアプリケーション層レベルでテナントによるシャーディングを検討しています。

仮に、これが機能する方法は、着信要求の場合、ルータープロセスが、この要求のテナントと仮想シャードIDを決定するためのプライマリ属性を含むテナントのグローバルコレクションを持っていることです。この仮想シャードIDは、実際のシャードにさらにマップされます。

実際のシャードには、アプリケーションのコードとこのテナントのデータ全体の両方が含まれています。これらのシャードは、LNMP（Linux、Nginx、MySQL / MongoDB、PHP）サーバーになります。

ルータープロセスはプロキシとして機能する必要があります。いくつかのローカルデータベースまたはファイルに格納されているコレクションに基づいて、着信要求のターゲットシャードを決定するためのコードを実行できる必要があります。これをより適切にスケーリングできるようにするために、シャード自体をルーターとしても機能させ、リクエストを適切なシャードに転送するリバースプロキシを実行できるようにすることを検討しています。シャードで実行されているnginxインスタンスは、そのリバースプロキシとしても機能する可能性があります。しかし、リクエストを適切なシャードと照合するために必要なアプリケーションロジックをどのように実行しますか。

このルーターの実装に関するアイデアや提案をいただければ幸いです。

ありがとう

MySQL テーブルをシャーディングするための最良のアプローチは何ですか。私が考えることができるアプローチは次のとおりです。

1. アプリケーションレベルのシャーディング?
2. MySQL プロキシ層でのシャーディング?
3. シャーディング用の中央検索サーバー?

この分野で興味深いプロジェクトやツールを知っていますか?

シャーディング (レプリカ セット上) を使用しており、データベースをダンプしようとしています。キー files_id によって mycms-prod.fs.chunks のシャーディングが有効になっています。追加情報: http://groups.google.com/group/mongodb-user/browse_thread/thread/a8f05cbf495d6487 この指示を読みました: http://www.mongodb.org/display/DOCS/Backing+Up+Sharded+クラスター (小規模クラスターの場合)。

そしてmongos.logで：

次に、server1.domain.com に移動します。

mongos はこのコンピュータに接続すべきではないと思います。レプリカセットのセカンダリであるため。

これはバグですか？

バージョン 1.8.1 のすべてのコンポーネント。

ニュアンスがあります。このデータベースは、mongorestore を使用して復元されます。

ダンプに何か問題があるのではないかと思いました。新しいデータベース シャード テストを作成し、そこに 500 個のファイル (gridfs 内) をコピーして、シャーディングを有効にしました。

すべてのデータがサーバー間で分散されるまで待ちます。そして、データベースのダンプを作成しようとしました。驚いたことに、それはうまくいきました！異なるmongosからも動作します。これは何を意味するのでしょうか？

もう1つのニュアンスに気づきました。

私がそうする場合：

tracking_pagevisit コレクションでエラーが発生しました。

次に... このコレクションを個別にダンプしてみましょう。

このワークアウト!!! 何が起こっていますか？

私のシステム:

モンゴが6匹います。実際には常に 2 つだけ使用されます。2 つのアプリケーションの場合。各アプリケーションには独自の mongos があります。

合計 9 台のサーバーがあります。params を使用して mongod を実行するたびに: shardsvr = true replSet = rs1 (rs2 および rs3)。レプリカが3つ。各レプリカは 3-mongod で構成されます。3 つの構成サーバー (server4.domain.com: 28001、server6.domain.com:28001、server1.domain.com:28001)。

Mongos パラメータ bind_ip = 127.0.0.1,123.456.789.12 ポート = 30000 フォーク = true configdb = server4.domain.com:28001,server6.domain.com:28001,server1.domain.com: 28001

使っていたmongosを再起動しました。それは役に立ちました。データベースは同一になりました。しかし、ダンプはまだ機能していません。上記のエラーを書きました。

ありがとう。

シャーディングデータベースはシャードキーを使用してチャンクを分割し、クエリをルーティングするため、シャードキーを増やすと、より多くのクエリを対象にすることができると思います。

このように複数のキーを指定してみました

しかし、それが機能するかどうか、そしてこれを行うことの欠点は何ですか？

私は最近Elasticsearchを発見し、遊びをすることにしました。残念ながら、インデックスの追加に問題があります。

インデックスの追加に使用されるコードは次のとおりで、新しいインデックスを追加しようとするたびに実行されます。

インデックスが追加されていないようで、クラスターの階層は現在赤です（シャードの1つが赤であるため）が、これを解決する方法がわかりません。インデックスが毎回追加されているという確認を受け取っていますが、検索時またはes-adminに表示されません。

すべてのヘルプやアイデアは大歓迎です。

私はソーシャルゲームの開発者であり、200万人近くのプレイヤーがいます（そしてこの数は増え続けています）。

マスターMySQLDBサーバーには24GbのRAMがあり、非常に大きなサイズの1つのテーブルがなければ、データベースはメモリに収まる可能性があります。現在、ほぼ10億のレコードがあり、サイズは33Gbです。次のスキーマがあります。

私はそれを最適化する方法について次の計画について考えています：

1. 「archive_」プレフィックスが付いた同様のテーブルを追加します

2. この新しいテーブルをハッシュで分割します

3. たとえば、1か月間ゲームをプレイしていない非アクティブなプレーヤーを見つけます。

4. 大きなテーブルからアーカイブテーブルにレコードをコピーします

5. アーカイブされているプレーヤーにマークを付け、ログインするたびに元のテーブルの代わりにアーカイブテーブルを使用します

6. オプションで、元のテーブルもハッシュでパーティション化します（オプションで、多くのダウンタイムが発生する可能性があるため）

7. シャーディングについて考えるのに何も役立たない場合

あなたはそれについてどう思いますか？それは良い計画のように聞こえますか？

インデックス作成とシャーディングの違いは何ですか。両者の役割は？

3 つのテーブルを使用するアプリケーションを開発しています。1 ～ 100 万行の製品。2 ～ 5 億行のユーザー。ユーザーが好む製品の 3 ～ 100 億行。テーブルは時間とともに大きくなりますが、それらの数にとどまります。この種の DB に適した方法を選択したいと考えています。私はシャーディング、クラスタリング、またはパーティショニングについてあまり知りませんが、この問題の最善の解決策を教えてくれる人がいるなら、私はそれに焦点を当てます。それは大きな助けになるでしょう. mysql をサポートするメソッドのみが必要で、この種の DB に複数のサーバーが必要な場合は? ありがとう。

NoSQL データベース サーバーのスケーラビリティ/弾力性をテストする YCSB ベンチマークのクライアントとしての MongoDB へのあらゆる種類の参照を目にします。

https://github.com/brianfrankcooper/YCSB

ただし、テストはスケーリングと弾力性を示すために 6 ～ 10 台のサーバー マシンで実行するように設計されているため、ベンチマークにはある種のシャーディング セットアップが必要であることは明らかです。

その構成がMongoDBでどのように見えるかについて、インターネット上で参照を見つけることができません。結果を公開し、構成がどのように見えるかを公開した人を見つけることができません。

これは本当に成功したのでしょうか？Cassandra、HBase などの元の YCSB クライアントと比較した結果はどうですか。

MongoDB クライアントのコードでは、「クライアント スレッドごとに 1 つの DB インスタンスがあります」と表示されているため、特に混乱しています。スニペットを参照してください。

ただし、Brian Cooper YCSB の結果に関する論文では、ワークロードを最大 500 スレッドまで実行したと記載されています。

6.1 実験のセットアップ

ほとんどの実験では、6 台のサーバー クラスのマシン (デュアル 64 ビット クアッド コア 2.5 GHz Intel Xeon CPU、8 GB の RAM、6 ディスクの RAID-10 アレイ、およびギガビット イーサネット) を使用して各システムを実行しました。また、47 台のサーバー クラスターで PNUTS を実行し、YCSB を使用して大規模なシステムのベンチマークを実行できることを実証しました。PNUTS には、構成サーバーとルーターとして機能する 2 つの追加のマシンが必要でした。HBase には、「マスター サーバー」と呼ばれる追加のマシンが必要でした。これらのサーバーの負荷は軽く、ここで報告する結果は主に 6 台のストレージ サーバーの容量に依存します。YCSB クライアントは、別の 8 コア マシンで実行されました。クライアントは、希望する提供スループットに応じて、最大 500 のスレッドで実行されました。テストでは、クライアント マシンがボトルネックではないことがわかりました。特に、

このベンチマークのシャーディング構成がある場所を知っている人はいますか?シャード構成またはシャードが必要ない理由の詳細な説明によってバックアップできる競合に対する実際の結果はありますか?

ありがとう - ロバート