1

私は自分のウェブサイトの通知システムをやっています。のような通知システムfacebook。またはstackoverflow。2つの問題があります。

  1. どのように db に保存しますか? ユーザードキュメントにすべての通知を保存できますか? または別のドキュメントに（monogdbはドキュメントのサイズに制限されていると思うので？）または、インテリジェントに保存しますか？(inc、または db の値 (true/false を参照) を使用して、洗練されたクエリを使用)

  2. ページに持ち込むにはどうすればよいですか？たとえば、inboxforのリンクをクリックstackoverflowすると、そのページにリダイレクトされます。しかし、私には、たとえばシステムがありmultipageます。100人の友達がいます。1ページに30個掲載されています。そのため、通知をクリックすると、適切なページを知ることができないため、リダイレクトできません (ユーザーを削除できます)。

どうもありがとうございました ！また、別のアイデアがあれば教えてください。ありがとう。

編集：

（私の英語でごめんなさい、私はフランス語です）

最初の問題については、自分の構造を選択する時が来るのを待たなければならないことに気付きました。私の通知は..少し複雑なので、感じに進んでください。

2番目に、私は問題を解決しました。私は次のように説明します: (分かりやすいので友人を例に挙げます。) 私は自分のデータを次のように保存しました:

{
  friends: [
    {_id: xxxxx, ts: xxxx},
    {_id: xxxxx, ts: xxxx}
  ]
}

すべての友達を表示するとします。1 ページあたり 30 人です。問題は次のとおりです。

  • すべての友達を表示したいとき、mongo を使用して並べ替えることができません。(ちょっと問題)
  • ユーザーをこのリスト (1 ページあたり 30) に導きたい場合は、特別な友達で、常に by を維持sortしtsます。ページがわかりません。ユニークな解決策は、すべてのドキュメントを取得することです。しかし、パフォーマンスが非常に悪いです。

だから、私はこのように保存します：

{
  friends: {
    xxxx: {ts:xxx},
    xxxx: {ts:xxx}
  }
}

スキップと制限を使用して、ドキュメントを並べ替えることができることを知っています。したがって、一部が必要な場合は、すべてのドキュメントを取得する必要はありません。

ページを知るには、ts に < または > の数を入力するだけです。たとえば、必要な友達の ts に > である 11 人の友達がいて、すべての友達の数を数えます (例: 50 人の友達)。 50 と 11 で、ページを推測できます。

この解決策は良いですか？- カウントが必要です - > または < の数を知るためのクエリで、友人がリストされているページを取得できます。the sort ts

カウントを使用する理由がわかりません。同じドキュメントに保存されていないため、必要です。

2編集：

このソリューションの問題は、query object（例： for doupdate objectmongo queryfriends.xxxxxx: {$exists:true}

ps: mongodbtsの代わりに使用する利点は何ですか? date私は使用していますが、ts保管すると思いますがdate、いいえts。

3 編集

のようにしSammayeます。別の文書に保管してください。見てみましょう: http://mongly.com/Multiple-Collections-Versus-Embedded-Documents/#1とhttp://openmymind.net/2012/1/30/MongoDB-Embedded-Documents-vs-Multiple-コレクション/

4

2 に答える 2

3

@Stennieはかなり完全な答えを出します。

しかし最近、私は自分のウェブサイトのために PHP で同様のことをしました。最初に理解しておくべきことは、あなたが通知システムを行っているのか、それともウォールを行っているのか (この 2 つは大きく異なります) です。

ページに持ち込むにはどうすればよいですか？たとえば、stackoverflow の受信トレイのリンクをクリックすると、そのページにリダイレクトされます。しかし、私には、たとえば複数ページのシステムがあります。100 人の友人がいます。1ページに30個掲載されています。そのため、通知をクリックすると、適切なページを知ることができないため、リダイレクトできません (ユーザーを削除できます)。

それはあまり上手な英語ではなく、読むと非常に混乱します。あなたがそれを拡張することができれば、人々はより良​​い答えができると確信しています.

通知システムの場合、通知オブジェクトの大規模なコレクションも機能することがわかりました。だから私は次のようなスキーマを持っていました:

{
    _id: {},
    to_user: ObjectId{},
    user_id: ObjectId{}, // Originating user
    custom_text: "has posted a new comment on your wall post",
    read: false,
    ts: MongoDate()
}

そして、これは文字通り、私が通知を作成しなければならない文書になります。ユーザーが通知を生成するアクションをコミットするたびに、DB に新しい行が書き込まれ、通知to_userが必要な各ユーザーが毎回入力されます。同じアクションをコミットしている複数のユーザーについては、実際にuser_idフィールドを のリストに変換するOjbectIdので、次のように言えます。

Sam, Dan and Mike all commented on your wall post

次に、ユーザーがts最後に見たものを行に格納してtsクエリを実行し、毎回最新の通知に対して範囲ベースのクエリを実行できるようにします。私の個人的な経験では、これはシャーディングとクエリに非常にうまく機能します。

それが役に立てば幸い、

于 2012-08-07T13:33:44.060 に答える
1

埋め込むかリンクするかは、MongoDB でのデータ モデリングに関する一般的な質問です。通知の数に制限がない場合は、これらを別のコレクションに保存することをお勧めします。

現在の 16Mb のドキュメント制限は、実際には他のいくつかの考慮事項ほど問題ではありません。

  • すべての通知を 1 つのドキュメントに含めることで発生する可能性があるパフォーマンスの問題は、急速に拡大するドキュメントをデータベース内でより頻繁に再配置する必要がある場合があることです (パディング ファクターを参照)。

  • 非常に短い時間内にドキュメントに複数の更新を適用したい場合があります (通知に「読み取り」フラグを設定するなど)。これは、同じドキュメントを更新するための競合が増えることを意味します (アトミック操作を参照)。

ページングを実装するには、範囲クエリまたはskip()と組み合わせてlimit()を使用できます。範囲クエリ (たとえば、 indexed に基づく) は、インデックスをより効果的に使用し、コレクションが大きくなるよりもパフォーマンスが向上します。notificationDateskip()

于 2012-08-07T02:20:20.817 に答える