用mongodb数据的原因

小编给大家分享一下用mongodb数据的原因，相信大部分人都还不怎么了解，因此分享这边文章给大家学习，希望大家阅读完这篇文章后大所收获，下面让我们一起去学习方法吧！

MongoDB与其他数据库的对比

简单键值存储

简单键值存储正如其名，它们基于给定的键对值做索引。常见的场景是缓存。举例来说，假设您需要缓存一个由应用程序呈现的HTML页面，此处的键可能是页面的URL，值是HTML本身。请注意，对键值存储而言，值就是一个不透明的字节数组。不用强加关系型数据库中的Schema，也没有任何数据类型的概念。这自然限制了键值存储的操作：可以放入一个新值，然后通过键将其取出或删除。拥有如此简单性的系统通常很快，而且具有可伸缩性。

最著名的简单键值存储是memcached（发音是mem-cach-dee）。memcached仅在内存里存储数据，用持久性来换取速度。它也是分布式的，跨多台服务器的memcached节点能像单个数据存储来使用，这消除了维护跨服务器缓存状态的复杂性。

与MongoDB相比，memcached这样的简单键值存储通常读写会更快。但与MongoDB不同的是，这些系统很少能充当主要数据存储。简单键值存储的最佳用途是附加存储，既可以作为传统数据库之上的缓存层，也可以作为任务队列之类的短暂服务的简单持久层。

复杂键值存储

可以改进简单键值模型来处理复杂的读写Schema或提供更丰富的数据模型。如此一来，就有了复杂键值存储。广为流传的论文 Dynamo：Amazon's Highly Available Key-value Store中描述的Amazon Dynamo就是这样一个例子。Dynamo旨在成为一个健壮的数据库，在网络故障、数据中心停转及类似情况下仍能工作。这要求系统总是能够进行读和写，本质上就是要求数据能自动跨多个节点进行复制。如果一个节点发生故障，系统的用户，也许这里是一个使用Amazon购物车的顾客，不会察觉到服务中断。当系统允许同一份数据被写到多个节点时，发生冲突的情况是不可避免的，Dynamo提供了一些解决冲突的方法。与此同时，Dynamo也很容易伸缩。因为没有主节点——所有节点都是对等的，很容易从整体上理解系统，能方便地添加节点。尽管Dynamo是一个私有系统，但其构建理念启发了很多NoSQL系统，包括Cassandra、Project Voldemort和Riak。

看看是谁开发了这些复杂键值存储，看看实践中它们的使用情况如何，您就能知道它们的优点了。以Cassandra为例，它实现了很多Dynamo的伸缩属性，同时还提供了与Google BigTable类似的面向列的数据模型。Cassandra是一款开源的数据存储，是Facebook为其收件箱搜索功能而开发的。该系统可以水平扩展，索引60TB以上的收件箱数据，允许在收件箱中对关键字和收件人做检索。数据是根据用户ID做索引的，每条记录由一个用于关键字检索的搜索项数组和一个用于收件人检索的收件人ID数组构成。

这些复杂键值存储是由Amazon、Google和Facebook这样的大型互联网公司开发的，用来管理系统的多个部分，拥有非常大的数据量。换言之，复杂键值存储管理了一个相对自包含的域，它对有效存储和可用性有一定要求。由于采用了无主节点的架构，这些系统能轻松地通过添加节点进行扩展。它们都选择了最终一致性，也就是说读请求不必返回最后一次写的内容。用户用较弱的一致性所换得的是在某一节点失效时仍能写入的能力。

这与MongoDB正好相反，它提供了强一致性、（每个分片）一个主节点、更丰富的数据模型，还有二级索引，最后两项特性总是一起出现的。如果一个系统允许建模多个领域对象，例如，构建完整Web应用程序时就会有此要求，那么查询就需要跨整个数据模型，这时就要用到二级索引了。

因为有丰富的数据模型，可以考虑把MongoDB作为更通用的大型、可伸缩Web应用程序的解决方案。MongoDB的伸缩架构有时也会受到争议，因为它并非源自Dynamo。但MongoDB针对不同领域有不同的伸缩解决方案。MongoDB的自动分片受到了Yahoo! PNUTS数据存储和Google BigTable的启发。读过这些数据存储的白皮书的人会发现，MongoDB实现伸缩的方法已经被实现了，而且还很成功。

关系型数据库

