MongoDBDB、Cassandra和 Mysql对比

1.为什么是Nosql?

1.1 Nosql在大数据处理相对于关系型数据库具有优势

1.1.1

                 1. 低延迟的读写速度: 大量数据的写入和读取可达 Wops/sec的速率

2. 海量的数据和流量:可以支持高效的查询,应对高并发请求。

3. 大规模集群的管理:分布式应用能更简单的部署和管理;

4. 关系型数据库由于存在类似Join这样多表查询机制,使得数据库在扩展方面很艰难;

5. 关系型数据库读写慢:这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂,使得其非常容易发生死锁等的并发问题,所以导致其读写速度下滑非常严重;

2.原理及区别

2.1. Mysql

在不同的引擎上有不同 的存储方式。

查询语句是使用传统的sql语句,拥有较为成熟的体系,成熟度很高。

mysql采用table和结构化的sql语句来处理数据,在mysql中需要预先定义数据结构schema,并定义table中数据字段的关系。

在mysql中,相关信息可以保存在不同的表中,通过join的形式来保持彼此关联

通用数据库应用广泛,不必多说。缺点就是在海量数据处理的时候效率会显著变慢

2.2 MongoDB

                非关系型数据库(nosql ),属于文档型数据库。MongoDB采用类JSON的documents来存储数据。数据结构由键值(key=>value)对组成。
                MongoDB采用动态数据模型schema,这意味着不需要预先定义表的数据类型和字段名。
                当MongoDB需要更新文档documents的时候,可以轻松增加新的字段名或者删除旧的字段。
                MongoDB让数据结构更加层级化,因而存储数组等复杂数据结构。 在同一个集合collection中,文档document对字段也没有强约束,因此更容易设计差异化的数据结构。

存储方式:虚拟内存+持久化。

查询语句:是独特的MongoDB的查询方式,相关信息由于可以采用灵活的数据结构存储在一块,所以查询速率非常快。

适合场景:事件的记录,内容管理或者博客平台等等。

架构特点:可以通过副本集,以及分片来实现高可用。

数据处理:数据是存储在硬盘上的,只不过需要经常读取的数据会被加载到内存中,将数据存储在物理内存中,从而达到高速读写。

优势:

易用性!对开发人员友好。易上手。国内用的较多,文档较全。

快速!在适量级的内存的MongoDB的性能是非常迅速的,它将热数据存储在物理内存中,使得热数据的读写变得十分快,

高扩展!

自身的Failover机制!且MongoDB具备高扩展性和延展性和自动分片机制(auto-sharding)。

2.3 Cassandra

(1) 列表数据结构

在混合模式可以将超级列添加到5维的分布式Key-Value存储系统。

(2) 模式灵活

使用Cassandra,不必提前解决记录中的字段。你可以在系统运行时随意的添加或移除字段。

(3) 真正的可扩展性

Cassandra是纯粹意义上的水平扩展。为给集群添加更多容量,可以增加动态添加节点即可。不必重启任何进程,改变应用查询,或手动迁移任何数据。

(4) 多数据中心识别

可以调整节点布局来避免某一个数据中心起火,一个备用的数据中心将至少有每条记录的完全复制。

(5) 范围查询

如果不喜欢全部的键值查询,则可以设置键的范围来查询。

(6) 分布式写操作

可以在任何地方任何时间集中读或写任何数据。并且不会有任何单点失败。

Cassandra写数据时,首先会将请求写入Commit Log以确保数据不会丢失,然后再写入内存中的Memtable,超过内存容量后再将内存中的数据刷到磁盘的SSTable,并定期异步对SSTable做数据合并(Compaction)以减少数据读取时的查询时间。因为写入操作只涉及到顺序写入和内存操作,因此有非常高的写入性能。而进行读操作时,Cassandra支持像LevelDB一样的实现机制,数据分层存储,将热点数据放在Memtable和相对小的SSTable中,所以能实现较高的读性能。

 

3. 性能对比

        单机测试:
               内存:8G
               硬盘:7200转 1T
               CPU: i5 6500
        数据集:
