使用 MySQL 的视角去看待 MongoDB 数据库
有专门的SQL背景的人钻研NoSQL看起来是一项艰巨的任务。我曾经在小型MySQL环境和大型Oracle SQL环境使用过SQL。
MongoDB在什么时候是一个不错的选择?
MongoDB是一个令人难以置信地健壮的、可扩展的、操作简便的数据库解决方案。 MongoDB是一个不错的选择,当你的开发者也需要负责数据库环境时。在小商店和创业公司,可能就是这样。 MongoDB用BSON (二进制JSON)存储信息。BSON是MongoDB用来检索存储在后端的BSON的信息的原生的JSON(JavaScript对象符号)语言。JSON和其他编程语言看起来很相近,许多开发者已经有过使用它的经验了。
当你需要大量写操作时,MongoDB同样是个不错的选择。这不是说当处理写任务繁重(write-heavy) 环境时MySQL没有好的选择,但是MongoDB处理起来相对轻松一点。Facebook为写任务繁重的环境设计了RocksDB存储引擎,也能很好地运行(标准检查程序测试证明了这一点)。
当你需要一个无模式(schemaless)或者模式灵活(schema-flexible)的数据结构的时候,MongoDB是一个不错的选择。 MongoDB能够相对轻松和优雅地处理你的数据组织的更改。这是NoSQL解决方案的卖点。MySQL世界也做了很多改进,使得在线模式(schema)更改成为可能,但是仍然比不上MongoDB那么简单。不需要定义结构就能创建记录的机制给MongoDB增加了灵活性。
选择MongoDB的另一个原因是它关于副本集设置、内置分片(build-in sharing)和自动选举主数据集(auto elections)的功能。在MongoDB搭建副本环境是很简单的,而且如果主节点(primary)挂了,自动选举主数据库过程允许一个第二主节点(secondary)接管主节点的职责。内置分片允许简单的水平扩展,对于MySQL环境来说管理、搭建和配置水平扩展都更加复杂。
什么时候你应该选择其他数据库?
MongoDB在某些情况下是一个很好的选择。在其他的某些情况下它又不是一个好的选择了。当你的数据高度关联和结构化时,MongoDB可能不是一个正确的选择。MongoDB不支持事务,但是在文档层面上,它的文档是原子性的。有关write concern机制的副本环境配置需要考虑一些问题,但解决这些问题是要以性能为代价的。 write concern异常的出现证明副本节点已经写入了信息。默认地,MongoDB设置了write concern只从主节点请求确认,而不从副本节点做这个事情。如果副本节点出现问题,这可能会导致违反数据一致性的情况。
MongoDB和MySQL在结构上有什么区别?
在SQL世界的许多概念听起来很像MongoDB的文档结构。让我们看一下一个简单的MongoDB环境的高层结构来更好地理解是怎么布局的。
下面的图表把MySQL和MongoDB做了一个关联(这是在MongoDB的官方文档发现的)。
另一个有趣的值得注意的地方是mongod进程。这是一个处理数据请求的守护进程,和MySQL的mysqld进程非常相似。这个进程监听MongoDB请求,管理数据库的访问。和MySQL一样,mongod进程也有一些启动选项。最重要的配置选项之一是—— 指定你的mongod实例使用的一个配置文件的配置。MySQL有轻微不同的是,这个文件使用YAML格式。下面是MongoDB的一个示例配置文件。请注意这个文件只是为了演示格式而已。它没有对用于生产的数据库做任何优化。
从定义上来说,MongoDB是一个文档存储数据库。这个图表可以让你对MongoDB的数据结构与MySQL或任何SQL风味数据库的关联有一些概念。不同于建一个表和添加数据,你可以在不定义数据结构的情况下直接插入数据到一个collection。这是MongoDB在灵活性上超过MySQL的优点之一。只是因为MongoDB提供了它的灵活性并不意味着组织一个功能强大的应用于生产的MongoDB数据库是毫不费力的,注意到这点很重要。和选择任何数据库一样,你应该留心数据库的数据结构和要达到的目标,来避免迟早会掉入的陷阱。
注意:YAML格式不处理标签。使用空格来缩进吧。
查询方面有什么差别?
通过shell和数据库进行交互方面,MongoDB的使用也和SQL有些差别。MongoDB用JSON来进行查询。同样,web开发人员对此非常熟悉,这也是吸引人们使用MongoDB的其中一个原因。下面是一个从SQL翻译过来成MongoDB用语的查询。我们有一个表user,这个表里面只有username和对应的ID。
用SQL来查询:
select username from user where id = 2;
在MongoDB里面的查询:
db.user.find({_id:2},{“username”:1})
我们以JSON格式指定了查询的user集合(collection)和我们感兴趣的文档的ID。最后,我们想要从其获得值的字段被指定。查询的结果将会是ID为2的用户(user)的用户名(username)。
总结
MongoDB对于你的MySQL困境来说并不是一个新技术了。 随着这两个数据库的不断发展,他们的弱点和优势开始慢慢地融合在了一起。不要让MongoDB灵活的数据结构欺骗你,让你认为你不需要对你的数据环境做好计划。这在未来一定会导致让你头痛的事情。这种灵活性允许的是动态的,快速的变化——而不是轻率的变化。
我鼓励任何MySQL用户为了测试的目的去获取一个MongoDB实例。在电子商务和游戏的世界,MongoDB是一个热门的选项,这得益于它的模式(schema)设计灵活性和对大量数据进行水平扩展的功能。
文 | Peter Zaitsev 译者 | tangmisi
时间:2018-10-09 23:10 来源: 转发量:次
声明:本站部分作品是由网友自主投稿和发布、编辑整理上传,对此类作品本站仅提供交流平台,转载的目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,不为其版权负责。如果您发现网站上有侵犯您的知识产权的作品,请与我们取得联系,我们会及时修改或删除。
相关文章:
- [数据挖掘]缓存与数据库双写一致性
- [数据挖掘]揭开AWS的Timestream数据库的面纱
- [数据挖掘]Oracle 行贿 10 万元:中标 1980 万元数据库项目
- [数据挖掘]"存算分离"已成为分布式数据库的主流方
- [数据挖掘]MySQL vs Redis,新时代王者的较量
- [数据挖掘]在复杂条件搜索上,为什么MySQL只能被ES吊打?
- [数据挖掘]MySQL 8.0的Public Key Retrival错误,毫无规律可言怎么
- [数据挖掘]卸载Navicat!操作所有的数据库靠它就够了
- [数据挖掘]吊打MySQL,MariaDB到底强在哪?
- [数据挖掘]为什么阿里不建议MySQL使用text类型?
相关推荐:
网友评论: