做网站是什么行业,黄页888,百度推广授权代理商,淘宝网发布网站建设本文转载自#xff1a;http://book.2cto.com/201211/7897.html 市面上的数据库数量成爆炸式增长#xff0c;要在它们之间进行权衡是很困难的。幸运的是#xff0c;它们之中的大多数数据库都能归在几个分类里。本节中#xff0c;我会描述简单及复杂的键值存储、关系型数据库… 本文转载自http://book.2cto.com/201211/7897.html 市面上的数据库数量成爆炸式增长要在它们之间进行权衡是很困难的。幸运的是它们之中的大多数数据库都能归在几个分类里。本节中我会描述简单及复杂的键值存储、关系型数据库和文档数据库并将它们与MongoDB做一个比较。下面来看表1-1。 表1-1　数据库家族  示　　例数据模型伸缩性模型使用场景简单键值存储memcached键值对其中值是一个二进制大字段多种模型。memcached能跨多个节点进行伸缩把所有可用内存变为一个巨大的数据存储缓存、Web操作复杂键值存储Cassandra、Project Voldemort、Riak多种模型。Cassandra使用名为列column的键值结构。Voldemort存储二进制大字段最终一致性多节点部署以获得高可用性和简单的故障转移高吞吐量垂直内容活动feed、消息队列、缓存、Web操作关系型数据库Oracle数据库、MySQL、 PostgreSQL数据表垂直伸缩。对集群和手动分区支持有限要求事务银行、金融或SQL的系统、正规化数据模型 1. 简单键值存储 简单键值存储正如其名基于给定的键对值做索引。常见的场景是缓存。举例来说假设需要缓存一个由应用程序呈现的HTML页面此处的键可能是页面的URL值是HTML本身。请注意对键值存储而言值就是一个不透明的字节数组。没有强加关系型数据库中的Schema也没有任何数据类型的概念。这自然限制了键值存储允许的操作可以放入一个新值然后通过键将其找出或删除。拥有如此简单性的系统通常很快而且具有可伸缩性。 最著名的简单键值存储是memcached发音是mem-cash-dee。memcached仅在内存里存储数据用持久性来换取速度。它也是分布式的跨多台服务器的memcached节点能像单个数据存储那样来使用这消除了维护跨服务器缓存状态的复杂性。 与MongoDB相比memcached这样的简单键值存储通常读写会更快。但与MongoDB不同这些系统很少能充当主要数据存储。简单键值存储的最佳用途是附加存储既可以作为传统数据库之上的缓存层也可以作为任务队列之类的短暂服务的简单持久层。 2. 复杂键值存储 可以改进简单键值模型来处理复杂的读写Schema或提供更丰富的数据模型。如此一来就有了复杂键值存储。广为流传的论文“Dynamo: Amazon’s Highly Available Key-value Store”中描述的亚马逊 Dynamo就是这样一个例子。Dynamo旨在成为一个健壮的数据库在网络故障、数据中心停转及类似情况下仍能工作。这要求系统总是能够被读和写本质上就是要求数据能自动跨多个节点进行复制。如果一个节点发生故障系统的用户在这里可能是一个使用亚马逊购物车的顾客不会察觉到服务中断。当系统允许同一份数据被写到多个节点时发生冲突的情况是不可避免的Dynamo提供了一些解决冲突的方法。与此同时Dynamo也很容易伸缩。因为没有主节点所有节点都是对等的所以很容易从整体上理解系统能方便地添加节点。尽管Dynamo是一个私有系统但其构建理念启发了很多NoSQL系统包括Cassandra、Project Voldemort和Riak。 看看是谁开发了这些复杂键值存储看看实践中它们的使用情况如何你就能知道它们的优点了。以Cassandra为例它实现了很多Dynamo的伸缩属性同时还提供了与谷歌 BigTable类似的面向列的数据模型。Cassandra是一款开源的数据存储是Facebook为其收件箱搜索功能开发的。该系统可以水平扩展索引超过50 TB的收件箱数据允许在收件箱中对关键字和收件人做检索。数据是根据用户ID做索引的每条记录由一个用于关键字检索的搜索项数组和一个用于收件人检索的收件人ID数组构成。1 这些复杂键值存储是由亚马逊、谷歌和Facebook这样的大型互联网公司开发的用来管理系统的多个部分拥有非常大的数据量。换言之复杂键值存储管理了一个相对自包含的域它对海量存储和可用性有一定要求。由于采用了无主节点的架构这些系统能轻松地通过添加节点进行扩展。它们都选择了最终一致性也就是说读请求不必返回最后一次写的内容。用户用较弱的一致性所换得的是在某一节点失效时仍能写入的能力。 这与MongoDB正好相反MongoDB提供了强一致性、每个分片一个主节点、更丰富的数据模型还有二级索引最后两项特性总是一起出现的。如果一个系统允许跨多个域建模例如构建完整Web应用程序时就会有此要求那么查询就需要跨整个数据模型这时就要用到二级索引了。 因为有丰富的数据模型可以考虑把MongoDB作为更通用的大型、可伸缩Web应用程序的解决方案。MongoDB的伸缩架构有时也会受到非难因为它并非源自Dynamo。但MongoDB针对不同域有不同的伸缩解决方案。MongoDB的自动分片受到了雅虎PNUTS数据存储和谷歌 BigTable的启发。读过发布这些数据存储的白皮书的人会发现MongoDB实现伸缩的方法已经被实现了而且还很成功。 3. 关系型数据库 本章已经介绍了不少关系型数据库的内容简单起见我只讨论RDBMS与MongoDB的相同点和不同点。尽管MySQL2使用固定Schema的数据表MongoDB使用无Schema的文档但两者都能表示丰富的数据模型。MySQL和MongoDB都支持B树索引那些适用于MySQL索引的经验也同样适用于MongoDB。MySQL支持联结和事务因此如果你必须使用SQL或者要求有事务那么只能选择MySQL或其他RDBMS。也就是说MongoDB的文档模型足以在不用联结查询的情况下表示对象。MongoDB中对单独文档的更新也是原子的这提供了传统事务的一个子集。MongoDB和MySQL都支持复制。就可伸缩性而言MongoDB设计成能水平扩展能自动分片并处理故障转移。MySQL上的分片都需要手动管理有一定的复杂性更常见的是垂直扩展的MySQL系统。 4. 文档数据库 自称为文档数据库的产品还不多在本书编写时除了MongoDB之外唯一的著名文档型数据库就是Apache CouchDB。尽管CouchDB的数据是使用JSON格式的纯文本存储的而MongoDB是使用BSON二进制格式但两者的文档模型是相似的。与MongoDB一样CouchDB也支持二级索引不同之处是CouchDB中的索引是通过编写MapReduce函数来定义的这比MySQL和MongoDB使用的声明式语法更复杂一些。两者伸缩的方式也有所不同CouchDB不会把数据分散到多台服务器上每个CouchDB节点都是其他节点的完整副本。 ________________________________ 1 参见http://mng.bz/5321。 2 这里我用MySQL来做说明因为我所描述的特性适用于大多数关系型数据库。 [以下补充内容来自http://book.2cto.com/201211/7896.html 为什么选择MongoDB] MongoDB项目的总体设计目标。根据其作者的观点MongoDB的设计是要结合键值存储和关系型数据库的最好特性。键值存储因为非常简单所以速度极快而且相对容易伸缩。关系型数据库较难伸缩至少很难水平伸缩但拥有富数据模型和强大的查询语言。如果MongoDB能介于两者之间就能成为一款易伸缩、能存储丰富数据结构、提供复杂查询机制的数据库。 在使用场景方面MongoDB非常适合用做以下应用程序的主要数据存储Web应用程序、分析与记录应用程序以及任何要求有中等级别缓存的应用程序。此外由于它能方便地存储无Schema数据MongoDB还很适合保存事先无法知晓其数据结构的数据。 转载于:https://blog.51cto.com/idata/1082559