本章中已经介绍了不少关系型数据库的内容，简单起见，我只讨论RDBMS与MongoDB的相同点和不同点。尽管MySQL使用固定Schema的数据表，MongoDB使用无Schema的文档，但两者都能表示丰富的数据模型。MySQL和MongoDB都支持B树索引，那些适用于MySQL索引的经验也同样适用于MongoDB。MySQL支持关联和事务，因此，如果您必须使用SQL或者要求有事务，那么只能选择MySQL或其他RDBMS。在不需要事务的情况下，MongoDB的文档模型通常也足够表示对象了。MongoDB中对单独文档的更新也是原子的，这提供了传统事务的一个子集。MongoDB和MySQL都支持复制。就可伸缩性而言，MongoDB设计成能水平扩展的，能自动分片并处理故障转移。MySQL上的分片都需要手动管理，有一定的复杂性，更常见的是垂直扩展的MySQL系统。

文档数据库

除了MongoDB之外，唯一的著名文档型数据库就是Apache CouchDB。尽管CouchDB的数据是使用JSON格式的纯文本存储的，而MongoDB使用的是BSON二进制格式，但两者的文档模型是相似的。与MongoDB一样，CouchDB也支持二级索引，不同之处是CouchDB中的索引是通过编写MapReduce函数来定义的，这比MySQL和MongoDB使用的声明式语法更复杂一些。两者伸缩的方式也有所不同，CouchDB不会把数据分散到多台服务器上，每个CouchDB节点都是其他节点的完整副本。

使用场景和生产部署

老实说，您不会仅根据数据库的特性就做出选择，您需要知道使用它的真实成功案例。这里，我提供一些广义上的MongoDB使用场景，以及一些生产环境中的范例。

Web应用程序

MongoDB很适合作为Web应用程序的主要数据存储。就算是一个简单的Web应用程序也会有很多数据模型，用来管理用户、会话、应用特定的数据、上传和权限，更不用说完整领域了。正如它们能和关系型数据库的扁平式方法对齐一样，它们也能获益于MongoDB的集合与文档模型。因为文档能表示丰富的数据结构，建模相同数据所需的集合数量通常会比使用完全正规化关系型模型的数据表数量要少。此外，动态查询和二级索引能让您轻松地实现SQL开发者所熟悉的大多数查询。最后，作为一个成长中的Web应用程序，MongoDB提供了清晰的扩展路线。

在生产环境中，MongoDB已经证明它能管理应用的方方面面，从主要数据领域到附加数据存储，比如日志和实时分析。这里的案例来自The Business Insider（TBE），它从2008年1月起使用MongoDB作为主要数据存储。虽然TBE是一个新闻网站，但它流量很大，每天有超过一百万独立页面访问（page view）。这个案例中有意思的是除了处理站点的主要内容（文章、评论、用户等等），MongoDB还处理并存储实时分析数据。这些分析被TBE用于生成动态热点地图，标明不同新闻故事的点击率。该站目前还没有太多的数据需要分片，但它有使用副本集来保证自动故障转移。

敏捷开发

无论如何看待敏捷开发运动，您都很难否认大家对于快速构建应用程序的渴望。不少开发团队，包括Shutterfly和纽约时代的团队，都部分选择了MongoDB，因为相比关系型数据库，使用MongoDB他们能更快地开发应用程序。一个明显的原因是MongoDB没有固定的Schema，所有花在提交、沟通和实施Schema变更的时间都省下来了。

除此之外，不再需要花时间把数据的关系型表述硬塞进面向对象的数据模型里去了，也不用处理ORM生成的SQL的奇怪行为，或者对它做优化了。如此一来，MongoDB为项目带来了更短的开发周期和敏捷的、中型大小的团队。

分析和日志

我之前已经暗示过MongoDB适用于分析和日志，将MongoDB用于这些方面的应用程序数量增长得越来越快。通常，发展成熟的公司都会选择用于分析的特殊应用作为切入点，进入MongoDB的世界。这些公司包括GitHub、Disqus、Justin.tv和Gilt Groupe，还有其他公司就不再列举了。

MongoDB与分析的关联源自于它的速度和两个关键特性：目标原子更新和固定集合（capped collection）。原子更新让客户端能高效地增加计数器，将值放入数组。固定集合，常被用于日志，特点是分配的大小是固定的，能实现自动过期。相比文件系统，将日志数据保存在数据库里更易组织，而且能提供更强大的查询能力。现在，抛开grep或自定义日志检索工具，用户可以使用他们熟悉并喜欢的MongoDB查询语言来查看日志输出。

缓存

这是一种数据模型，它能更完整地表示对象，结合了更快的平均查询速度，经常让MongoDB介于传统的MySQL与memcached之间。例如之前提到的TBE，它不使用memcached，直接通过MongoDB来响应页面请求。

以上是用mongodb数据的原因的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注亿速云行业资讯频道！