关于数据提取方法的一个问题，
第一种方法：
让说，我有两个文件
userdoc1
{
“status”:“pending”
“usertype”:“VIP”
“userid”:“123”
}
对于上述文件，让说我的documentid是状态::用户类型[我只想澄清，该文件ID将在我们的情况下，唯一]
userdoc2
{
“userid”:“123”,
“fname”:“abc”,
“lname”:“xyz”,
“age”:20;
“address”:“asdf”
}
对于userdoc2，让说的用户ID是我documentid
如果我做一个GET操作，我会继续这样的（这里的想法是基于文件ID来获取数据）
select userid from userdoc1 with key “pending::VIP”;
接着
select * from userdoc2 with key “123”;
第二条本办法：
我只有一个文件
userdoc
{
“status”:“pending”
“usertype”:“VIP”
“userid”:“123”
“fname”:“abc”,
“lname”:“xyz”,
“age”:20;
“address”:“asdf”
}
在这里，documentid是“状态::用户类型”，我们手头上的用户ID二级指标
在这里，如果得到这样的数据（这里的想法是基于二级索引取数据）：
SELECT * FROM userdoc其中userd =“123”;
能否请您解释一下哪一种方法能保证较高的读取性能假设在一个集群和XDCR等因素的影响与节点100高负荷的数据？
选项1将不得不从客户端2次往返于服务器运行两个廉价的查询。选项2将不得不从客户机到服务器的一次往返运行一个稍贵的查询。
我不能没有测量完全有信心，但我敢打赌我的钱选项2.往返费用可以是一个婊子。
一定要对用户标识使用合适的索引选项2和使用准备好的查询与用户ID作为参数。这应该是最快的选项。
主导因素（如约翰·拉尔森说，在他的回答）很可能是往返次数。您的第一个解决方案将具有从应用程序到群二往返，而第二个将只有一个。有一些潜在的细微差别，虽然。
要注意的重要一点是键/值检索总是将是最快的。这些请求将直接进入运行数据服务节点。与Couchbase，客户端直接访问包含该节点的数据，而不是通过主 - 从布置。换句话说，你可以完成一个单次往返只涉及有实际的文档数据节点A的K / V请求。
使用你的第一种方法，可以避开N1QL完全。只需要对id状态::用户类型直ķ/ V get，拔出用户ID，然后用它做第二文档的get。你甚至可以使用的子文档API只返回该用户ID。
第二种方法将涉及的索引和查询N1QL，所以你可能打起来到集群中的三台不同的机器。这是否会更快取决于拓扑。如果您的应用程序一起运行在群集（即：网络吞吐量/延迟类似于在群集内的时间），我觉得K / V方案实际上可能会更快。如果从应用程序的网络延迟到集群较长，第二种方式是有可能更快。
有一个进一步审议。如果整个结果被“覆盖”您为查询创建索引（这意味着你存储在你的索引关心文件的所有部分），那么响应可以通过索引服务提供完全。这将削减N1QL方式向下击球查询服务和索引服务，这会更快。
要进入更详细一点，你的问题涉及到数据，索引和查询。 Couchbase拆分这些功能集成到不同的服务，这意味着你可以独立地扩展容量每一个。这也是为什么你可以打与N1QL查询三种不同的机器。
这也将取决于数据负载的性质。举例来说，如果它的数据读取的与写沉重。写重与指数将意味着索引更新，而读重不会。同样，XDCR将读与写的影响。