NoSQL-MongoDB
MongoDB 与 MySQL 的区别
关于 MongoDB 与 MySQL 的区别可以参考网上关于 NoSQL 与 MySQL 的区别,以下是找到的网上的关于两者区别的截图:
MongoDB 的优势
MongoDB 的劣势
总体上讲:
由于 MongoDB 独特的数据处理方式,可以将热点数据加载到内存,故而对查询来讲,会非常快(当然也会非常消耗内存);同时由于采用了 BSON 的方式存储数据,故而对 JSON 格式数据具有非常好的支持性以及友好的表结构修改性,文档式的存储方式,数据友好可见;数据库的分片集群负载具有非常好的扩展性以及非常不错的自动故障转移(大赞)。
不足:数据库的查询采用了特有的查询方式,有一定的学习成本(不高);索引不咋滴;锁只能提供到 collection 级别,还做不到行级锁;没有事务机制(不能回滚啊);学习资料肯定没有 MySQL 的多。
MongoDB 相关视频
提取码: ud3e MongoDB
MongoDB 与 Hadoop 的区别
MongoDB 侧重于对数据进行操作的应用系统,而 Hadoop 则侧重于对数据进行分析统计的应用。
MongoDB 能够满足对数据库读写性能具有极高要求的应用场景(很消耗 memory 的),一般这些应用的响应延迟会要求控制在 10ms 以下,甚至更低。而 Hadoop 由于每一次的读写操作会包含大量数据(Hadoop 更适合少次操作大批量数据的场景),通过聚集分析处理大量数据,这种分析一般都会走 MapReduce,会造成很高的延迟(数分钟到数小时不等)
不适合 MongoDB 的场景
如果业务中存在大量复杂的事务逻辑操作,则不要用 MongoDB 数据库
MongoDB 能为我解决哪些问题
一般来讲,我会将 MySQL 中的部分表迁移到 MongoDB 中,主要是涉及到车辆历史轨迹以及温湿度数据等机器采集到的数据,而订单数据、***等信息,仍然放到 MySQL 数据库中,主要是因为这两类数据实时采集,实时更新,会随着时间的推移,项目的扩大(PAAS 服务),造成非常巨大的数据量,而一般 MySQL 在单表数据量超过 500 万后,性能就会下降的比较快,虽然可以通过分表的方式进行处理,但是随着时间的增长,仍然会给我带来比较大的麻烦(如查询等),这样,就不如将其放到 MongoDB 中存储,查询什么的都会比较方便,不过需要注意根据片键分片哦。
在开发过程中遇到问题如何求助
常见的问题一般都可以在网上找到答案。
可以百度搜索如https://segmentfault.com/t/mongodb,github 之类的网站查找对应的问题
mongodb 与关系型数据库相比的优缺点
与关系型数据库相比
MongoDB 的优点:
弱一致性(最终一致),更能保证用户的访问速度:
举例来说,在传统的关系型数据库中,一个 COUNT 类型的操作会锁定数据集,这样可以保证得到“当前”情况下的较精确值。这在某些情况下,例 如通过 ATM 查看账户信息的时候很重要,但对于 Wordnik 来说,数据是不断更新和增长的,这种“较精确”的保证几乎没有任何意义,反而会产生很大的延 迟。他们需要的是一个“大约”的数字以及更快的处理速度。
但某些情况下 MongoDB 会锁住数据库。如果此时正有数百个请求,则它们会堆积起来,造成许多问题。我们使用了下面的优化方式来避免锁定:
每次更新前,我们会先查询记录。查询操作会将对象放入内存,于是更新则会尽可能的迅速。在主/从部署方案中,从节点可以使用“-pretouch”参数运行,这也可以得到相同的效果。
使用多个 mongod 进程。我们根据访问模式将数据库拆分成多个进程。
文档结构的存储方式,能够更便捷的获取数据。
对于一个层级式的数据结构来说,如果要将这样的数据使用扁平式的,表状的结构来保存数据,这无论是在查询还是获取数据时都十分困难。
内置 GridFS,支持大容量的存储。
GridFS 是一个出色的分布式文件系统,可以支持海量的数据存储。
内置了 GridFS 了 MongoDB,能够满足对大数据集的快速范围查询。
内置 Sharding。
提供基于 Range 的 Auto Sharding 机制:一个 collection 可按照记录的范围,分成若干个段,切分到不同的 Shard 上。
Shards 可以和复制结合,配合 Replica sets 能够实现 Sharding+fail-over,不同的 Shard 之间可以负载均衡。查询是对 客户端是透明的。客户端执行查询,统计,MapReduce 等操作,这些会被 MongoDB 自动路由到后端的数据节点。这让我们关注于自己的业务,适当的 时候可以无痛的升级。MongoDB 的 Sharding 设计能力较大可支持约 20 petabytes,足以支撑一般应用。
这可以保证 MongoDB 运行在便宜的 PC 服务器集群上。PC 集群扩充起来非常方便并且成本很低,避免了“sharding”操作的复杂性和成本。
第三方支持丰富。(这是与其他的 NoSQL 相比,MongoDB 也具有的优势)
现在网络上的很多 NoSQL 开源数据库完全属于社区型的,没有官方支持,给使用者带来了很大的风险。
而开源文档数据库 MongoDB 背后有商业公司 10gen 为其提供供商业培训和支持。
而且 MongoDB 社区非常活跃,很多开发框架都迅速提供了对 MongDB 的支持。不少知名大公司和网站也在生产环境中使用 MongoDB,越来越多的创新型企业转而使用 MongoDB 作为和 Django,RoR 来搭配的技术方案。
性能优越:
在使用场合下,千万级别的文档对象,近 10G 的数据,对有索引的 ID 的查询不会比 mysql 慢,而对非索引字段的查询,则是全面胜出。 mysql 实际无法胜任大数据量下任意字段的查询,而 mongodb 的查询性能实在让我惊讶。写入性能同样很令人满意,同样写入百万级别的数 据,mongodb 比我以前试用过的 couchdb 要快得多,基本 10 分钟以下可以解决。补上一句,观察过程中 mongodb 都远算不上是 CPU 杀手。
关系型数据库相比,MongoDB 的缺点:
mongodb 不支持事务操作。
所以事务要求严格的系统(如果银行系统)肯定不能用它。(这点和优点①是对应的)
mongodb 占用空间过大。
关于其原因,在官方的 FAQ 中,提到有如下几个方面:
空间的预分配:为避免形成过多的硬盘碎片,mongodb 每次空间不足时都会申请生成一大块的硬盘空间,而且申请的量从 64M、128M、256M 那 样的指数递增,直到 2G 为单个文件的较大体积。随着数据量的增加,你可以在其数据目录里看到这些整块生成容量不断递增的文件。
字段名所占用的空间:为了保持每个记录内的结构信息用于查询,mongodb 需要把每个字段的 key-value 都以 BSON 的形式存储,如果 value 域相对于 key 域并不大,比如存放数值型的数据,则数据的 overhead 是较大的。一种减少空间占用的方法是把字段名尽量取短一些,这样占用 空间就小了,但这就要求在易读性与空间占用上作为权衡了。我曾建议作者把字段名作个 index,每个字段名用一个字节表示,这样就不用担心字段名取多长 了。但作者的担忧也不无道理,这种索引方式需要每次查询得到结果后把索引值跟原值作一个替换,再发送到客户端,这个替换也是挺耗费时间的。现在的实现算是 拿空间来换取时间吧。
删除记录不释放空间:这很容易理解,为避免记录删除后的数据的大规模挪动,原记录空间不删除,只标记“已删除”即可,以后还可以重复利用。
可以定期运行 db.repairDatabase()来整理记录,但这个过程会比较缓慢
MongoDB 没有如 MySQL 那样成熟的维护工具,这对于开发和 IT 运营都是个值得注意的地方。
MongoDB 适合存储一些关系简单、数据量又很大的数据,比如我们的平台上虚拟机的监控信息,包括内存、IO、CPU、网络等数据,每隔几秒就采集一次数据,每周、每月,量很大,而且旧的监控数据也不会保留太长时间,就使用的 mongodb 来存储这些数据;
另外 mongodb 的集群部署相对比较简单,易于扩展;比如主从复制,在 mongo.conf 配置几个参数就 OK 了;分片集群的配置也比较简单。还支持使用命令行来进行动态地添加和删除节点;
Mongodb 的优点与不足
Mongodb 的不足之处
在集群分片中的数据分布不均匀
单机可靠性比较差
大数据量持续插入,写入性能有较大波动
磁盘空间占用比较大
Mongodb 的过人之处
无模式
查询与索引方式灵活,是最像 SQL 的 Nosql
支持复制集、主备、互为主备、自动分片等特性
Mongodb 与 redis 相比较:
mongoDB 源码语言是 C++,redis 也是 C 或 C++,
mongodb 文件存储是 BSON 格式类似 JSON,或自定义的二进制格式。
mongodb 与 redis 性能都很依赖内存的大小,mongodb 有丰富的数据表达、索引;最类似于关系数据库,支持丰富的查询语言,redis 数据丰富,较少的 IO ,这方面 mongodb 优势明显。
mongodb 不支持事物,靠客户端自身保证,redis 支持事物,比较弱,仅能保证事物中的操作按顺序执行,这方面 redis 优于 mongodb。
mongodb 对海量数据的访问效率提升,redis 较小数据量的性能及运算,这方面 mongodb 性能优于 redis .monbgodb 有 mapredurce 功能,提供数据分析,redis 没有 ,这方面 mongodb 优于 redis 。
评论