时间序列数据处理的角逐：MongoDB vs. Cassandra
2013-10-21 00:58 |
查看: 5801|
评论: 0
|
使用Cassandra替换MongoDB来管理时间序列后的飞跃 使用场景 MyDrive拥有一个基于AWS托管的数据处理平台，由Resque工作者负责。作为一个远程信息处理公司，我们需要处理非常多的时间序列数据，初始我们采用了MongoDB。作为初期方案，MongoDB最初定义就是临时性的选择。 MongoDB表现的也是相当不错，然而不同大小负载处理时间的不可预测性带来了很多困扰，同时也让数据处理管道的优化变得非常困难。基于 MongoDB的设计（大部分的关系型数据库同样如此），返回30个文档与返回300个文档的作业将触发不同的I/O负载，而返回30个文档的作业肯定要 比300个的快。当然不管是30还300，处理的速度都不是很快，即使使用了非常好的索引及非常合适的实例。 此后，我们不得不对MongoDB实例进行一定的纵向扩展；当然如果长期如此，将带来非常多的额外开销。 解决方案 从开始，目标就被锁定在Cassandra上，因为AboutUs 5.0之后的版本都使用了Cassandra。它已经向我们证明了强大的可靠性、可见性以及弹性。这些特色在整合了横向扩展之后，让Cassandra成为一个当之无愧的杀手级数据存储。 一般情况的数据流为写入数据>>读回>>修改>>写入>>再读取，这些操作被不同用户执行。虽然这不是Cassandra的设计理念，但是Cassandra却非常适合我们的查询方式。 Cassandra确实非常适合时间序列数据，因为可以周期性的将时间序列数据写入1列，然后通过部分字符串对比来查询一定时间范围内的数据。这样的话 使用列就比使用行更加的高效，而加载单行可以让你获得巨大的I/O性能。然后Cassandra必须至少读取一个数据，而随着数据持久化到磁盘的进行，所 有剩余的数据都将被读取。 我们使用时间戳作为ID的前半部分，这样的话就可以做任何时间段的范围查询——每行都体现出了一条数据，而列则体现了时间序列数据的一个周期。这样所有数据都可以通过键及起止时间查询。 鉴于我们工作负载的类型，使用MongoDB时，写操作的数量会严重影响到读的性能，而使用Cassandra就不会有这种情况发生。 前后对比 上面的突变显示大半年的性能，蓝线表示的是受数据存储性能影响的部分。很明显在做MongoDB优化及横向扩展硬件时性能的落差很大，然而这些对Cassandra毫无影响。 我们阶段化的关闭了MongoDB，开始是停止了对其写入，最后停止了在MongoDB上的读操作（在图片上使用了红色箭头标注），不过图片上没有显示的是在过渡到Cassandra后加入了大量的批处理作业。 |
免责声明：
除非特别声明，文章均为投稿或网络转载，仅代表作者观点，与大数据中国网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。如果本文内容有侵犯你的权益，请发送信息至ab12-120@163.com，我们会及时删除
上一篇：2013年10月数据库流行度排行榜
下一篇：数据库测试不可或缺，你知道吗？
最新评论
最新新闻
最新新闻
要闻推荐
要闻推荐
今日视点
今日视点
/1 
