Couchdb 视图和许多(数千种)文档类型
我正在研究 CouchDB,并且正在想象最坏的情况:
对于每种文档类型,我需要 3 个视图,而该应用程序可以生成 10 万种文档类型。
“文档类型”是指文档的结构。
插入新文档后,couchdb 会进行 3*10K 调用以查看搜索正确文档类型的函数。
这是真的吗? 有没有比为每种文档类型创建数据库更聪明的解决方案?
文档示例(假设没有文档具有相同的结构,在本示例中数据位于不同的键下):
[
{
"_id":"1251888780.0",
"_rev":"1-582726400f3c9437259adef7888cbac0"
"type":'sensorX',
"value":{"ValueA":"123"}
},
{
"_id":"1251888780.0",
"_rev":"1-37259adef7888cbac06400f3c9458272"
"type":'sensorY',
"value":{"valueB":"456"}
},
{
"_id":"1251888780.0",
"_rev":"1-6400f3c945827237259adef7888cbac0"
"type":'sensorZ',
"value":{"valueC":"789"}
},
]
视图示例(在本示例中每种文档类型只有一个)
"views":
{
"sensorX": {
"map": "function(doc) { if (doc.type == 'sensorX') emit(null, doc.valueA) }"
},
"sensorY": {
"map": "function(doc) { if (doc.type == 'sensorY') emit(null, doc.valueB) }"
},
"sensorZ": {
"map": "function(doc) { if (doc.type == 'sensorZ') emit(null, doc.valueC) }"
},
}
I'm studing CouchDB and I'm picturing a worst case scenario:
for each document type I need 3 view and this application can generate 10 thousands of document types.
With "document type" I mean the structure of the document.
After insertion of a new document, couchdb make 3*10K calls to view functions searching for right document type.
Is this true?
Is there a smart solution than make a database for each doc type?
Document example (assume that none documents have the same structure, in this example data is under different keys):
[
{
"_id":"1251888780.0",
"_rev":"1-582726400f3c9437259adef7888cbac0"
"type":'sensorX',
"value":{"ValueA":"123"}
},
{
"_id":"1251888780.0",
"_rev":"1-37259adef7888cbac06400f3c9458272"
"type":'sensorY',
"value":{"valueB":"456"}
},
{
"_id":"1251888780.0",
"_rev":"1-6400f3c945827237259adef7888cbac0"
"type":'sensorZ',
"value":{"valueC":"789"}
},
]
Views example (in this example only one per doc type)
"views":
{
"sensorX": {
"map": "function(doc) { if (doc.type == 'sensorX') emit(null, doc.valueA) }"
},
"sensorY": {
"map": "function(doc) { if (doc.type == 'sensorY') emit(null, doc.valueB) }"
},
"sensorZ": {
"map": "function(doc) { if (doc.type == 'sensorZ') emit(null, doc.valueC) }"
},
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
当您第一次请求每个新文档的视图时,CouchDB 中的
map()
函数的结果会被缓存。让我用一个简单的例子来解释一下。您向 CouchDB 插入 100 个文档
您请求视图。现在,
map()
函数针对这 100 个文档运行,并缓存结果。您再次请求查看。数据是从索引视图数据中读取的,无需重新映射文档。
您又插入了 50 个文档
您请求查看。 50 个新文档被映射并与旧的 100 个文档合并到索引中。
我希望这是有道理的。如果您担心当用户请求视图并且添加了许多新文档时会产生很大的负载,您可以考虑让导入过程调用视图(以重新映射新文档)并让用户请求对于视图包括
stale=ok
。CouchDB 书籍 是有关 CouchDB 的非常好的信息资源。
The results of the
map()
function in CouchDB is cached the first time you request the view for each new document. Let me explain with a quick illustration.You insert 100 documents to CouchDB
You request the view. Now the 100 documents have the
map()
function run against them and the results cached.You request the view again. The data is read from the indexed view data, no documents have to be re-mapped.
You insert 50 more documents
You request the view. The 50 new documents are mapped and merged into the index with the old 100 documents.
I hope that makes sense. If you're concerned about a big load being generated when a user requests a view and lots of new documents have been added you could look at having your import process call the view (to re-map the new documents) and have the user request for the view include
stale=ok
.The CouchDB book is a really good resource for information on CouchDB.
詹姆斯有一个很好的答案。
看起来您在问这个问题“X 类型的文档的值是什么?”
我认为您可以通过一个视图来做到这一点:
现在,获取
sensorY
的所有值code>,您使用参数?key="sensorX"
查询/db/_design/app/_view/sensor_value
。 CouchDB 将显示sensorX 的所有值,这些值来自文档的value.valueA
字段。 (对于sensorY,它来自value.valueB
等)面向未来
如果您将来可能有新文档类型,那么更通用的东西可能会更好
:非常简单,任何具有
type
和value
字段的文档都可以工作。接下来,要从视图中获取valueA
、valueB
等,只需在客户端执行此操作即可。如果无法使用客户端,请使用
_list
函数。显然,使用
send()
来发送您喜欢的客户端格式(例如 JSON)。James has a great answer.
It looks like you are asking the question "what are the values of documents of type X?"
I think you can do that with one view:
Now, to get all values for
sensorY
, you query/db/_design/app/_view/sensor_value
with a parameter?key="sensorX"
. CouchDB will show all values for sensorX, which come from the document'svalue.valueA
field. (For sensorY, it comes fromvalue.valueB
, etc.)Future-proofing
If you might have new document types in the future, something more general might be better:
That is very simple, and any document will work if it has a
type
andvalue
field. Next, to get thevalueA
,valueB
, etc. from the view, just do that on the client side.If using the client is impossible, use a
_list
function.Obviously use
send()
to send whichever format you prefer for the client (such as JSON).