7

Google App Engine でアプリを作成して、よりよく学習できるようにしています。データストアにデータを永続化しています。

このアプリケーションは、StackOverflow に似たモデルです。Story エンティティがあり、Comment エンティティのコレクションがあり、多くのユーザーに好かれたり嫌われたりする可能性があります。私が今これをモデル化している方法は次のとおりです。

class Story {
    Comment[] comments;
    ...
}

class Comment {
    User[] likes;
    User[] hates;
    ...
}

したがって、特定のストーリーをロードすると、すべてのコメントと、各コメントの好き嫌いの割合を一覧表示できます。特定のユーザーがコメントに投票したかどうかを追跡することもできます。

Comment エンティティ内のすべての実際のユーザーを遅延読み込みできると仮定していますが、それでも、これを行うためのより良い方法があると思います。

これは、何百ものコメントがあり、それぞれが何十万票もあるストーリーをどのように処理するのでしょうか?!

NoSQL でそのような概念をモデル化する一般的な方法は何ですか?

4

1 に答える 1

7

考えられる答え:

(1) これは何百ものコメントをどのように処理しますか?

UIでコメントを遅延ロードすることを提案することで、すでにこれに答えているようです。Mongo や CouchDB などのドキュメント データベースでは、データベースから取得したデータをページングするオプションがあることを知っています。「制限」や「スキップ」など。

何百ものコメントを保存するのはそれほど難しくないはずですし、クエリでコメントが遅くなるとは思いません。

(2) 数十万票をどう処理するか？

これを単純に前処理するのが最善の方法だと思います。ユーザーが何かに投票するとき、次の 2 つの操作を行うことを検討できます。1) コメントのいいね! カウンターを 1 つ増やします。2) ユーザー投票の記録を別の場所に書き込みます。

最初のステップは非常に迅速かつ簡単で、いいねの総数がすぐにユーザーに表示されます。

2 番目の操作 (ユーザーが何をしたか、どのコメントが好き/嫌いかを保存する) は少し遅くなるかもしれませんが、簡単に実行できます。

NoSQL では、データの正規化について心配する必要がないため、冗長な情報は問題ないことに注意してください。

(3) これらの概念をモデル化する一般的な方法は何ですか?

(2) で述べたように (そして私の経験からも)、モデル化の良い方法は、アイテムをすばやくインクリメントし、冗長な情報も保存することです。

Mongo や Couch などで結合するのは非常に難しいため、データをさまざまなドキュメントに何度も保存すると特に便利です。その情報は、それを必要とするエンティティの隣に保管することをお勧めします。

NoSQL データベースのもう 1 つの特徴は、一貫性のない状態が許容されることです。コメント セクションの好き嫌いの数を 1 つの数字にして、ユーザーの好き嫌いを見るときに別の数字にすることは問題ありません。

(あなたのモデルに関する唯一の注意点は、エンティティの分割です。従来の RDMS の場合のように分割する場合は、後で結合する必要があることを常に覚えておいてください! NoSQL では非常に困難な場合があります。)

于 2013-01-06T03:53:50.687 に答える