2012-03-11 21 views
0

私のmap reduce操作は、特定のユーザーに負担をかけるための小額支払いの一覧をまとめます。 user_idは_idになります。私はまた、支払いが必要なマイクロペイメントの配列IDを保管しています。出力は、支払と呼ばれる透過物収集に入る。マップリデュースの出力をモンゴイド文書にする必要がありますか?

出力は一つの文書

{ "_id" : ObjectId("4f48855606164f4765000004"), "value" : { "payment" : "5.0", "conversions" : [ ObjectId("4f5bd23baa113e964700000e") ] } } 

のために、このようになります私は一種の私は支払いのコレクションを中心にmongoid文書の構築について考えていたように、これらの支払いを追跡したいと思います。私はそれができることを知っているのは知っているが、私は本当にそれをやっている誰も見ていないので、より良い方法がなければならないと思う。

また、このアプローチの1つの問題は、毎月支払いを行っているため、_idがuser_idであることが競合するためです。また、マイクロペイメントを別の州に更新する必要があるので、取引の問題が起こる可能性があると思います。そのため、支払いを一度も行わないとどうなりますか?これらの状態はstate_machineで変化します。

答えて

0

マップリデュースの出力をモンゴイド文書にする必要がありますか?

もちろんこれは間違いありません。これは、M/Rが単に「何らかのファイル」ではなくコレクションに出力される理由のようなものです。

また、このアプローチの1つの問題は、毎月支払いを行っているため、_idがuser_idであることが競合するためです。

明らかに、あなたのM/Rの出力は重要なデータです。このデータを将来のM/Rによって「叩かれる」コレクションに残さないでください。代わりに、作成したコレクションの名前を変更するか、手動でデータを「キーパー」コレクションに追加するforループを実行します。

「キーパー」コレクションでは、_id_id: { uid: ObjectId('...'), month: "201203" }のように変更します。 valuesフィールドをいくつかのフィールドに「ファンアウト」することもできます。また、トランザクションIDのフィールドを追加する必要があります。

また、MongoDBはデフォルトで "fire & forget"書き込みを使用することを覚えておいてください。これらは安全性が低い。あなたは、財務データを持っているので、あなたは、可用性とデータの安全性のためのベストプラクティスのすべてを、次のしていることを確認します(セカンダリデータセンターを持つ)

  • レプリカセット
    • ジャーナリングすべてがこれに書き込みいることを確認してくださいcollection/dbはw: majorityjournal: trueで行われます。これらの書き込みには数百ミリ秒かかりますので、この操作ではDBスループットが低下します。
    • データベースのパスワード
    • は、非標準のMongoDBポート、IPホワイトリスト(通常のDBセキュリティ)

    支払いのいずれかに障害が発生した場合はどうなりますか?

    これはここで説明するにはあまりにも単純な問題と方法です。代わりに、two-phase commit with MongoDBのこの文書を参照してください。

    2フェーズコミットでは、MongoDBのfindAndModifyコマンドが必要です。 Mongoidでこれを処理する方法を学ばなければなりません。

  • 関連する問題