私は、レプリカ セット構成で MongoDB を試して、それがどのようにスケーリング/実行/対処するかを確認しました。
私はMorphia ( Mongo の Java ドライバーの上にある POJO マッピング レイヤー) を使用して、10,000 個の単純なランダム ドキュメントを単一のコレクションに保持しています。データベースに送信されたデータが安全に永続化されることを期待して、POJO (MyData以下のスニペット) に注釈を付けました。@Entity(concern="REPLICAS_SAFE")
私の POJO は、ObjectIdフィールド (Mongo のプライマリ キー タイプ)、Stringランダムな長さ (最大 20 文字) のランダムな文字、およびlongを使用して生成された で構成されてRandom.nextLong()いました。
私のコードは次のとおりです。
for (int i=0;i<10000;i++) {
final MyData data = new MyData();
boolean written = false;
do {
try {
ds.save(data); //ds is of type DataStore
written=true;
} catch (Exception e) {
continue;
}
}
while (!written);
}
私は 4 ノードのレプリカ セット クラスターをセットアップし、上記のプログラムを実行してから、比喩的にケーブルを引き抜いて何が起こったかを確認しました。
望ましい結果は、すべてのドキュメントをデータベースに正常に永続化するまでプログラムを実行することでした。
数回行った後の実際の結果は、次のいずれかでした。
- Java は 10k のエントリをコミットしたが、データベースには 10k 未満しかないと報告している
- Java が 10k 未満をコミットしたことを報告し、データベースが同じ値またはそれ以下の値を報告する
- すべて正常に動作しています
あるケースでは、バックアップされたノードが実際には PRIMARY ノードに追いつくことができず、削除されたデータベースで最初から開始する必要がありました。これは、opfile パラメーターを 2 ギガに増やしたにもかかわらずでした。これは、10,000 行の非常に単純なデータを再生するのに十分であると考えていました。
あなたが知っておくべきその他の事項：
- これらはすべて単一のハードウェア (2 ギガの Pentium D!) 上で実行され、クラスタはそれぞれ 128 メガ RAM の 2 つの 32 ビット Ubuntu Server VirtualBox インスタンス上で実行され、Java クライアントは Windows XP ホスト内で実行されます。各仮想マシンで2 つの
mongodプロセスが実行され、1 つの仮想マシンでアービターも実行されました。 - 2 台の仮想化されたマシンのクロックは数秒ずれていました (これを修正するには VirtualBox Guest Additions をインストールする必要があります) が、それほど大きくはありませんでした。 d 言及します。
私は 32 ビット マシンでの Mongo の 2 ギガ制限を認識しており、他の人が記録を失っているという事実を認識しており、これらのテストを行っているマシンが正確に上位 500 に含まれていないことを認識しています (これが、私が保持することを選択したデータが小さかった理由です) しかし、私のテストが機能したとき、それらは非常にうまく機能しました.
私が抱えていた問題は、Mongo がまだゴールデンアワーの準備ができていないことを証明しているのでしょうか、それとも私が何か本質的に間違ったことをしているのでしょうか?
私は1.6.5を使用しています。
洞察、ヒント、ヒント、指針、説明、または批判は大歓迎です!
ps: 私はトローリングではありません - NoSQL が適している種類のデータに対する NoSQL のアイデアが本当に好きなので、それが機能することを本当に望んでいますが、今のところあまり運がありません!