NoSql大比拼--方案

前端之家收集整理的这篇文章主要介绍了NoSql大比拼--方案前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

NoSQL数据库大比拼: Cassandra,HBase,MongoDB,Riak一文提供了这四个NoSQL数据库修改等操作的不同性能比较。是最新的一份全面报告。

该比较是以延迟和吞吐量为衡量指标,吞吐量越大,造成的延迟就越大,这是一对矛盾,那么哪个NoSQL数据库能够在这对矛盾中做得更好呢?

首先是大量数据Load加载,一亿的数据加载比较如下:



横坐标是吞吐量,纵坐标是延迟,吞吐量越大,延迟越小越好,图中HBase获胜。

修改为主

修改比例: 50/50,这是模拟典型电子商务应用的操作比例,重量修改操作下四个数据库的写能力比较图如下:


HBase 和 Cassandra 写性能方面遥遥领先。

HBase客户端配置为 AutoFlush关闭. 修改聚合在客户端buffer中,一旦缓冲满了,将异步追加写flushed,为了加速服务器端修改处理, 启用延迟日志 flush。在flush阶段WAL edits保存在内存中。

Cassandra写可变数据到commit日志,然后内存in-memory Memtable表更新,这将会慢些,但是比HBase的延迟日志flush将更安全。

下图是各个数据库在读方面能力的性能比较图:



HBase 和 Cassandra不但写能力领域,在电子商务读写1:1情况下,读能力也很强,据此可以认为HBase 和 Cassandra适合读修改1:1的应用场合。
读为主

Workload B组的比较是以读为主的场景下,95%读,5%写,适合CMS内容管理等系统,下图是四个数据库在这种情况下读性能比较


传统MysqL在碎片分区下Sharded MysqL性能最好,MongoDB因为内存映射文件(Memory-mapped files )类型的缓存名列第二, 内存映射文件用户所有MongoDB的磁盘I/O; Cassandra的主键key和列缓存能够有利于频繁读取数据,特别是0.8版本增加了off-heap(超越JVM内部Heap)列缓存特性,显示它有相当的读取性能。主键key缓存保存每一列所有的Key在。因此不再需要查询SSTable索引文件,得益于行缓存,也不必从SSTable中读取行数据;而HBase的随机读取性能就慢了。

那么在以读为主的操作中,四个数据库修改性能如何?
还是HBase和Cassandra获胜。看来这两个数据库写能力一直很坚强。 纯粹读-只读

只读情况下,sharded MysqL因为缓存和B-tree索引获得胜利。


扫描Scan

按顺序扫描记录,随机选取一个记录key. 扫描记录数也是在1-100随机选择。Read/update/insert比例: 95/0/5


以插入数据为主

Insert-mostly以插入数据为主方式,比例Insert/Read: 90/10


HBase性能最好:高吞吐量低延迟。

总结:根据自己业务应用系统的读写频繁度选择相应的NoSQL

命令查询的责任分离Command Query Responsibility Segregation (简称CQRS)模式是一种架构体系模式,能够使改变模型的状态的命令和模型状态的查询实现分离。这属于DDD应用领域的一个模式,主要解决DDD在数据库报表输出上处理方式。

  Greg Young在infoQ的采访中“State Transitions in Domain-Driven Design”谈到了CQRS,Greg 解释了把领域模型分为两种:状态校验,以及状态转换,维持当前状态的一个视图


在客户端就将数据的新增修改删除等动作和查询进行分离,前者称为Command,走Command bus进入Domain对模型进行操作,而查询则从另外一条路径直接对数据进行操作,比如报表输出等。

  当一个Command进来时,从仓储Repository加载一个聚合aggregate对象群,然后执行方法和行为。这样,会激发聚合对象群产生一个事件,这个事件可以分发给仓储Repository,或者分发给Event Bus事件总线,比如JavaEE的消息总线等等。事件总线将再次激活所有监听本事件的处理者。当然一些处理者会执行其他聚合对象群的操作,包括数据库的更新。

  因为领域对象操作和数据库保存持久这两个动作分离,因此,数据表结构可以和领域对象松耦合(JiveJdon源码可展示领域对象和数据表不再是一对一对应依赖,这也是使用Hibernate 等ORM框架容易造成的问题),你可以优化数据表结构专门用于查询

  再者,由于事件驱动了领域模型的状态改变,如果你记录这些事件audit ,将可以将一些用户操作进行回放,从而找到重要状态改变的轨迹,而不是单纯只能依靠数据表字段显示当前状态,至于这些当前状态怎么来的,你无法得知。当你从数据库中获得聚合体时,可以将相关的事件也取出来,这些叫Event Sourcing,事件源虽然没有何时何地发生,但是可以清楚说明用户操作的意图。

  虽然这种架构有些复杂,但是好处却很多,主要的是实现透明的分布式处理Transparent distributed processing,当使用事件作为状态改变的引擎时,你可以通过实现多任务并发处理,比如通过JVM并行计算或事件消息总线机制,事件能够很容易序列化,并在多个服务器之间传送,(EJB提倡贫血失血模型,实际就是为解决胖模型在多个服务器之间传送时序列化耗费性能,现在我们不序列化模型,而是改变模型数据的事件)。

原文链接:https://www.f2er.com/nosql/204329.html

猜你在找的NoSQL相关文章