Question

我遇到的情况是，每个新输入的数据集都会提示重新创建多个视图。我目前正在尝试CouchDB，但希望得到有关其他数据库解决方案的反馈。

描述：该表包含许多字段，包括一个对象数组。

视图需要根据某些条件扫描这些对象数组（例如obj-field answer = yes）。

每当创建新的表条目时，这会为每个视图创建一些密集的视图重新创建..

Original Data:
1: [A, B, C, D, ..]
2: [A, B, C, D, ..]
3: [A, B, C, D, ..]
..

View 3)
A: [1, 2, 3, ..]
B: [2, 4, 6, ..]
C: [1, 5, 6, ..]
..

View 4)
A: [2, 3, 7]
C: [3, 5, 8]
..

原始数据和视图都以类似的规律进行查询。

更详细的解释：

有一个用例很难在mysql中处理，因为表变长了。所以我在考虑实现No-sql。

用户对作为对象数组的标准化问题提供反馈 - 通常每个作者对一个目标用户的反馈约为60个对象。这些对象基本上是标准化的答案（例如是，不，可能），带有强度指示（例如，一点点，有点，非常）。

此外，一些人口统计和关系数据（年龄，地点，位置等）也会出现。

虽然保存这些数据是直截了当的 - 但问题是如何优化反馈的分析部分，这需要在每次反馈时更新视图。

视图不仅汇总了反馈对象，还重新排序了反馈数组。目前我这个客户端为每个字段运行for-loops - 但是我担心一旦收到太多反馈，这将会太慢。这适用于移动应用，因此资源有限。

A）我的问题是..哪个no-sql数据库最适合这个（我目前正在试用couchDB）。

B）我也想知道＆＃34;观点的效率＆＃34; - 特别是当feedbackObj相关的视图需要在添加新数据（参见3）和4）后完全更新。

C）或者我应该更多地关注手动实施的缓存解决方案服务器或客户端？

author_id,
target_id,
[
    feedbackObj: 
    {
         question,
        answer: yes/no/maybe,
        intensity: a-little, somewhat, very,
        ...
    }
]

1）作者对target_user = 1和answer_type的反馈：（例如，对于target_user = 1的所有反馈，其中answer = yes）

author_id : [ feedbackObj-1, feedbackObj4, .. ]
author_id : [ feedbackObj-3, feedbackObj9, .. ]

2）仅返回用＆＃34; yes＆＃34;回答的feedbackObjects。对于某个target_user = 1，按author_id

排序

author_id : [ feedbackObj-1, feedbackObj2, .. ]
author_id : [ feedbackObj-1, feedbackObj2, .. ]

3）仅返回用＆＃34; yes＆＃34;回答的feedbackObjects。对于某个target_user = 1，按feedbackObj排序（因为问题是标准化的）

feedbackObj-1: [ authorID-1, authorID-3, ..]
feedbackObj-2: [ authorID-1, authorID-10, ..]

...这里存储的数据需要经过大量的处理。

4）例如feedbackObj-1-Value（例如所有是）和强度指标（有点，非常，有点）的反馈（对于target_user = 1）

feedbackObj-1: [ authorID-1, authorID-3, ..]
feedbackObj-2: [ authorID-1, authorID-10, ..]

Answer 1

A）了解您需要访问数据的频率至关重要。我认为您必须考虑优化数据的不同方法。

chouchdb中不经常访问意味着当您查看视图时，您将在所有更改中触发重新索引。如果不需要最新结果，您可以使用update-after调用陈旧视图。如果您这样做，您可能还希望将文档保存在不同的

中

Couchbase做了相反的事情并更新了我认为的文档更新时的视图索引。

2）对于couchdb来说，通过扩展数组来减少并不是最佳的 - 减少意味着提供简短的响应。但是如果你只返回每个文档的密钥对，那么couchdb会非常快。返回像[feedbackObj_1，authorId-1]这样的密钥然后可以减少到只有一个计数。如果您需要FeedbackObj-1的响应，您可以使用startkey和endkey来获取所有作者ID对象。

因此，您有一个看似feedbackbyauthor的视图：

function(doc){
    // you may need to do some filtering to just emit on feedback documents here
    emit([doc.author_id, doc.feedback_id], null)
}

然后，您可以使用参数startkey=[AUTHOR_ID,]&endkey=[AUTHOR_ID, {}]&include_docs=true

进行查询

请参阅here。

3）关于缓存解决方案，请检查陈旧视图。这可能会帮助您控制实际需要重新索引的次数。

<强>更新

考虑到吞吐量，我预计Couchbase更适合您的需求。我没有那么多地使用它，但它是very similar in it's map reduce logic to couchdb。我添加了一个示例，说明如何在couchdb中编写用例视图。

什么NO-SQL解决方案针对频繁的视图更新进行了优化娱乐？

1 个答案: