我有一个关于 Couchbase 存储桶结构的快速问题。我正在运行 2.0 和 .net 客户端。我们即将推出一些东西，只想用“正确”的存储桶设计进行最终测试，但已经意识到这并不像我们想象的那么容易。
我们有什么：
基本上，我们目前在 1 个存储桶上有 11 个视图。然而，每个视图都被写入以不同的方式返回数据......
假设一个文档具有以下值（json doc）：Value1，Value2，Value3，... Value50
编写视图以便它发出多个结果，即：
emit ([1, Value1, Value2, Value3], null)
和
emit ([2, Value10, Value20, Value30], null)
然而，每个视图仅在 1 个“文档类型”上，即所有视图在开始时都有一个类似的 if 条件if(doc.docType = "Blah")
然后在 .net 代码中，当我们需要基于 value10、value20 和 value30 的文档时，通过让开始键和结束键以“2”开头，我们得到了我们想要的。
问题一：这个设计好吗？我见过很多这样的例子，但是我们在每个视图中都有 5-10 个不同的发射，所以 Couchbase 必须对其进行索引。与将每个人放在自己的视图中相比，这有什么性能问题吗？
其次，我们目前使用 1 个存储桶并收到超过 10 个视图的警告。所以我们要拆分桶。我们在想我们可以根据逻辑组将它分成大约 7-8 个不同的桶。我们意识到有 10 个桶的限制。
问题2：我在一个论坛的一篇文章中读到.net SDK一次只能连接到1个桶......这似乎是错误的。我的意思是关于 SO 的其他问题，即像这里他们使用了多个存储桶。我们将在 global.asax 中为每个存储桶“打开”连接，然后通过应用程序使用它。即client1.getview...然后client2.getview...这意味着 1 个页面 (.aspx) 将从 1 个存储桶进行 1 次调用，并从另一个存储桶调用另一个来填充页面。我快速尝试了一下它，它似乎工作......但只是想知道这是否是使用 CB 的可接受方式。我对将与 1 个逻辑应用程序相关的所有文档放在一个存储桶中的最佳实践建议感到困惑......：SI 会为每个文档制作“几乎”1 个存储桶（这样我们最多可以对其进行 10 次查看） ) 然后当我们达到 10 个桶的限制时，刚刚启动了一个新集群（注意：我们处于独特的位置，我们有很多未使用的硬盘，即一台服务器有 64gb 未使用/未分配的 ram，资源不是一个特别的问题。 ...性能是！）
我希望我的问题是有意义的。如果没有请告诉我
干杯
罗宾
注意：.net 4.0，Couchbase 2.0。我已经阅读了这两本手册，但仍不清楚上述内容。