[{'domain': u'Boot', 'jama_id': u'IVL-UCIS-5923', 'name': u'Power Init', 'planned_release': u'PSS 0.8', 'execution_team': u'{Select One}', 'actual_release': u'Unassigned', 'integration_status': u'Not Started'},
 {'domain': u'Boot', 'jama_id': u'IVL-UCIS-5931', 'name': u'FTPM or TPM Support', 'planned_release': u'PSS 0.8', 'execution_team': u'{Select One}', 'actual_release': u'Unassigned', 'integration_status': u'BugFix Required'}, 
{'domain': u'Boot', 'jama_id': u'IVL-UCIS-5935', 'name': u'BIOS basic ME support', 'planned_release': u'PSS 0.8', 'execution_team': u'{Select One}', 'actual_release': u'Unassigned', 'integration_status': u'Completed'},
 {'domain': u'Boot', 'jama_id': u'IVL-UCIS-5936', 'name': u'BIOS Device Enablement', 'planned_release': u'PSS 0.8', 'execution_team': u'{Select One}', 'actual_release': u'PSS 0.8', 'integration_status': u'Completed'}, 
{'domain': u'Boot', 'jama_id': u'IVL-UCIS-5938', 'name': u'BOOT to UEFI with FW/IFWI', 'planned_release': u'PSS 0.8', 'execution_team': u'{Select One}', 'actual_release': u'Unassigned', 'integration_status': u'Completed'}, 
{'domain': u'Boot', 'jama_id': u'IVL-UCIS-5940', 'name': u'Basic BOOT on Linux', 'planned_release': u'PSS 0.8', 'execution_team': u'{Select One}', 'actual_release': u'PSS 0.8', 'integration_status': u'Completed'}, 
{'domain': u'Boot', 'jama_id': u'IVL-UCIS-5949', 'name': u'Intermediate boot', 'planned_release': u'PSS 1.0', 'execution_team': u'{Select One}', 'actual_release': u'PSS 1.0', 'integration_status': u'Completed'}, 
{'domain': u'Boot', 'jama_id': u'IVL-UCIS-5953', 'name': u'SMBIOS FW Data', 'planned_release': u'PSS 0.8', 'execution_team': u'{Select One}', 'actual_release': u'Unassigned', 'integration_status': u'Completed'}, 
{'domain': u'Boot', 'jama_id': u'IVL-UCIS-5954', 'name': u'Win Basic IO', 'planned_release': u'PSS 1.0', 'execution_team': u'{Select One}', 'actual_release': u'PSS 1.0', 'integration_status': u'Completed'}, 
{'domain': u'Boot', 'jama_id': u'IVL-UCIS-5955', 'name': u'Linux BASIC IO', 'planned_release': u'PSS 1.0', 'execution_team': u'{Select One}', 'actual_release': u'PSS 1.0', 'integration_status': u'Completed'}, 
{'domain': u'PM', 'jama_id': u'IVL-UCIS-5961', 'name': u'BASIC-Sx-Full_Sleep', 'planned_release': u'PSS 0.8', 'execution_team': u'{Select One}', 'actual_release': u'PSS 0.8', 'integration_status': u'Completed'}, 
{'domain': u'PM', 'jama_id': u'IVL-UCIS-5987', 'name': u'Global-Warm Reset', 'planned_release': u'PSS 0.8', 'execution_team': u'{Select One}', 'actual_release': u'PSS 0.8', 'integration_status': u'Completed'}] 
字段:7    数据条数:12   数据集大小:2.6KB  单条数据平均大小:0.08KB 
操作:1.向3个数据库都插入数据集5W次 合计数据12*5W = 60W条  合计数据大小 130M
          2. 从60W条数据中查找指定条件的数据(符合的数据5W条,每个数据集中一条符合)
          3. 修改数据,符合修改要求的数据共5W条
 
结果:
        
  insert find update
Mysql 106 s 0.9 s 1.3
MongoDB 37s 0.2 s 1.4
Cassandra 2000+ s 5 s 18s
     
        单机测试下Cassandra的结果有点意外,以高写入效率出名的Cassandra的写入速度反而差MySQL和MongoDB一大截,不知道是不是没有搭建集群或优化的原因。
        给出他人的测试结果吧:
        单纯查询场景:
        
        单纯随机查询的场景。在该场景中MongoDB表现最为突出,整体吞吐量达到每秒钟8万以上。SequoiaDB和Cassandra类似,大约为MongoDB的一半,在4万至5万之间徘徊。而HBase表现最差,未达到每秒1万的指标。
        查询导入平衡场景
        

该场景主要模拟50%的插入和50%的查询业务  其中插入业务使用单条记录插入。

最终的结果显示,SequoiaDB的整体表现最优,平均达到每秒钟超过14000TPS,而MongoDB/HBase/Cassandra则比较接近,各自不到10000TPS。

查询最新


查询最新场景为95%读+5%插入,并且读取的数据尽可能是刚刚写入的数据。

从图8中可以看出,SequoiaDB对于刚刚写入至内存中便读取的场景性能最佳,达到近4万每秒。

而MongoDB和Cassandra则相比场景6有明显下降,HBase依然性能较低。

 

更新为主

        
        

如图6所示,更新为主场景模拟95%更新与5%查询的场景。该场景中,SequoiaDB表现最优,结果介于5万到6万之间每秒。

而MongoDB表现相对较弱,大约在5千每秒左右的数量级。(然而我们实测MongoDB 修改5W条数据用时1.3s)

4. 分析

      在读场景多的情况下MongoDB(读性能更好)会更好,在写入和修改(写性能好)多的情况下Cassandra更合适。
      MongoDB 适用场景:
          1.应用不需要事务及复杂 join,2.新应用,需求会变,数据模型无法确定,想快速迭代开发 3.应用需要大量的的读写QPS, 4应用要求存储的数据不丢失?应用需要99.999%高可用?应用需要大量的地理位置查询、文本查询?
      Cassandra适用场景:
          1.大规模部署 2.写密集、统计和分析型工作,3支持多地分布,4.变化的应用

Mongodb cassandra 和 Mysql对比的更多相关文章

  1. Springboot集成mybatis(mysql),mail,mongodb,cassandra,scheduler,redis,kafka,shiro,websocket

    https://blog.csdn.net/a123demi/article/details/78234023  : Springboot集成mybatis(mysql),mail,mongodb,c ...

  2. 170504、MongoDB和MySQL对比(译)

    一.概要 几十年来,关系型数据库已经成为企业应用程序的基础,自从MySQL在1995年发布以来,它已经成为一种受欢迎并且廉价的选择.然而随着近年来数据量和数据的不断激增,非关系数据库技术如MongoD ...

  3. mongodb,redis,memcached,mysql对比

    1.性能都比较高,性能对我们来说应该都不是瓶颈总体来讲,TPS方面redis和memcache差不多,要大于mongodb 2.操作的便利性memcache数据结构单一redis丰富一些,数据操作方面 ...

  4. 非替代品,MongoDB与MySQL对比分析

    IT168 评论]对于只有SQL背景的人来说,想要深入研究NoSQL似乎是一个艰巨的任务,MySQL与MongoDB都是开源常用数据库,但是MySQL是传统的关系型数据库,MongoDB则是非关系型数 ...

  5. mongoDB关系型数据库的对比

    一.基本操作 1.mongoDB和关系型数据库对比 对比项 mongoDB mysql oracle 表 集合list 二维表 表的一行数据 文档document 一条记录 表字段 键key 字段fi ...

  6. Mongodb和Hbase的对比

    Mongodb和Hbase的对比 1.Mongodb bson文档型数据库,整个数据都存在磁盘中,hbase是列式数据库,集群部署时每个familycolumn保存在单独的hdfs文件中. 2.Mon ...

  7. mysql对比表结构对比同步,sqlyog架构同步工具

    mysql对比表结构对比同步,sqlyog架构同步工具 对比后的结果示例: 执行后的结果示例: 点击:"另存为(S)" 按钮可以把更新sql导出来.

  8. MongoDB与关系数据库的对比

    MongoDB与关系数据库的对比

  9. Mongodb数据结构及与MySql对比

    MySql一直是性价比最高的关系型数据库典范 MongoDB带来了关系数据库以外的NoSql体验. 让我们看一个简单的例子,我们将如何为MySQL(或任何关系数据库)和MongoDB中创建一个数据结构 ...

随机推荐

  1. HBase介绍 (1)---数据模型

    http://blog.csdn.net/heyutao007/article/details/5766896 BigTable是什么?Google的Paper对其作了充分的说明.字面上看就是一张大表 ...

  2. 小修改,让mvc的验证锦上添点花(1)

    首先,mvc的客户端验证用的是jquery.validate.js, jquery.validate本身已经提供了很好的扩展功能,通过简单点配置就可以做得更好看些. 而Microsoft通过jquer ...

  3. 【原创】vim插件安装简介

    一.安装vundle(vim插件管理软件): git clone https://github.com/VundleVim/Vundle.vim 拷贝目录到 ~/.vim/bundle/Vundle. ...

  4. linux 查看进程所在目录

    一下内容转自:https://blog.csdn.net/spring21st/article/details/50561550 通过 ps 及 top 命令查看进程信息时,只能查到 相对路径,查不到 ...

  5. luoguP4513 小白逛公园

    https://www.luogu.org/problemnew/show/P4513 题意是给你一个序列,计算一个区间内的最大字段和,支持单点修改 线段树维护左起最大字段和,右起最大字段和,区间和和 ...

  6. Redis + Redis-sentinel + keepalived部署过程

    1   Redis缓存服务 Redis是一个key-value存储系统.与memcached一样,为了保证效率,数据都是缓存在内存中的.区别的是redis支持周期性的把更新的数据写入磁盘或者把修改操作 ...

  7. Archlinux下virtualbox报错'/sbin/rcvboxdrv setup'

    因为刚刚换成archlinux系统,安装virtualbox的时候报错了.如下图: 可是怎么解决呢?我看了很多资料大多数是ubuntu的,没有archlinux的. 但是原理都差不多我借着也就研究出来 ...

  8. 分享VMware题目解答

    VMnet1是主机模式.是一个Host-Only网络模式 192.168.1.254/24VMnet8是NAT模式.是一个NAT方式,最简单的组网方式VMnet6是手动设置的(主机.net.内部) 1 ...

  9. 追随自己的价值观:用研经理 Anne Diaz 职业探索之路

    『漫谈』系列聚焦了人性脆弱面的价值.每期的对话嘉宾可能是爱彼迎设计团队的成员,也可能来自设计界的其他领域.对话主题都是我们在工作中很少讨论的话题. 这些话题涉及不同方面,比如失败.人生道路.冲突.成长 ...

  10. [web]Servlet中的Listener和Filter

    建议先看看 ——> Servlet工作原理 一.Listener 在Tomcat服务中,Listener的设计是基于观察者模式的,目前在Servlet中提供6中两类事件的观察者接口,它们分别是: ...