我正在使用RethinkDB构建应用程序，我即将切换到使用更改源。但我面临建筑选择，我想得到一些建议。
我的应用程序当前从用户登录的几个表中加载所有用户数据（将所有用户数据发送到前端），然后处理来自前端的请求，更改数据库，准备并向用户发送更改的项目。我想将其转换为更改源。我看到它的方式，我有两个选择：
getAll）。保持与当前登录用户一样多的更改源。用户退出时关闭它们。解决方案＃1有一个很大的缺点：RethinkDB更改源没有时间（或版本号）的概念，例如Kafka。这意味着没有办法a）加载初始数据，b）获得自初始加载以来发生的变化。有一个时间窗口可能会丢失更改：在初始数据加载（a）和更改源设置的时刻（b）之间。我觉得这很令人担忧。
解决方案＃2似乎更好，因为includeInitial可用于获取初始数据，然后不间断地获得后续更改。我必须处理初始加载性能（加载所有数据的单个转储比处理数千次更新更快），但似乎更多＆＃34;正确＆＃34;。但是缩放呢？我计划每台服务器处理多达1k个用户--RethinkDB是否已准备好处理数千个更改源，每个基本上都是getAll个查询？这些更改过程中的实际活动将非常低，这只是我担心的数字。
RethinkDB手册对更改进度缩放有点简洁，并说：
更改源在扩展时表现良好，但它们会在每次写入时创建额外的群集内消息与开放源连接的服务器数量成比例。
解决方案＃2创建了更多的Feed，但是对于两个解决方案，具有开放式Feed连接的服务器数量实际上是相同的。并且＆＃34;改变饲料随着它们的扩展而表现良好。还不足以继续下去： - ）
我也有兴趣了解处理服务器重启/升级和断开连接的推荐做法。我看到它的方式，如果RethinkDB发生任何事情，客户端必须在重新连接后执行完整数据加载（使用includeInitial），因为无法知道在停机期间丢失了哪些更改。那是人们做的吗？
答案 0 :(得分：7)
如果在合理的硬件上，RethinkDB应该可以处理成千上万的更改。在这种情况下，有些人要做的一件事是降低网络负载，他们将代理节点放在与他们的应用服务器相同的机器上，并连接到那个，因为代理节点知道足以重复删除通过网络传入的更改馈送消息，以及因为它会占用主群集的大量CPU /内存负载。
目前，从崩溃中恢复的唯一方法是使用includeInitial重新启动更改源。有计划在将来添加写时间戳，但在这种情况下处理删除很复杂。