Fatal编程技术网
  • couchbase/
  • 使用Couchbase SDK与同步网关API

使用Couchbase SDK与同步网关API

couchbase

使用Couchbase SDK与同步网关API,couchbase,couchbase-sync-gateway,Couchbase,Couchbase Sync Gateway,我有一个couchbase（服务器、同步网关和lite）的完整部署，并且有一个API、移动应用程序和web应用程序都在使用它 它工作得很好，但我想知道使用同步网关API是否比Couchbase SDK有任何优势？具体地说，我想知道Sync网关是否比SDK更好地处理更多的操作，SDK可能是一个内部队列/缓存系统，但似乎找不到这方面的明确文档 目前，API使用的是C#Couchbase SDK，我们很少使用SyncGateway（仅用于同步移动应用程序） 简单的回答是，对于后端操作，Couchbas

我有一个couchbase（服务器、同步网关和lite）的完整部署，并且有一个API、移动应用程序和web应用程序都在使用它

它工作得很好，但我想知道使用同步网关API是否比Couchbase SDK有任何优势？具体地说，我想知道Sync网关是否比SDK更好地处理更多的操作，SDK可能是一个内部队列/缓存系统，但似乎找不到这方面的明确文档

目前，API使用的是C#Couchbase SDK，我们很少使用SyncGateway（仅用于同步移动应用程序）

简单的回答是，对于后端操作，Couchbase SDK是您的选择，并且性能会更好。同步网关旨在供移动客户端使用，只有少数例外（*）

批量/批处理操作 在使用JavaCouchbaseSDK和AsyncBucket（）的批量操作进行的性能测试中，我每秒更新了多达8000个文档。在.Net中，您也可以执行批处理操作（）

同步网关还支持批量操作，但速度要慢得多，因为它依赖REST API，并且需要您提供一个来自要更新的每个文档的前一版本的修订版。这通常会导致后端在执行PUT之前必须先执行GET。另外，请记住，同步网关不是一个存储单元。它只是Couchbase的代理，根据为每个用户注册的通道管理移动客户端对数据段的访问，并将其所有元数据文档写入Couchbase服务器bucket，包括通道索引、用户注册、文档修订和视图

质疑 视图被编入索引，因此用于查询大型数据，它们的响应速度可能非常快。每当文档发生更改时，所有视图的映射功能都有机会对其进行映射。但是，当通过同步网关REST API创建视图时，会向映射函数中添加一些代码来处理用户通道/权限，使其比直接在Couchbase管理UI中创建的普通代码慢。当您有分层数据时，使用startKey/endKey参数使用复合键查询视图非常强大，但此功能和reduce函数的使用不适用于移动客户端

当N1QL查询利用Couchbase索引时，N1QL也可以非常快

笔记 （*）该规则的一个例外是，当您想删除文档并在手机上反映出来时。删除操作会留下一个带有
\u deleted:true
属性的空文档，并且只能通过同步网关完成。下次移动设备同步并发现此提示时，它将从本地存储中删除该文档。您还可以通过PUT操作使用set此属性，此时您还可以添加
\u exp:“2019-12-12T00:00:00.000Z”
属性，以便在将来的日期对文档执行编程清除，从而使服务器也变得干净。然而，仅仅通过同步网关清除文档就相当于通过Couchbase SDK删除文档，这不会反映在移动设备上

注意：在同步网关1.5和Couchbase 5.0之前，所有后端操作都必须直接在同步网关中完成，以便同步网关和移动客户端能够检测到这些更改。自从引入共享_bucket_访问选项以来，情况发生了变化。更多信息。首先，一些相关的背景信息：

需要同步到Couchbase Lite（CBL）客户端的每个文档都需要由同步网关（SGW）处理。无论文档是通过SGWAPI编写的，还是通过服务器写入（N1QL或SDK）输入的，都是如此。后一种情况称为“导入处理”，其中SGW通过DCP提要读取写入bucket（通过N1QL）的文档。然后SGW处理该文档，并使用相关的同步元数据将其写回bucket

先决条件：

为了让SGW导入通过N1QL/SDK直接编写的文档，您必须启用“共享存储桶访问”和导入处理，如前所述

非移动文档：

如果您的文档永远不会同步到CBL客户端，那么选择是显而易见的。请使用服务器SDK或N1QL

移动文档（要同步到CBL客户端的文档）：

假设您在SGW2.x上与CBL2.x客户端同步

如果您在服务器端编写了需要与CBL客户端同步的文档，那么请考虑下面的

  • 服务器端写入速率：
如果您看到服务器端的写入速度持续显著超过1.5K/s（比方说5K/s），那么您应该选择SGW API路线。虽然通过服务器N1QL查询进行批量更新很容易，但请记住，SGW仍然需要保持并执行导入处理（在后台讨论）

这意味着，如果您通过SDK/N1QL进行大容量更新，则必须对其进行速率限制，以便SGW能够跟上（通过SDK进行批量更新）

这样说，重要的是要考虑到如果SGW不能跟上DCP feed上的写吞吐量，那么不管写入如何发生（SGW API或N1QL）

，都会导致延迟。 若您在服务器上的持续写入速率并不例外，那个么请使用N1QL

  • 删除处理：
没关系。在共享bucket访问下，通过SDK或SGW API进行的删除将导致墓碑。请阅读更多信息

  • SGW特定配置：
当然，如果您正在处理特定于SGW的配置，创建SGW用户、角色，那么您将使用SGWAPI来实现这一点

  • 冲突处理：
在2.x中，这无关紧要。冲突在CBL端处理

挑战SGW API