文档数据库的学习报告

文档数据库的学习报告

 

0 目录:

       1 大数据环境下的背景

       2传统关系数据库的瓶颈

       3文档数据库的选择

       4 什么是文档数据库

                4.1 什么是文档?

4.2 JSON数据格式

4.3那么是什么是文档型数据库呢?

4.4有哪些文档数据库？

       5文档数据库的一些关键特点

6 文档数据库数据模型

7文档数据库数据建模技术

8文档数据库的适用场景

    8.1文档数据库适用场景的考虑因子

8.2适用的场景

8.3不适用场景

       9引用参考

1 大数据环境下的背景

随着互联网web2.0网站的兴起，Web 技术的最新进展使得所有用户都可以轻松地提供和使用所有格式的内容. 另外, 后web2.0时代是网络发展中一个重要的阶段，它连接着下一代互联网Web3.0. 在这个时代背景下，互联网、物联网每天都在产生大量的数据，这些庞大的数据资源，使得’‘大数据’‘得以问世. 大数据的出现，直接导致’‘资源’‘的含义发生极大的变化，例如：

                  * 构建一个个人网站(比如，Google Sites)

                  * 创建一个博客(使用 WordPress、Blogger 和 LiveJournal)

                  * 在网络社区进行交互(使用 Facebook、Twitter、LinkedIn等等)

这些渠道已成为商品和工具，使更多的人能够更多元化地轻松创建、使用和传输更多数据，比如，采用博客、微博、微信、社交网络交互、视频、音频和照片的形式，数据可以是结构化的，也可是非结构化的. 就创建、交流、访问内容、共享信息和购买产品而论，快速扩展的新一代基于 Internet 的服务(比如电子邮件、博客、社交媒体、搜索和电子商务)实际上重新定义了 Web 用户的行为和趋势. 由于这些系统的数量的不断增多, 所生成数据和所消耗数据的规模的不断扩大，不断增长的伸缩性需求和新功能需求, 为传统关系型数据库管理系统 (RDBMS) 带来了新的挑战.

 

2 传统关系数据库的瓶颈

         随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速. 而传统的关系数据库在应付 web2.0网站，特别是超大规模和高并发的SNS类型的web2.0动态网站已经显得力不从心，暴露了很多难以克服的问题：

                   1对数据库高并发读写的需求

web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求. 关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO早已经无法承受了. 其实对于普通的 BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求.

     2对海量数据的高效率存储和访问的需求

类似Facebook，Twitter，Instagram,  Friendfeed这样的社交网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5亿条用户动态. 对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的. 再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付.

3对数据库的高可扩展性和高可用性的需求

在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候, 数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力. 对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现横向扩展呢？

然而在上面提到的’‘三高’‘需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：

1数据库事务一致性需求

很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高. 因此数据库事务管理成了数据库高负载下的一个沉重负担.

2数据库的写实时性和读实时性需求

对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，举个例子, 如某用户在某个blog网站上发一条消息之后，过几秒乃至十几秒之后，该用户的订阅者才看到这条动态是完全可以接受的.

3复杂的SQL查询，特别是多表关联查询的需求

任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度来看，就需要避免这种情况的产生. 往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大地弱化了.

         在这些情况下, 大部分的MySQL都应该是IO密集型的. 然而事实上，如果MySQL是个CPU密集型的话，那么很可能MySQL在设计存在性能优化问题. 大数据量高并发环境下的MySQL应用开发越来越复杂，也越来越具有技术挑战性. 分表分库的规则把握都是需要经验的. 虽然有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发者的复杂性，但是避免不了整个应用架构的复杂性. 分库分表的子库到一定阶段又面临扩展问题. 还有就是需求的变更，可能又需要一种新的分库方式. 除此之外,  MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库. 比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小.

尽管关系数据库很强大，但是它并不能很好的应付所有的应用场景.  MySQL的扩展性差(需要复杂的技术来实现)，大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题.

 

3 文档数据库的选择

         如今的社交网站越来越普及，而随着用户量不断壮大，每个用户的使用方式或者是发布的内容类型都不尽相同. 有人会发布风景照片或者剪短的视频、有人发布对时事的评论, 还有人分享音乐用于表达心情等. 面对如此大量而多样性的数据，如果使用关系型模型，就需要不断修改数据操作模式，这样，可能会引起系统负载的大幅度提升，同时也会大大增加处理的响应时间.

         在这个背景下，希望新类型的数据库可以有以下特点：

1易扩展：关系型数据库是一种’’纵向扩展’’的技术，想要扩展容量(无论数据存储还是I/O)，都需要更换更大的服务器. 现代应用结构的解决却是使用’’横向扩展’’ --无需新购买更大的服务器，只需要在负载均衡器下增加一般的服务器、虚拟机或是云服务器就可以实现扩展. 此外，容量在不再需要的时候还可以轻易的缩减. 事实上, NoSQL数据库种类繁多，但它们的一个共同特点就是去掉关系数据库的关系型特性. 数据之间无关系，这样就非常容易扩展. 在架构的层面上带来了可扩展的能力.

2大数据量，高性能࿱