储和管理NoSQL分析

1.大数据时代2.关系数据库的瓶颈3.NoSQL简介4.CAP理论5.NoSQL数据模型及分类6.NoSQL应用现状7.几个典型的NoSQL第7章大数据时代的数据存储和管理---NoSQL随着网民参与互联网产品和应用的程度越来越深，互联网将更加智能，互联网的数据量也将呈爆炸式增长。1.大数据时代•大交易数据：来自电商的数据，包括B2B、B2C、C2C、团购等•大交互数据：来自社交网络的数据，SNS、微博等•两类数据的有效融合将是大势所趋，这种融合更能增强企业的商业洞察力4GBTBPBEBZB想驾驭这庞大的数据，我们必须了解大数据的特征。地球上至今总共的数据量：在2006年，个人用户才刚刚迈进TB时代，全球一共新产生了约180EB的数据；在2011年，这个数字达到了1.8ZB。而有市场研究机构预测：到2020年，整个世界的数据总量将达到35.2ZB（1ZB=10亿TB）！1PB=2^50字节1EB=2^60字节1ZB=2^70字节大数据时代大数据时代的爆炸增长何为大？___数据度量1Byte=8Bit1KB=1,024Bytes1MB=1,024KB=1,048,576Bytes1GB=1,024MB=1,048,576KB=1,073,741,824Bytes1TB=1,024GB=1,048,576MB=1,099,511,627,776Bytes1PB=1,024TB=1,048,576GB=1,125,899,906,842,624Bytes1EB=1,024PB=1,048,576TB=1,152,921,504,606,846,976Bytes1ZB=1,024EB=1,180,591,620,717,411,303,424Bytes1YB=1,024ZB=1,208,925,819,614,629,174,706,176Bytes《红楼梦》含标点87万字（不含标点853509字）每个汉字占两个字节：1汉字=16bit=2*8位=2bytes1GB约等于671部红楼梦1TB约等于631,903部1PB约等于647,068,911部美国国会图书馆藏书（151,785,778册）（2011年4月：收录数据235TB）中国国家图书馆：2631万册1EB=4000倍美国国会图书馆存储的信息量MGI估计,全球企业2010年在硬盘上存储了超过7EB(1EB等于10亿GB)的新数据,同时,消费者在PC和笔记本等设备上存储了超过6EB新数据7“大量化(Volume)、多样化(Variety)、快速化(Velocity)、价值密度低（Value）”就是“大数据”的显著特征，或者说，只有具备这些特点的数据，才是大数据。VolumeVelocityValueVariety大数据的4V特征8密不可分的大数据与云计算商业模式驱动应用需求驱动云计算本身也是大数据的一种业务模式大数据是落地的云•云计算的模式是业务模式，本质是数据处理技术。•数据是资产，云为数据资产提供存储、访问和计算。•当前云计算更偏重海量存储和计算，以及提供的云服务，运行云应用，但是缺乏盘活数据资产的能力，挖掘价值性信息和预测性分析，为国家、企业、个人提供决策和服务，是大数据核心议题，也是云计算的最终方向。9结构化数据向非结构化数据演进，使得未来IT投资重点不再是建系统为核心，而是围绕大数据为核心；海量数据可以在各个部门创造重大的财物价值，未来投资倾斜。未来IT投资重心转移10政府、金融、电信等行业投资建立大数据的处理分析手段，实现综合治理、业务开拓等目标；应用到制造等更多行业。大数据的应用大数据相关技术(1)存储o结构化数据：•海量数据的查询、统计、更新等操作效率低o非结构化数据•图片、视频、word、pdf、ppt等文件存储•不利于检索、查询和存储o半结构化数据•转换为结构化存储•按照非结构化存储•存储问题解决方案o在CAP理论指导下数据库技术适当“退化”•NoSQL技术：HDFS,HBASE,OceanBase,MongoDB等大数据相关技术(2)计算o因结构变化为导致计算模式变更o需求模式变化带来的计算碰到瓶颈(3)解决方案oHadoop（MapReduce技术）o流计算（twitter的storm和yahoo！的S4）大数据的研究方向•关系数据库如何应对大数据?(1)Highperformance–高并发读写的需求问题：数据库读写压力巨大，硬盘IO无法承受解决方案：Master-Slave，主从分离分库、分表，缓解写压力，增强读库的可扩展性2、关系数据库的瓶颈(2)HugeStorage–海量数据的高效率存储和访问的需求问题：存储记录数量有限，SQL查询效率极低解决方案：分库、分表，缓解数据增长压力关系数据库的瓶颈(3)HighScalability&&HighAvailability-–高可扩展性和高可用性的需求在关系数据库中解决数据库扩展性的思路主要有两个水平分区（数据分片sharing）或垂直分区（功能业务分区）。这样虽然可以很好解决数据库的扩展性问题，但是在实际使用中，一旦采用了数据分片或者功能分区，必然导致牺牲“关系型”数据库的最大优势-join，对业务的局限性会很大，而且数据库也退化成为一个简单的存储系统。Master-Slave复制方式通过读写分离在某种程度上解决扩展性的问题，但是这种方案中，由于每个数据库节点必须保存所有的数据，这样每个存储的IO必然会成为扩展的瓶颈，并且master也是一个瓶颈•解决方案的问题分库分表缺点：（1）受业务规则影响，需求变动导致分库分表的维护复杂（2）系统数据访问层代码需要修改Master-Slave缺点:（1）Slave实时性的保障，对于实时性很高的场合可能需要做一些处理（2）高可用性问题，Master就是那个致命点，容易产生单点故障关系数据库的瓶颈3.NoSQL简介•什么是NoSQL？NoSQL是NotOnlySQL的缩写，而不是NotSQL它不限于SQL，它是一类范围非常广泛的数据持久化解决方案，它不一定遵循传统数据库的一些基本要求，比如说遵循SQL标准、ACID属性、表结构等等。也不使用SQL作为查询语言。它是1998年开始的一个由CarloStrozzi发起的一项运动，这项运动的主旨就是“要找到存储和检索数据的其他高效的途径，而不是盲目地在任何情况下都把关系数据库当作万金油”18BASE模型BasicallyAvailable(基本可用)：支持分区失败Soft-state(软状态)：状态可以有一段时间不同步Eventuallyconsistent(最终一致)：最终数据是一致的19NoSQL的优势:（1）易扩展NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。甚至有多种NoSQL之间的整合。（2）灵活的数据模型NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。20NoSQL的优势（3）高可用NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。（4）大数据量，高性能NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。21NOSQL缺点很难实现数据的完整性。缺乏强有力的技术支持。开源数据库从出现到用户接受需要一个漫长的过程。关系型数据库在设计时更能够体现实际要求。22NoSQL和关系型数据库的区别(1)横向和纵向扩展能力关系型数据库通常部署在一台服务器上，通过增加处理器、内存和硬盘来升级。部署在多台服务器上的关系型数据库通常是依赖互相复制来保持数据同步。NoSQL数据库可以部署在单服务器上．但更多的部署是成云状分布。(2)列，key/value存储，数组(Tuples)存储关系型数据库通常是由表或视图里的字段构成(固定的结构，用各种操作相互关联)。NoSQL数据库通常存储的是一对键值或数组(Tuples)，其结构不周定，只是一个有顺序的数据队列。23NoSQL和关系型数据库的区别(3)数据的内存和硬盘使用关系型数据库通常是驻留在一个硬盘内或一个网络存储空间里。查询或存储过程操作会把数据集提取到内存空间里。一些(并不是全部)NoSQL数据库可以直接在硬盘上操作，也可以通过内存来加快速度。24SQL与NOSQL在应用上的比较SQLNOSQL----------------------------------------------重量级轻量级贵便宜商业开源成熟时尚、风险企业通用特定领域、互联网25•分布式数据系统的CAP原理的三要素：•一致性(Consistency)•可用性(Availability)•分区容忍性(Partitiontolerance)一致性（Consistency）是指执行了一次成功的写操作之后，未来的读操作一定可以读到这个写入的值。可用性（Availability）(指的是快速获取数据)每一次操作总是能够在确定的时间返回。分区容忍性（Partition-tolerance）系统中任意信息的丢失或失败不会影响系统的继续运作。4.CAP原理•CAP原理：在分布式系统中，这三个要素最多只能同时实现两点，不可能三者兼顾。对大型网站，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着A、P的方向设计，然后通过其它手段保证对于一致性的商务需求。当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的。27最终一致性(eventuallyconsistent)对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何将复制分布到整个系统，以保证数据最终一致。一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。28从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。对于分布式数据系统：N—数据复制的份数W—更新数据是需要保证写完成的节点数R—读取数据的时候需要读取的节点数如果W+RN，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则不管读的是主库还是备库的数据，都是一致的。如果W+R=N，则是弱一致性。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。29对于分布式系统，为了保证高可用性，一般设置N=3。不同的N,W,R组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。如果N=R,W=1，只需要一个节点写入成功即可，写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据