用于 facebook 洞察的 CouchDB 文档设计

Question

我开始使用 CouchDB 从 Facebook Insights 和其他来源收集分析信息。我不确定文档的设计是否正确，希望更有经验的 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 个。

对文档的预期请求:

• 给定时间段内每个客户、每个源 ID、每个指标的值(value)总和
• 针对更复杂指标的专业 View

问题:

• 为了获得一些复杂指标(例如 page_wall_posts_source_unique)的分析，我们需要构建专门的 View (可能有很多)，我应该预料到 View 更新时间会出现问题吗？
• 使用数组作为时间戳是正确的决定还是使用 long 更好？
• 我应该使用一个设计文档还是将每个 View 放入一个新文档中？

Answer 1

我认为你最好不要将 CouchDb 用于此类目的。我认为您最大的目标之一是在数据中进行一些聚合，但这并不是 CouchDb 设计的主要目的。

实际上，CouchDb 有相当纯粹的聚合部分(正如我从它的实际经验中发现的那样，我在 3 个项目中实现了它)。当然，您可以像傻瓜文本搜索部分一样向其中添加 Lucene，它将扩展其查询功能，但无论如何，它会比您可能需要的功能要少。CouchDb 非常适合维基百科可能的项目，因为每次更新文档时，它都会创建具有新版本的文档，而您仍然拥有旧版本。这就是主要功能，看看您的项目，我看不出您想使用它。

此外，CouchDb 不适用于数百万个小文档。它更喜欢操纵平均数量的中型文档。但数以百万计的小文档对于 CouchDb View 系统来说并不是完美的事情。

所以我建议你选择你的主要目标并看看其他NoSQL解决方案，因为在NoSQL世界中没有一个解决方案可以满足所有目标，而是有针对所选目标的自己的解决方案，不像SQL，当你用一个来做所有事情的时候。乍一看，我认为 MongoDB 应该符合您的目标。

但是，无论如何，回答你的问题:1)认为是的，但这取决于有多少文档将被重新计算2)我更喜欢使用长值，因为当你有单个值时你可以查询它，如果你有不同值的数组，你就会遇到问题。使用像时间戳这样的长整型也是常见的做法。3)没什么大不了的。你可以做任何你想做的事。