4

Mongo でジョブ キューを実装したいと考えています。ソフトウェア システム全体が Mongo をベースにしているため、Mongo は自然で、うまく適合する可能性があります。

ジョブコレクションには、各ジョブの状態がドキュメントとして格納されます。これは、クエリのニーズに基づいた上限のないコレクションであると思います。ジョブドキュメントは次のようになります。

{
    "_id" : ObjectId("50a6742ee4b0a9a1c2cb4fd4"),
    "type" : "archive_job",
    "state" : 2,
    "priority" : 1,
    "timing" : {
        "submitted": ISODate(...),
        "running": ISODate(...),
        "completed": ISODate(...),
        "failed": null,
        "cancelled": null
    },
    payload: {
       ...job-specific JSON...
    }
}

ジョブコレクションの一般的なアクセス パターンは次のとおりです。

  • type、state、priority 、および場合によってはtiming.submittedの範囲クエリに基づいて、実行する未処理のジョブを検索します。以前の読み取り時間よりも長く送信されました
  • 処理された (完了、失敗、キャンセルされた) ジョブをすべて見つける
  • すべての未処理 (送信済み、実行中) のジョブを見つける
  • _id で特定のジョブを検索し、そのペイロードを取得します(状態が実行中の場合)

クエリの大部分は、実行が必要な未処理のジョブを見つけることです。ジョブコレクション内でドキュメント サイズが大きく変わらないように、ペイロードをjobs_payloadコレクションに移動する価値はありますか?

大量の処理済み (完了済み、失敗済み、キャンセル済み) のジョブと未処理のジョブは、最終的にジョブコレクションに必要なワーキング セット メモリを増加させますか? 適切なインデックスを使用しても、未処理のジョブを実行するためのアクセス時間は遅くなりますか?

スキーマ設計を使用して行うことができる代替案とトレードオフは何ですか?

4

1 に答える 1

-1

ペイロードをjobs_payloadコレクションに移動して、ドキュメントサイズがjobsコレクションで大きく変化しないようにすることは価値がありますか？

一般的に、埋め込みはmongodbでの正しい方法ですが、あなたの場合は問題ないように見えます。

未処理のジョブと比較して、大量の処理済み（完了、失敗、キャンセル）されたジョブは、最終的にジョブコレクションに必要なワーキングセットメモリを増やしますか？適切なインデックスを使用しても、未処理のジョブを実行するためのアクセス時間は遅くなりますか？

データベースがメモリに収まる間、速度低下は気づかれません。

スキーマは問題ないように見えます。例として、セロリ（mongodbバックエンドを持つ）スキーマを見ることができます。

于 2012-11-17T20:49:58.830 に答える