NoSQL数据库PPT

优点
查找速度快
缺点
数据无结构化，通 常只被当作字符串 或者二进制数据
列存储数据 库
Cassandra, HBase, Riak
分布式的文件系统 以列簇式存储， 查找速度快，可扩
将同一列数据 展性强，更容易进
存在一起
行分布式扩展
功能相对局限
文档型数据 CouchDB,
库
MongoDb
与Key-Value类似， Key-Value对 Value是结构化的， 应的键值对， 不同的是数据库能 Value为结构 够了解Value的内 化数据 容
数据结构要求不严 格，表结构可变， 不需要像关系型数 据库一样需要预先 定义表结构
查询性能不高，而 且缺乏统一的查询 语法。
图形(Graph) 数据库
Neo4J, InfoGrid, Infinite Graph
社交网络，推荐系 图结构 统等。专注于构建 关系图谱
利用图结构相关算 法。比如最短路径 寻址，N度关系查找 等
4.图形(Graph)数据库
图形结构的数据库同其他行列以及刚性结构的SQL数据库不 同，它是使用灵活的图形模型，并且能够扩展到多个服务器 上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数 据库查询需要制定数据模型。许多NoSQL数据库都有REST 式的数据接口或者查询API。
NoSQL数据库的四大分类表格分析
6. BASE
相对于事务严格的ACID特性，NoSQL数据库保证的是BASE特性。BASE是最终 一致性和软事务。
四.NoSQL数据库的四大分类
1.键值(Key-Value)存储数据库
这一类数据库主要会使用到一个哈希表，这个表中有一个特 定的键和一个指针指向特定的数据。Key/value模型对于IT系 统来说的优势在于简单、易部署。但是如果DBA只对部分值 进行查询或更新的时候，Key/value就显得效率低下了。
1、High performance - 对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提 供动态信息，所以基本上无法使用动态页面静态化技术，因 此数据库并发负载非常高，往往要达到每秒上万次读写请求。 关系数据库应付上万次SQL查询还勉强顶得住，但是应付上 万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于 普通的BBS网站，往往也存在对高并发写请求的需求。
大规模数据集合，多重 数据带来了许多挑战， 尤其是大数据应用难题 厄待解决
关系数据库面临的挑战
传库在应付web2.0网站，特别是超大规模和高并发的SNS类 型的web2.0纯动态网站已经显得力不从心，暴露了很多难以 克服的问题统的关系数据，例如：
1、High performance - 对数据库高并发读写的需求； 2、Huge Storage - 对海量数据的高效率存储和访问的需求； 3、High Scalability && High Availability- 对数据库的高可扩 展性和高可用性的需求；
3. 弹性可扩展
可以在系统运行的时候，动态增加或者删除结点。不需要停机维护，数据可 以自动迁移。
4. 分区
相对于将数据存放于同一个节点，NoSQL数据库需要将数据进行分区，将记录分 散在多个节点上面。并且通常分区的同时还要做复制。这样既提高了并行性能， 又能保证没有单点失效的问题。
5. 异步复制
和RAID存储系统不同的是，NoSQL中的复制，往往是基于日志的异步复制。这 样，数据就可以尽快地写入一个节点，而不会被网络传输引起迟延。缺点是并不 总是能保证一致性，这样的方式在出现故障的时候，可能会丢失少量的数据。
3、High Scalability && High Availability- 对数据库的高可扩 展性和高可用性的需求
在基于web的架构当中，数据库是最难进行横向扩展的，当 一个应用系统的用户量和访问量与日俱增的时候，你的数据 库却没有办法像web server和app server那样简单的通过添 加更多的硬件和服务节点来扩展性能和负载能力。对于很多 需要提供24小时不间断服务的网站来说，对数据库系统进行 升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁 移，为什么数据库不能通过不断的添加服务器节点来实现扩 展呢？
三.共同特征
对于NoSQL并没有一个明确的范围和定义，但是他们都 普遍存在下面一些共 同特征：
1.不需要预定义模式
不需要事先定义数据模式，预定义表结构。数据中的每条记录都可能有不同 的属性和格式。当插入数据时，并不需要预先定义它们的模式。
2. 无共享Fra Baidu bibliotek构
相对于将所有数据存储的存储区域网络中的全共享架构。NoSQL往往将数据 划分后存储在各个本地服务器上。因为从本地磁盘读取数据的性能往往好于 通过网络传输读取数据的性能，从而提高了系统的性能。
NoSQL数据库
内容大纲
定义
产生
共同特征
分类 适用场景 发展现状 挑战
一.什么是NoSQL数据库？
NoSQL: 即Not Only SQL 与关系型数据库相对应的，也可理解为 no relational ，即非关系型数据库
。
二.NoSQL数据库的产生
关系数据库
A 面临挑战
大数据 B 发展
关系数据库面对超大规模和 高 并 发 的 SNS 类 型 的 web2.0 纯 动 态 网 站 显 得 力 不从心，暴露了很多难以克 服的问题
七.挑战
1. 已有key-value数据库产品大多是面向特定应用自治构建的，缺乏通用性；
2. 已有产品支持的功能有限（不支持事务特性），导致其应用具有一定的局限性；
3. 已有一些研究成果和改进的NoSQL数据存储系统，但它们都是针对不同应用需 求而提出的相应解决方案，如支持组内事务特性、弹性事务等，很少从全局考虑 系统的通用性，也没有形成系列化的研究成果；
分类
Examples举 典型应用场景 例
键值 （key-value）
Tokyo Cabinet/Tyra nt, Redis, Voldemort, Oracle BDB
内容缓存，主要用 于处理大量数据的 高访问负载，也用 于一些日志系统等 等
数据模型
Key 指向 Value 的键值 对，通常用 hash table来 实现
很多时候需要对整 个图做计算才能得 出需要的信息，而 且这种结构不太好 做分布式的集群方 案
五.适用场景
NoSQL数据库在以下的这几种情况下比较适用：
1、数据模型比较简单； 2、需要灵活性更强的IT系统； 3、对数据库性能要求较高； 4、不需要高度的数据一致性； 5、对于给定key，比较容易映射复杂值的环境。
在上面提到的“三高”需求面前，关系数据库遇到了难以克 服的障碍，而对于web2.0网站来说，关系数据库的很多主要 特性却往往无用武之地，例如：
1、数据库事务一致性需求很多web实时系统并不要求严格的 数据库事务，对读一致性的要求很低，有些场合对写一致性 要求也不高。因此数据库事务管理成了数据库高负载下一个 沉重的负担；
4. 缺乏类似关系数据库所具有的强有力的理论(如armstrong公理系统)、技术（如 成熟的基于启发式的优化策略、两段封锁协议等）、标准规范（如SQL语言）的 支持。
5. 目前，HBase数据库时安全特性最完善的NoSQL数据库产品之一，而其他的 NoSQL数据库多数没有提供内建的安全机制，但随着NoSQL的发展，越来越多 的人开始意识到安全的重要，部分NoSQL产品逐渐开始提供一些安全方面的支持。
2.列存储数据库 这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但 是它们的特点是指向了多个列。这些列是由列家族来安排的。
3.文档型数据库 文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种 键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档 以特定的格式存储。文档型数据库可 以看作是键值数据库的升级版，允 许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。
2、Huge Storage - 对海量数据的高效率存储和访问的需求
对于大型的SNS网站，每天用户产生海量的用户动态，以国 外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对 于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查 询，效率是极其低下乃至不可忍受的。再例如大型web网站 的用户登录系统，若没有能够支撑海量数据的高效率存储和 访问需求的数据库，那又如何满足用户的需求？
六.发展现状
计算机体系结构在数据存储方面要求具备庞大的水平扩展性，而NoSQL致力于改 变这一现状。
NoSQL项目的名字上看不出什么相同之处，但是，它们通常在某些方面相同：它 们可以处理超大量的数据。
这场革命仍然需要等待。的确，NoSQL对大型企业来说还不是主流，但是，一两 年之后很可能就会变个样子。在NoSQL运动的最新一次聚会中，来自世界各地的 150人挤满了CBS Interactive的一间会议室。分享他们如何推翻缓慢而昂贵的关 系数据库的暴政的经验，怎样使用更有效和更便宜的方法来管理数据。
“关系型数据库给你强加了太多东西。它们要你强行修改对象数据，以满足 RDBMS （relational database management system，关系型数据库管理系统） 的需要，”在NoSQL拥护者们看来，基于NoSQL的替代方案“只是给你所需要 的”。
水平扩展性(horizontal scalability)指能够连接多个软硬件的特性,这样可以将多个 服务器从逻辑上看成一个实体。
2、数据库的写实时性和读实时性需求对关系数据库来说，插 入一条数据之后立刻查询，是肯定可以读出来这条数据的， 但是对于很多web应用来说，并不要求这么高的实时性。
3、对复杂的SQL查询，特别是多表关联查询的需求。任何 大数据量的web系统，都非常忌讳多个大表的关联查询， 以及复杂的数据分析类型的复杂SQL报表查询，特别是 SNS类型的网站，从需求以及产品设计角度，就避免了这 种情况的产生。往往更多的只是单表的主键查询，以及单 表的简单条件分页查询，SQL的功能被极大的弱化了。