我想使用data.table :: fwrite进行快速存储&以文本日志的形式检索状态。这些是通过移动应用程序更新的,该应用程序将管道工API调用用于R端点。移动应用程序可能每秒触发许多API,并且有可能在~0.5秒的间隙内由两个API修改同一行。由于每次API调用延迟1~2秒,我会避免数据库读写(R的fwrite可以在0.5秒内完成相同的工作,然后在后续调用中在不到20毫秒的时间内完成API)
我的问题是:
将为更高流量的情况进行fwrite / fread组合工作 我必须寻找锁定文件的方法,以避免腐败?是 有没有办法锁定文件进行读或写?
答案 0 :(得分:2)
将为更高流量的情况进行fwrite / fread组合工作,还是我必须寻找锁定文件的方法以避免损坏?
答案是"它取决于。"
如果您使用简单的托管模式托管应用,其中所有流量都会遇到相同的单例R流程,那么即使在高流量情况下您也可能会成功。这里需要注意的是,如果您在API中进行任何类型的内部流程分析,这将无法解决(或者如果data.table执行此操作;我不确定,我从未使用过它)
但是,如果您在其前面托管具有多个R进程和负载均衡器的应用程序,那么在尝试写入同一文件的多个进程中您将遇到麻烦。
扩展Plumber API的典型建议是通过添加更多R进程来水平扩展。因此,我鼓励您尝试找到一种设计,如果您最终希望并行运行多个Plumber流程,这些设计将继续有效。您可以考虑集中在远程数据库中,甚至可以使用SQLite在本地进行集中处理,只需确保将其配置为支持多个并发编写器(如果SQLite支持此操作,我不能100%确定)。
我肯定不会期望延迟1-2秒来击中DB。可能值得调查您的数据库硬件/软件或检查网络中是否存在任何延迟。您还可以查看pool package作为保持数据库连接打开并可用于API的方法。我猜这会大大减少数据库写入所需的时间。