我使用的是MongoDb,其中的数据每分钟都会频繁地更改(更新)。这些数据是通过第三方应用程序接口通过超文本传输协议从MongoDB获取的。同样在API数据中,在返回它们之前对它们进行额外的累加,例如计算第N页的最近X天的视图总数。
不断增加的数据量(即很少有6 GB到14 GB的收集),在某些情况下会出现2-7秒的延迟,直到API返回聚合数据。提到的web应用程序的延迟是足够大的。我想以某种方式减少这些延迟。
在我描述的情况下使用了哪些模型?也许首先,我应该放弃HTTP API的想法,并将所有API逻辑转移到服务器端?
自己的想法,考虑因素:
也许应该有两个分离的数据“处理器”:
1)第一个"proccessor“应该完成所有聚合作业,并只写入第二个作业。
2)第二个“处理器”所有数据只返回,没有任何内部计算,聚合。
但在第一次写入第二个数据存储时也可能会出现bootleneck,应该有更新新旧数据的逻辑,这也会影响性能。
发布于 2014-11-16 20:41:49
第三方应用程序似乎做得不好,因此您应该放弃它。也许您可以通过重构数据模型或使用更好的聚合算法来解决问题。
Pre-calculations
使用批处理处理器和实时处理器听起来是个好主意,但我认为您还不需要它(见下文)。如果你仍然想实现它,你应该阅读关于Lambda architecture的文章,因为它修复了你的方法可能存在的一些问题。
这种架构方法试图通过使用批处理来提供全面准确的预计算视图来平衡延迟、吞吐量和容错能力,同时使用实时流处理来提供动态视图。两个视图输出可以在呈现之前连接。
数据模型()
你是说有很多更新,这是使用MongoDB时的危险信号。由于MongoDB的分布式特性,某些类型的更新可能会降低它的速度。例如,尝试插入子文档,而不是更新字段。但这不是一门精确的科学,因此如果不看数据模型,我就无能为力了。
聚合框架
数据库是为数据而生的,因此将数据聚合转移到MongoDB中。Map Reduce是slow on MongoDB,因此使用Aggregation Framework。
https://stackoverflow.com/questions/26956310
复制相似问题