web-dev-qa-db-ja.com

nodejsとmongodbでハッシュタグをモデル化する方法

既存のアーキテクチャ:mongodbバックエンドを備えたnodejsサーバー。

#hashtagsを含むことができる画像を説明する文字列があります。

文字列からハッシュタグを抽出し、ハッシュタグを保存して、画像をそのハッシュタグに関連付けたいと思います。

したがって、たとえば「#bandcamp #nycで楽しんで」と画像がアップロードされている

#bandcampおよび#nycが抽出されます。

  • それらがハッシュタグとしてまだ存在しない場合、それらは作成され、画像はそれらの両方に関連付けられます。

  • それらが存在する場合、それは認識され、画像は両方に関連付けられます。

したがって、1つまたは複数のハッシュタグのすべての画像を取得するmongo findクエリを作成することが可能になります。

私はnosqlを使い始めたばかりですが、リレーショナルで私が持っていると理解しています

  • テーブルのハッシュタグ
  • テーブル画像
  • テーブル画像

多対多の関係で。画像には多くのハッシュタグを含めることができ、ハッシュタグには多くの画像を含めることができます。

Mongoにはどのようなアプローチが適していますか?このようなQ&Aを読むことから: https://stackoverflow.com/questions/8455685/how-to-implement-post-tags-in-mongo

タグを使用して画像ドキュメントにサブドキュメントを実装できることがわかります。検索と取得にそれは効率的ですか?

次に http://cookbook.mongodb.org/patterns/count_tags/ を使用できます-マップは縮小しますか?

したがって、次のようになります。

タグ付きの画像コレクションサブドキュメントタグコレクション

  • タグ付きの画像ドキュメント画像の作成時にタグが抽出されて追加されたサブドキュメントと、まだ存在しない場合はコレクションに新しいタグが追加されます(つまり、タグは一意である必要があります)

タグコレクションにタグを作成し、map reduceを実行します。

それは音ですか?私は物事を正しく理解していますか、そして私のアプローチは賢明ですか?

7
Dave

ハッシュタグをドキュメント内の配列に格納します。

これがドキュメントを持つ利点です。単にネストすることができます。そして、この特定のケースでは、それは取るに足らないことです。

_{
    "_id": 123,
    "file": "c43a5f46-kitten.png",
    "description": "My kitten :3 #kittens #cute"
    "hashtags": ["kittens", "cute", "cat", "animals"]
}
_

(「同義」タグをいくつか追加しました。これは、他のドキュメントを検索することで自動的に行うことができます。)

これは、ドキュメント指向データベースの最も自然なソリューションです。

  • インデックスを追加するだけで、ハッシュタグによるドキュメントの検索は簡単です。ランダムなドキュメントのハッシュタグの挿入、更新、削除も簡単です。
  • このような操作を複数の「バッチ」に分割する必要があるため、大量の挿入、更新、削除は少しトリッキーですが、それでも管理しやすく、実装するのは難しくありません。
  • 複雑な集計は、標準の集計パイプラインまたはmap-reduceで実行できます

一方、リレーショナルスタイルを使用すると、アプリケーションコード内でSQL JOINを再発明するときに大きな問題が発生します。これは、MongoDB(など)を使用する際の最も一般的なアンチパターンの1つです。これは非常に典型的な疑似コードです:

_for (HashTag tag: mongodb.hashtags.find()) {
   for (Image img: mongodb.images.find(
           new Document("_id", new tag.getImageId()))) {
       // ...
   }
}
_

これは非効率的でスケーラブルではなく、単にホイールを再発明しています。これを使用すると、コード内のループが原因で、O(N*M)が複雑になる可能性があります。代わりに外部キーを使用したSQLを選択した場合、O(N*log(M))またはO(N+M)のようなものになります。

MongoDBにはテーブル(リレーション)と外部キーはありません。それらを発明しないでください。必要に応じて、代わりにSQLを使用してください。実際、データreallyがドキュメントで構成されていない限り、MongoDBの代わりにSQLを使用することを強くお勧めします。

ドキュメントの典型的な例は、構成、フォーム、そしておそらくユーザーセッションです。 「ランダム」な構造のため、これらは通常、テーブルにうまく適合しません。

3
scriptin