5

すべてのドキュメントに添付された画像を変換する必要があります (実際には、画像を 400px 幅に縮小する必要があります)。それを達成するための最良の方法は何ですか？nodejs コードで _changes をリッスンし、ドキュメントの保存時に必要な操作を実行することを考えていました。ただし、これには多くの欠点があります: a) ドキュメントの変更は、常に新しい添付ファイルが追加されたことを意味するとは限りません b) 既に縮小された画像を常に処理する必要があります (少なくとも画像の幅を確認してください)。

4

1 に答える 1

12

基本的にデータベースにいくつかのデータがあり、問題のほとんどは単にアプリケーションのロジックと実装にあると思います。Drizzle を使用するアプリケーションの要件リストは非常によく似ていると想像できます。とにかく、あなたのアプリケーションはどのように「細心の注意を払い」、CouchDB の強みを生かすことができるのでしょうか?

Node.js_changesリスナーは、非常に良い出発点のように思えます。Node.js には、誇大広告やばかげた議論がたくさんあります。しかし、CouchDB から「to-do リスト」を受け取り、そのリストを同時に実行するには、Node.js が理想的です。

メモ化

ドキュメント内の画像メタデータが役立つとすぐに思います。画像を取得して 400px かどうかを確認すると、コストがかかる可能性があります。"shrunk":trueまたはそのようなことをドキュメントに示すことができれば"width":400、ドキュメントをスキップすることがすぐにわかります。(これは最適化です。プロジェクトの初期段階では省略できます。)

しかし、メタデータを画像と同期させるにはどうすればよいでしょうか? 後で誰かが大きな画像を添付するかもしれませんが、メタデータにはまだ"shrunk":true. 1 つの答えは検証機能です。validate_doc_update()古いバージョンと新しい (候補) ドキュメント バージョンの両方を調べることができます。満たされていない場合はthrow()、例外として変更を防止できます。したがって、いくつかの方法でポリシーを適用できます。

  • 新しいイメージが添付されるたびに、"shrunk"キーも削除する必要があります
  • または、外部 Node.js ツールに、CouchDB にアクセスするための専用のユーザー名があります。"shrunk":trueユーザーがツールでない限り、ドキュメントを設定してはいけません

調査する価値のあるもう 1 つのアイデアは、 を設定する代わりに"shrunk":true、イメージの MD5 チェックサムに設定することです。(これはドキュメント内、._attachmentsオブジェクト内に既にあります。) したがって、Node.js ツールがこのドキュメントを参照すると、実行する作業があることがわかります。

{ "_id": "a_doc"
, "shrunk": "md5-D2yx50i1wwF37YAtZYhy4Q=="
, "_attachments":
  { "an_image.png":
    { "content_type":"image/png"
    , "revpos": 1
    , "digest": "md5-55LMUZwLfzmiKDySOGNiBg=="
    }
  }
}

言い換えると：

if(doc.shrunk == doc._attachments["an_image.png"].digest)
  console.log("This doc is fine")
else
  console.log("Uh oh, I need to check %s and maybe shrink the image", doc._id)

実行

以下のツールを書いたので偏見があります。しかし、私は成功しており、他の人は Node.js パッケージを使用して成功したと報告してい_changesます。

そして、CouchDB ドキュメントで ACID トランザクションに Txn を使用します: https://github.com/iriscouch/txn

パターンは、

  • follow()おそらくオプションで、_changes URL で実行し"include_docs":trueます。
  • 変更ごとに、作業が必要かどうかを判断します。その場合は、関数を実行して必要な変更を行い、txn()フェッチと更新を処理し、一時的なエラーが発生した場合は再試行します。

たとえば、Txn を使用すると、画像のサイズをアトミックに変更したり、メタデータを更新したりすることが非常に簡単になります。

最後に、プログラムがクラッシュした場合、既に処理済みの大量のドキュメントをフェッチする可能性があります。それは問題ないかもしれません (メタデータが機能している場合)。ただし、ときどきチェックポイントを記録したい場合があります。見た変更を覚えておいてください。

var db = "http://localhost:5984/my_db"
var checkpoint = get_the_checkpoint_somehow() // Synchronous, for simplicity

follow({"db":db, "since":checkpoint}, function(er, change) {
  if(change.seq % 100 == 0)
    store_the_checkpoint_somehow(change.seq) // Another synchronous call
})

ワーク キュー

繰り返しになりますが、私自身のすべてのツールを指すのは恥ずかしいです。しかし、画像処理はワーク キューの状況の典型的な例です。作業が必要なすべてのドキュメントがキューに入れられます。無制限の柔軟な労働者の軍隊が仕事を受け取り、ドキュメントを修正し、仕事を完了 (削除) します。

私はこれを自分でよく使用します。そのため、CouchDB キュー システムである CQS を作成しました: https://github.com/iriscouch/cqs

これは Node.js 用であり、独自の CouchDB サーバーを使用する点を除いて、Amazon SQS と同じです。すでに CouchDB を使用している場合は、CQS によってプロジェクトが簡素化される可能性があります。

于 2012-04-07T12:51:59.673 に答える