我一直在阅读MongoDB.我对聚合框架能力特别感兴趣.我正在考虑采用每月至少超过1000万行的多个数据集,并根据这些数据创建聚合.这是时间序列数据.
例.使用Oracle OLAP,您可以在第二个/每分钟级别加载数据,并将其汇总到数小时,数天,数周,数月,数周,数年等...只需定义您的维度并从那里开始.这非常有效.
到目前为止,我已经读过MongoDB可以使用它的map reduce功能来处理上述内容.可以实现Map reduce功能,以便逐步更新结果.这是有道理的,因为我将每周或每月加载新数据,我希望只需要处理正在加载的新数据.
我还读过MongoDB中的map reduce可能很慢.为了克服这个问题,我们的想法是使用便宜的商品硬件并将负载分散到多台机器上.
所以这是我的问题.
我提前感谢您的回复!
MongoDB处理地图的好坏(或多坏)在性能方面有何降低？你真的需要很多机器来获得可接受的性能吗？
MongoDB的Map/Reduce实现(从2.0.x开始)受限于对单线程SpiderMonkey JavaScript引擎的依赖.已经对v8 JavaScript引擎进行了一些实验,改进的并发性和性能是一个总体设计目标.
新的聚合框架是用C++编写的,具有更加可扩展的实现,包括"管道"方法.每个管道当前都是单线程的,但您可以并行运行不同的管道.聚合框架目前不会替换可以在Map/Reduce中完成的所有作业,但确实简化了许多常见用例.
第三种选择是通过MongoDB Hadoop Connector将MongoDB与Hadoop结合使用.Hadoop目前具有更具可扩展性的Map/Reduce实现,并且可以通过Hadoop Connector访问MongoDB集合以进行输入和输出.
在工作流方面,是否相对容易存储和合并map reduce生成的增量结果？
Map/Reduce有几个输出选项,包括将增量输出合并到先前的输出集合或返回结果内联(在内存中).
聚合框架提供了多少性能改进？
这实际上取决于Map/Reduce的复杂性.总体而言,聚合框架更快(在某些情况下,显着更快).您最好对自己的用例进行比较.
MongoDB 2.2尚未正式发布,但2.2rc0发布候选版自7月中旬开始提供.
聚合框架是否能够以与已存在的map/reduce功能类似的方式递增地存储结果.
聚合框架目前仅限于内联返回结果,因此您必须在返回结果时处理/显示结果.结果文档也仅限于MongoDB中的最大文档大小(目前为16MB).
有一个建议的$out管道命令(SERVER-3253),将来可能会添加更多的输出选项.
一些可能感兴趣的进一步阅读:
| 归档时间： |
|
| 查看次数： |
6395 次 |
| 最近记录： |