3

Facebook インサイトやその他のソースから分析情報を収集するために、CouchDB の作業を開始しています。ドキュメントの適切な設計について確信が持てないので、より経験豊富な CouchDB ユーザーに見てもらい、大きな間違いを犯そうとしている場合は警告してもらいたいと思います。

{
"_id": "0b69a33807d4cb63680dbebc16000af5",
"_rev": "1-7c9916592c377e32cf83acf746a8647c",
//array of metrics, one element per facebook page, around 10 pages per document**
"metrics": [        
    {
        "sourceId": "210627525692699", //facebook page ID
        "source": "facebook",
        "values": {
           "page_likes": 53
           //many more other metrics, around 100
       }
   },
   {
       "sourceId": "354413697924499", // //facebook page ID
       "source": "facebook",
       "values": {
           "page_wall_posts_source_unique": {other: 0, composer: 1},
           "page_likes": 12
           //many more other metrics, around 100
       }
   }
],
"timestamp": [
   2012,
   10,
   15,
   10,
   0,
   0
],
"customerId": "71ff942f-9283-4916-ab84-4927bce09117"
}

予想されるドキュメント数: 毎時 +10 000、毎日 +240 000。

ドキュメントに対する予想される要求:

  • 特定の期間における顧客ごと、sourceId ごと、メトリックごとの値の合計
  • より複雑なメトリクスに特化したビュー

質問:

  • いくつかの複雑なメトリクス (page_wall_posts_source_unique など) の分析を取得するには、特殊なビュー (おそらくその多く) を作成する必要がありますが、ビューの更新時間の問題が予想されるでしょうか?
  • タイムスタンプに配列を使用するのは正しい決定ですか、それとも long を使用する方が良いですか?
  • 1 つの設計ドキュメントを使用するべきですか、それともすべてのビューを新しいドキュメントに入れる必要がありますか?
4

2 に答える 2

0

返信ありがとうございます。

Ph0en1x さん、部分的には同意します。CouchDB は明白な選択ではありませんでしたが、他のオプションについては確信が持てません。今のところ、CouchDB に固執します。

とにかく、複数のソースから収集した回答は次のとおりです。

1）明らかに、それはドキュメントの数に依存します。しかし、ドキュメントが小さいと、その可能性が高くなります。

2）両方のアプローチが機能します。タイムスタンプはもう少し普遍的です。

3) 1 つのドキュメント内のビューが多いほど、それらのビューがより頻繁に再インデックスされる可能性が高くなります。そのため、1 つのドキュメントのビュー数をできるだけ最小限に抑えようとしています。

于 2012-12-09T19:28:06.640 に答える
0

そのような目的で CouchDb を使用しない方がよいと思います。あなたの最大の目標の 1 つは、データ全体を集計することです。これは、CouchDb が設計した主な目的ではありません。

実際、CouchDb には集約部分の非常に純粋なクエリがあります (実際の経験からわかったように、3 つのプロジェクトで実装しています)。愚かなテキスト検索部分のように Lucene を追加すると、そのクエリ機能が拡張されますが、いずれにせよ、おそらく必要な数よりも少なくなります。CouchDb は、Wikipedia の可能性のあるプロジェクトに最適です。ドキュメントを更新するたびに、新しいリビジョンのドキュメントが作成され、古いバージョンがまだ残っているためです。それは主な機能であり、あなたのプロジェクトを見ていると、あなたがそれを使いたいとは思いません。

また、CouchDb は何百万もの小さなドキュメントには対応していません。中サイズのドキュメントの平均的な量で操作することを好みます。しかし、何百万もの小さなドキュメントは、CouchDb ビュー システムにとって完璧なものではありません。

そのため、主な目標を選択し、他の NoSQL ソリューションを検討することをお勧めします。なぜなら、NoSQL の世界では、すべての目標に対する 1 つのソリューションは存在しないためです。代わりに、選択した目標に対する独自のソリューションがあります。SQL の場合とは異なります。すべてのものに1つ。一見すると、MongoDB はあなたの目標に合うはずだと思います。

しかし、とにかく、あなたの質問に答えてください: 1) はいと思いますが、それは再計算するドキュメントの数に依存します 2) 私は長い値を使用することを好みます。値が異なると、問題が発生します。また、タイムスタンプのような long を使用するのも一般的な方法です。3) 大したことはありません。好きなようにできます。

于 2012-12-08T17:41:58.207 に答える