RethinkDB改变性能：建筑建议？

Question

我正在用RethinkDB构建一个应用程序，并且即将切换到使用换入。但我正面临着建筑选择，我想得到一些建议。

我的应用程序当前在用户登录时加载了来自多个表的所有用户数据（将它全部发送到前端），然后处理来自前端的请求，更改数据库以及准备和发送更改的项目给用户。我想将它切换到换刀。我看到它的方式有两种选择：

1. 为每个表设置一个换页进纸。按登录到特定服务器的用户进行过滤，并手动将更改分发给用户。这些换货从未关闭，例如他们有我的服务器的一生。
2. 当用户登录时，为该用户设置单个换货订单，仅针对该用户的数据（使用带辅助索引的getAll）。保持与当前登录用户一样多的更换进度。用户注销时关闭它们。

解决方案＃1有一个很大的缺点：RethinkDB换刀没有时间（或版本号）的概念，就像Kafka所做的那样。这意味着无法a）加载初始数据，并且b）获得自初始加载后发生的更改。有一个时间窗口可能会导致更改丢失：在初始数据加载（a）和更改加载设置（b）之间。我觉得这很令人担忧。

解决方案＃2似乎更好，因为includeInitial可用于获取初始数据，然后获得后续更改而不会中断。我不得不处理初始加载性能（加载所有数据的单个转储比处理数千次更新更快），但似乎更“正确”。但是缩放呢？我计划每台服务器处理多达1k个用户 - RethinkDB准备处理数千个更改进程，每个进程本质上都是一个getAll查询？这些换货的实际活动将非常低，这只是我担心的数字。

的RethinkDB手册是有点简洁约changefeed缩放，说：

Changefeeds表现良好，因为它们比例的，尽管它们创建按比例额外群集内消息给服务器的与每个打开进料连接数写。

解决方案＃2创建了更多的提要，但具有打开提要连接的服务器的数量实际上对于这两种解决方案都是相同的。和“换刀进展顺利”，不足以继续:-)

我也有兴趣知道什么是处理服务器重新启动/升级和断开连接的推荐做法。我看到它的方式，如果RethinkDB发生任何事情，客户端必须在重新连接后执行完整的数据加载（使用includeInitial），因为无法知道在停机期间丢失了哪些更改。那是人们在做什么？

Answer 1

如果RethinkDB在合理的硬件上，它应该能够处理数以千计的更改。在这种情况下，有些人要做的工作是降低网络负载，因为他们将代理节点放在应用程序服务器所在的同一台机器上，并连接到该节点上，因为代理节点有足够的知识来重复删除通过网络传入的换货信息，并且因为它会占用大量CPU /内存的负载。

目前，从碰撞中恢复的唯一方法是使用includeInitial重新启动换卡。有计划在将来添加写入时间戳，但在这种情况下处理删除操作很复杂。