noSQL数据库

为什么使用NoSQL数据库
对海量数据的高效率存储和访问的需求
• 对于大型的SNS网站，每天用户产生海量的 用户动态，以国外的Friendfeed为例，一 个月就达到了2.5亿条用户动态，对于关系 数据库来说，在一张2.5亿条记录的表里面 进行SQL查询，效率是极其低下乃至不可忍 受的。再例如大型web网站的用户登录系统， 例如腾讯，盛大，动辄数以亿计的账号， 关系数据库也很难以应付。
NoSQL数据库 非关系型数据库
NoSQL数据库
目录
NoSQL数据库简介
为什么使用NoSQL数据库
NoSQLCAP原理
NoSQL数据库应用
NoSQL数据库简介
• NoSQL，即是不提供SQL功能的数据库，是一项全新的数据库革命性的 运动。NoSQL早期就有人提出，发展至2009年趋势越发高涨。NoSQL是 指非关系型数据库，分布式，不提供ACID的数据库设计模式。 • ACID，是指在数据库管理系统（DBMS）中，事务（transaction）所 具有的四个特性：原子性、（atomicity）、一致性（consistency）、 独立性（isolation）、持久性（durability）。 • 关系数据库，是建立在关系模型基础上的数据库，借助于集合代数等 数学概念和方法来处理数据库中的数据。现实世界中的各种实体以及 实体之间的各种联系均用关系模型来表示。标准数据查询语言SQL就 是一种基于关系数据库的语言，这种语言执行对关系数据库中的数据 的检索和操作。关系模型由关系数据结构、关系操作集合、关系完整 性约束三部分组成。
• (1) A写入V的新值V1。 • (2) N1向N2发送消息M以更新V值。 • (3) B读取V的新值V2
但是现实可能是这样子的
• 由于网络分区，N1发向N2的消息很有可能没送达，那么，B节点将读 取到一个过时的V值，不一致Байду номын сангаас产生了。并且当把节点的规模不断扩 大的时候，不一致性问题也会更加严重。 • 所以如果我们希望A B都是高可用的（也就是低延迟），那么一致性 通常就不能得到很好的保证，我们必须要容忍一定的不一致性以换取 高可用性。
NoSQL数据库优点
• 易扩展 NoSQL数据库种类繁多，但是一个共同的特点都是 去掉关系数据库的关系型特性。数据之间无关系， 这样就非常容易扩展。也无形之间，在架构的层 面上带来了可扩展的能力。 • 大数据量，高性能 NoSQL数据库都具有非常高的读写性能，尤其在大 数据量下，同样表现优秀。这得益于它的无关系 性，数据库的结构简单。一般MySQL使用 Query C ache，每次表的更新Cache就失效，是一种大粒度 的Cache，在针对web2.0的交互频繁的应用，Cach e性能不高。而NoSQL的 Cache是记录级的，是一 种细粒度的Cache，所以NoSQL在这个层面上来说 就要性能高很多了。
为什么使用NoSQL数据库
• 在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍， 而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之 地，例如： 1、数据库事务一致性需求 很多web实时系统并不要求严格的数据库事务，对读一致性的要 求很低，有些场合对写一致性要求也不高，因此数据库事务管理成了 数据库高负载下一个沉重负担。 2、数据库的写实时性和读实时性需求 对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出 来这条数据的，但对于很多web应用来说，并不需要这么高的实时性， 比如发一条消息之后，过几秒乃至十几秒后，我的订阅者才看到这条 动态是完全可以接受的。 3、对复杂的SQL查询，特别是多表关联查询的需求 任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复 杂的数据分析类型的复杂SQL报表查询，此时SQL的功能被极大的弱化 了。
NoSQL数据库特点
• 可以处理超大量的数据 • 可以运行在便宜的PC服务器集群上 • 打破了性能的瓶颈 NoSQL的支持者称，通过NoSQL架构可以省去将Web或J ava应用和数据转换成SQL友好格式的时间，执行速度变得 更快。对于那些繁重的重复操作的数据，SQL值得花钱。 但是当数据库结构非常简单时，SQL可能没有太大用处。 • 没有过多的操作 虽然NoSQL的支持者也承认关系数据库提供了无可比拟的 功能集合，而且在数据完整性上也发挥绝对稳定，他们同 时也表示，企业的具体需求可能没有那么多。
为什么使用NoSQL数据库
• 随着互联网web2.0网站的兴起，非关系型 的数据库现在成了一个极其热门的新领域。 传统的关系数据库在应付web2.0网站，特 别是超大规模和高并发的SNS（social net working service，即社会性网络服务）类 型的web2.0纯动态网站已经显得力不从心， 暴露了很多难以克服的问题。
为什么使用NoSQL数据库
对数据库的高可扩展性和高可用性的需求
• 在基于web的架构当中，数据库是最难进行横向扩 展的，当一个应用系统的用户量和访问量与日俱 增的时候，你的数据库却没有办法像web server 和app server 那样简单的通过添加更多的硬件和 服务节点来扩展性能和负载能力。对于很多需要 提供24小时不间断服务的网站来说，对数据库系 统进行升级和扩展是非常痛苦的事情，往往需要 停机维护和数据迁移，为什么数据库不能通过不 断的添加服务器节点来实现扩展呢？
MongoDB特性
• 它的特点是高性能、易部署、易使用，存储数据非常方便。主要功能 特性有： • 面向集合存储，易存储对象类型的数据。 • 模式自由。 • 支持动态查询。 • 支持完全索引，包含内部对象。 • 支持查询。 • 支持复制和故障恢复。 • 使用高效的二进制数据存储，包括大型对象（如视频等）。 • 自动处理碎片，以支持云计算层次的扩展性。 • 支持RUBY，PYTHON，JAVA，C++，PHP,C#等多种语言。 • 文件存储格式为BSON（一种JSON的扩展）。 • 可通过网络访问。
NoSQL数据库优点
• 灵活的数据模型 NoSQL无需事先为要存储的数据建立字段，随时 可以存储自定义的数据格式。而在关系数据库里， 增删字段是一件非常麻烦的事情。如果是非常大 数据量的表，增加字段简直就是一个噩梦。这点 在大数据量的web2.0时代尤其明显。 • 高可用 NoSQL在不太影响性能的情况，就可以方便的实现 高可用的架构。比如Cassandra，HBase模型，通 过复制模型也能实现高可用。
调整N、W、R的取值，数据库系统的性质就会发生改 变
• N越大，同一个数据的备份越多，系统相对也就越不容易 丢失数据。 • W越大，系统的一致性会越高，但更新操作也就越慢。 • R越大，系统的一致性会越高，但读操作也就越慢。 • W+R>N，系统是强一致性的。为什么？举例来说，假设N=6， W=R=3，当一个更新操作完成的时候，它至少更新了6个备 份中的3个备份，那么当我们去读取这个数据的时候，因 为R=3，所以我们至少得读3个数据，并从中选择最新的数 据，而W+R>N就意味着读取的3个数据跟更新的3个数据至 少有一个是重叠的，所以读取的3个数据中一定存在最新 的数据，因而就能保证系统是强一致性的。 • W+R<=N，系统是弱一致性的。
为什么使用NoSQL数据库
• 总结：传统的关系型数据功能支持上通常 很宽泛，从简单的键值查询，到复杂的多 表联合查询再到事务机制的支持。而与之 不同的是，NoSQL系统通常注重性能和扩展 性，而非事务机制。
NoSQL数据一致性
• 传统的SQL数据库的事务通常都是支持ACID 的强事务机制。 • NoSQL中，通常有两个层次的一致性：第一 种是强一致性，即集群中的所有机器状态 同步保持一致。第二种的最终一致性，既 可以允许短暂的数据不一致，但数据最终 会保持一致。
CAP原理
• 分布式系统中，有三种重要的属性，分别是： • 一致性(Consistency)：任何一个读操作总是能读 取到之前完成的写操作结果，也就是在分布式环 境中，多点的数据是一致的。 • 可用性(Availability)：每一个操作总是能够在 确定的时间内返回，也就是系统随时都是可用的。 • 分区容忍性(Tolerance of network Partition)： 在出现网络分区（比如断网）的情况下，分离的 系统也能正常运行。
MongoDB
• MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。主要 解决的是海量数据的访问效率问题，为WEB应用提供可扩展的高性能 数据存储解决方案。当数据量达到50GB以上的时候，MongoDB的数据 库访问速度是MySQL的10倍以上。MongoDB的并发读写效率不是特别出 色，根据官方提供的性能测试表明，大约每秒可以处理0.5万~1.5万 次读写请求。MongoDB还自带了一个出色的分布式文件系统GridFS， 可以支持海量的数据存储。 • MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关 系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非 常松散，是类似json（基于JavaScript语言的轻量级的数据交换格式） 的bjson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点 是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语 言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还 支持对数据建立索引。
MongoDB
• 所谓“面向集合”（Collenction-Orented），意思是数据被分组存 储在数据集中，被称为一个集合（Collenction)。每个 集合在数据 库中都有一个唯一的标识名，并且可以包含无限数目的文档。集合的 概念类似关系型数据库（RDBMS）里的表（table），不同的是它不需 要定 义任何模式（schema)。 • 模式自由（schema-free)，意味着对于存储在mongodb数据库中的文 件，我们不需要知道它的任何结构定义。如果需要的话，你完全可以 把不同结构的文件存储在同一个数据库里。 存储在集合中的文档，被存储为键-值对的形式。键用于唯一标识一 个文档，为字符串类型，而值则可以是各中复杂的文件类型。我们称 这种存储形式为BSON（Binary Serialized dOcument Format） MongoDB服务端可运行在Linux、Windows或OS X平台，支持32位和64位应 用，默认端口为27017。推荐运行在64位平台，因为MongoDB在32位模 式运行时支持的最大文件尺寸为2GB
为什么使用NoSQL数据库
• 对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时 生成动态页面和提供动态信息，所以基本 上无法使用动态页面静态化技术，因此数 据库并发负载分成高，往往要达到每秒上 万次的读写请求。关系数据库应付上万次S QL查询还勉强顶得住，但是应付上万次SQL 写数据请求，硬盘IO就已经无法承受了。 其实对于普通的BBS网站，往往也存在对高 并发写请求的需求。
一致性or可用性
• 下面是一个牺牲一致性换取可用性的小例子。 • 假设N1和N2是分布式环境下的两个节点，它们有保存了共 同的数据V，它们的值都是V0，A和B是两个分别对数据进 行操作的进程。我们看看这么一个过程：A向N1节点写入 了新的V值V1，B读取V的值。
如果一切正常的话，这个过程看起来像是这样的：
从客户端角度看一致性
• 强一致性：读取到的数据总是最新的。 • 弱一致性：读取到的数据不一定是最新的。 • 最终一致性：属于弱一致性，不同的是， 最终一致性的系统会在后台异步地更新所 有的备份，所以最终所有的备份都会是最 新的数据。
从服务器端角度看一致性
• 我们利用一个数学模型来分析一下服务器端对于一致性的实现 • N：存储备份的节点数目，可以理解为备份的数目。 • W：更新（写）操作成功之前所必须更新的最少备份数目。假设W=3， 表示至少等到3个备份的数据得到更新时，更新操作才算完成。 • R：读操作所需要连接的最少备份数目。假设R=3，表示读取一个数据 时，至少要读取到这个数据的3个备份，然后选其中最新的备份。