大数据内存数据库与NoSql数据库Word文档下载推荐.docx
《大数据内存数据库与NoSql数据库Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《大数据内存数据库与NoSql数据库Word文档下载推荐.docx(21页珍藏版)》请在冰豆网上搜索。
传统RDBMS表关联
◆有限关联;
◆性能问题;
◆一系列限制;
传统关系型数据库IO面临的挑战
核心业务正在面临数据计算扩展能力的挑战
增加或减少Web和
应用服务器数据的扩展只能依赖于移到更大处理能力的机器上Web和应用层很容易扩展及虚拟化,节点可以灵活地增加或减少共享文件系统能够被虚拟化,按需进行增长Web层
应用层
数据库层
存储层
负载均衡器
内存数据库
•内存数据库,顾名思义就是将数据放在内存中直接操作的数据库。
相对于磁盘,内存的数据读写速度要高出几个数量级,将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。
•同时,内存数据库抛弃了磁盘数据管理的传统方式,基于全部数据都在内存中重新设计了体系结构,并且在数据缓存、快速算法、并行操作方面也进行了相应的改进,所以数据处理速度比传统数据库的数据处理速度要快很多。
(双通道DDR3-1333可以达到9300MB/s,一般磁盘约150MB/s,
随机访问时间更是可以纳秒级(一般磁盘约10ms,双通道DDR3-1333可以达到0.05ms。
•内存数据库的最大特点是其“主拷贝”或“工作版本”常驻内存,即活动事务只与实时内存数据库的内存拷贝打交道。
显然,它要求较大的内存量,但并非任何时刻整个数据库都存放在内存,即内存数据库系统还是要处理I/O
NoSQL概念
•NoSQL(NoSQL=NotOnlySQL,指的是非关系型的数据库。
•关系型数据库中的表都是存储一些格式化的数据结构,每个元组字段的组成都一样,即使不是每个元组都需要所有的字段,但数据库会为每个元组分配所有的字段,这样的结构可以便于表与表之间进行连接等操作,但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。
•非关系型数据库以键值对存储,它的结构不固定,每一个元组可以有不一样的字段,每个元组可以根据需要增加一些自己的键值对,这样就不会局限于固定的结构,可以减少一些时间和空间的开销。
NoSQL特点
它们可以处理超大量的数据。
它们运行在便宜的PC服务器集群上。
PC集群扩充起来非常方便并且成本很低,避免了“sharding”操作的复杂性和成本。
它们击碎了性能瓶颈。
通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL格式的时间,执行速度变得更快。
没有过多的操作。
关系数据库提供了无可比拟的功能集合,而且在数据完整性上也发挥绝对稳定,但对于某些企业的具体需求可能不需要那么多。
NoSQL产品
•Redis内存数据库•MongoDB文档数据库
•Neo4j图数据库
•Hbase列数据库
•Hadoop分布式计算模型•GemFire商用内存数据库•timesTenOracle商用内存数据库
Redis
Redis与Memcached
•共同特征
•都是key-value形式的内存数据库
•都是NoSQL家族的数据管理解决方案
•都基于同样的key-value数据模型
•所有数据全部放在内存中(这也是适用于缓存的原因•性能得分不分伯仲,包括数据吞吐量和延迟等指标•都是成熟的、广受开源项目欢迎的key-value存储系统
•有硬盘存储支持的内存数据库,
•支持Master-slave复制
•虽然采用简单数据或以键值索引的哈希表,但也支持复杂操作,例如ZREVRANGEBYSCORE。
•INCR&
co(适合计算极限值或统计数据
•支持sets(同时也支持union/diff/inter
•支持列表(同时也支持队列;
阻塞式pop操作
•支持哈希表(带有多个域的对象
•支持排序sets(高得分表,适用于范围查询
•Redis支持事务
•支持将数据设置成过期数据(类似快速缓冲区设计
•Pub/Sub允许用户实现消息机制
•最佳应用场景:
适用于数据变化快且数据库大小可遇见(适合内存容量的应用程序。
•例如:
股票价格、数据分析、实时数据搜集、实时通讯。
•内存数据库
•单核
•value限制512M
•多种value类型,游戏用途使用私有的序列化协议(例如protobuf•支持落地(bgsave
•用户:
新浪,淘宝,Flickr,Github
•应用场景:
适合读写都很高,数据处理复杂等
Redis速度
•SET操作每秒钟110000次,GET操作每秒钟81000次,•服务器配置如下:
Linux2.6,XeonX33202.5Ghz.
Redis用武之地
•使用Redis作为缓存,通过调优缓存内容,系统效率能获得极大提升。
•很明显Redis的优势在于缓存管理。
缓存通过某种数据回收机制(dataevictionmechanism在必要时将旧数据从内存中删除,为新数据腾出空间。
Redis允许细粒度控制过期缓存,有6种不同的策略可供选择。
Redis还采用了一些更复杂的内存管理方法和回收策略。
•Redis对缓存的对象提供更大的灵活性。
是二进制安全的【即不丢数据,与编码无关】。
Redis提供6种数据类型,使缓存以及管理缓存变得更加智能和方便。
•Redis通过Hash来存储一个对象的字段和值,并可以通过单个key来管理它们。
•而使用RedisHash的方式,可以大幅度降低资源消耗并提高性能。
Redis的其他数据类型,如List或者Set,可用来实现更复杂的缓存管理模式。
•160多个命令中的大部分都可以用来进行数据操作,所以通过服务端脚本调用进行数据处理成为现实。
这些内置命令和用户脚本可以让你直接灵活地处理数据任务,而无需通过网络将数据传输给另一个系统进行处理。
•Redis提供了可选/可调整的数据持久化,目的是为了在崩溃/重启后可以快速加载缓存。
•最后,Redis提供主从复制(replication。
Replication可用于实现高可用的cache系统,允许某些服务器宕机的情况下也能提供不间断的服务。
•需要使用缓存来提高应用系统性能时,Redis和Memcached是最佳的产品级解决方案。
但考虑到其丰富的功能和先进的设计,绝大多数时候Redis都应该是你的第一选择。
Hbase特点
•特点:
支持数十亿行X上百万列
•在BigTable之后建模
•采用分布式架构Map/reduce
•对实时查询进行优化
•高性能Thrift网关
•通过在server端扫描及过滤实现对查询操作预判•支持XML,Protobuf,和binary的HTTP•Cascading,hive,andpigsourceandsinkmodules•基于Jruby(JIRB的shell
•对配置改变和较小的升级都会重新回滚
•不会出现单点故障
•堪比MySQL的随机访问性能
Hbase存储特点
•假如系统中有一个User表,如果按照传统的RDBMS的话,User表
中的列是固定的,比如schema定义了name,age,sex等属性,User
的属性是不能动态增加的。
•但是如果采用列存储系统,比如Hbase,那么我们可以定义User表,然后定义info列族,User的数据可以分为:
info:
name=zhangsan,info:
age=30,info:
sex=male等,如果后来你又想增加另外
的属性,这样很方便只需要info:
newProperty就可以了。
MongoDB
•DB-Engines公布了2014年年度最受欢迎数据库管理系统
•自从公布此榜单两年以来,MongoDB已经二度成为最受欢迎的NoSQL数据库。
MongoDB最大的特点是它支持的查询语言非常大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引,这也是其如此受欢迎的原因之一
•在开源的、面向文档的数据库中,MongoDB经常被誉为具有RDBMS功能的NoSQL数据库。
•MongoDB还带有交互式shell,这使得访问其数据存储变得简单,且其对于分块的即装即用的支持能够使高可伸缩性跨多个节点。
i7四核8G,insert一次20万,循环10次,总共200万数据用时65秒。
Insert语句及存储示例:
>
db.person.insert({name:
"
test"
age:
40};
tianmj"
desc:
{height:
170,weight:
80}};
db.person.find(;
{"
_id"
:
ObjectId("
559388bf52a9ffe7970065bf"
"
name"
"
age"
40}
559388bf52a9ffe7970065c0"
desc"
{"
height"
170,"
weight"
80}}>
db.person.find({age:
{$gt:
30}};
db.person.find({"
desc.height"
:
130}};
80}}
MongoDB特点
保留了SQL一些友好的特性(查询,索引。
•Master/slave复制(支持自动错误恢复,使用sets复制
•内建分片机制
•支持javascript表达式查询
•可在服务器端执行任意的javascript函数
•update-in-place支持比CouchDB更好
•在数据存储时采用内存到文件映射
•对性能的关注超过对功能的要求
•采用GridFS存储大数据或元数据(不是真正的文件系统
适用于需要动态查询支持;
需要使用索引而不是map/reduce功能;
需要对大数据库有性能要求;
MongoDB与Hbase
•1.Mongodbbson文档型数据库,整个数据都存在磁盘中,hbase是列式数据库,集群部署时每个familycolumn保存在单独的hdfs文件中。
•2.Mongodb主键是“_id”,主键上面可以不建索引,记录插入的顺序和存放的顺序一样,hbase的主键就是rowkey,可以是任意字符串(最大长度是64KB,实际应用中长度一般为10-100bytes,在hbase内部,rowkey保存为字节数组。
存储时,数据按照Rowkey的字典序(byteorder排序存储。
•3.Mongodb支持二级索引,而hbase本身不支持二级索引
•4.Mongodb支持集合查找,正则查找,范围查找,支持skip和limit等等,是最像mysql的nosql数据库,而hbase只支持三种查找:
通过单个rowkey访问,通过rowkey的range,全表扫描
•5.mongodb的update是update-in-place,也就是原地更新,除非原地容纳不下更新后的数据记录。
而hbase的修改和添加都是同一个命令:
put,如果put传入的rowkey已经存在就更新原记录,实际上hbase内部也不是更新,它只是将这一份数据已不同的版本保存下来而已,hbase默认的保存版本的历史数量是3。
•6.mongodb的delete会将该行的数据标示为已删除,将该删除记录数据置空,这种方法会提升性能。
•7.mongodb和hbase都支持mapreduce,不过mongodb的mapreduce支持不够强大,如果没有使用mongodb分片,mapreduce实际上不是并行执行的
•8.mongodb支持shard分片,hbase根据rowkey自动负载均衡,这里shardkey和rowkey的选取尽量用非递增的字段,尽量用分布均衡的字段,因为分片都是根据范围来选择对应的存取server的,如果用递增字段很容易热点server的产生,由于是根据key的范围来自动分片的,如果key分布不均衡就会导致有些key根本就没法切分,从而产生负载不均衡。
•9.mongodb的读效率比写高,hbase默认适合写多读少的情况。
•10.hbase采用的LSM思想(Log-StructuredMerge-Tree,就是将对数据的更改hold在内存中,达到指定的threadhold后将该批更改merge后批量写入到磁盘,这样将单个写变成了批量写,大大提高了写入速度,但降低了读的性能。
mongodb采用的是mapfile+Journal思想,如果记录不在内存,先加载到内存,然后在内存中更改后记录日志,然后隔一段时间批量的写入data文件,这样对内存的要求较高,至少需要
容纳下热点数据和索引。
Neo4j图数据库
•node(节点
•每个节点可以和多个节点之间建立多个关系(relationship
•单个节点可以设置多个(Key,Value的properties属性的键值对•relationships(关系
•每个关系都会包含一个startNode和endNode
•每个关系可以设置多个(Key,Value的properties属性的键值对
•可以为关系定义对应的关系类型(RelationshipType
*DynamicRelationshipType动态关系类型
*XXXRelationshipType静态关系类型(实现了RelationshipType接口
Neo4j特点
•可独立使用或嵌入到Java应用程序
•图形的节点和边都可以带有元数据
•很好的自带web管理功能
•使用多种算法支持路径搜索
•使用键值和关系进行索引
•为读操作进行优化
•支持事务(用Javaapi
•使用Gremlin图形遍历语言
•支持Groovy脚本
•支持在线备份,高级监控及高可靠性支持使用AGPL/商业许可
•
适用于图形一类数据。
这是Neo4j与其他nosql数据库的最显著区别•例如:
社会关系,公共交通网络,地图及网络拓谱
HADOOP
GemFire
•GemFire的第一个版本发布于2002年3月份,当时它还属于一家独立的公司GemStoneSystems.后来GemStoneSystem这家公司被VMware给收购了,GemFire也被整合到了VMwareVfabric产品线。
请注意,VMWare当时也收购了Redis项目。
•在2013年4月EMC与VMware/GE合资成立一家新公司Pivotal,VMware慷慨的贡献出了它的vfabric产品线,以及它收购的一些开源项目。
•目前,GemFire的商业版权已经属于Pivotal了。
顺便说一句,Redis的创始人SalvatoreSanfilippo现在也供职于Pivotal.
1.分布式数据存储
•稳定而高性能的的基于内存的数据数据存储
•灵活的Cache部署策略:
点对点(peertopeer;
客户端/服务端(clientserver;
多集群(multipleclusters的本地或远程数据同步,支持数据高性能灾备和双活
•灵活的Region(数据对象集或者可理解为表分布式处理:
同一集合数据(可理解为一个表的数据可以整集多点同步或切割后不同点保存,并支持数据实时再平衡(rebalance既数据分隔保存后若加入新的空闲服务器,数据可以在不重启服务的情况下重新切割和平衡数据,从而达到真正的数据在线动态延展
•具有持续性的数据高可用性和容错性:
各个分散的数据点可以配置一个或多个基于内存的热备数据点,当主数据点宕机的情况下,其中一个热备点就会提升称为主数据点,同时可以继续在空闲机器上创建备份点,从而达到数据的持续的可用性。
同时数据可以通过配置同步或异步地持续化到本地硬盘,或者到指定的数据库或文件中。
•数据地客户端缓存:
客户端可以将最常用数据缓存一个备份与本地,进一步加快效能
•在线数据备份
•数据全内存和部分内存策略:
通过配置可以将数据全部存入内存,或者通过将非频繁使用数据挤出策略(LRU来将部分频繁适用数据保存于内存中达到成本效益最大化
•内置资源优化器用以降低JAVAGC所带来的延迟,支持单个大容量Cache点(一般服务器可配置超过40GB内存的Javaheapsize
•安全支持:
基于用户和角色的数据访问,数据传输渠道加密(SSL•数据存取除key-value简单cache支持外,支持复杂数据对象和关系存储
•丰富的OQL(类SQL的查询语言支持
•支持数据单记录或批处理
•本地或分布式事务处理
•Map-Reduce并行查询:
同一查询命令可并行发送到各Cache点(Map,结果集自动在客户端汇合(Reduce
•智能定点查询:
查询命令在包含数据特征如主键值时,查询命令会自动命中数据点
LoadBalancer
WebandAppServers
ApplicationTier
MiddlewareTier
DatabaseTier
OS
App
在NoSQL领域,利用弹性的数据网格计算架构,为业务系统提供高并发、低延迟的数据处理能力,同时保障数据的最终一致性和完整性
AppMemoryTierDataGridinMemory
GemFire典型的几种部署方式
Shoppingcartstate
managementHighperformanceOLTP▪Shareddatagridpopulatedby
multipledatafeedsandserving
manyclients
▪Abilitytoexecuteapplogicin
clientsand/orwithinthedata
griditself
HTTPSessionStateManagementandL2CacheApplicationServers
GemFireAppDataCache,In-memoryDBGemFire
ClientClientClientClientClientClientGlobalDataBackbone
ClientClientClientClientClientClientGemFire
使用场景
▪商业银行信用卡用户行为实时分析及附加服务的提供▪商业银行信用卡反欺诈实时分析和监控
▪商业银行客户关系管理系统报表查询及分析
▪商业银行主机系统日间/夜间批量对账
▪投资银行外汇交易
▪投资银行金融衍生品风险评估和定价
▪大型在线订票网站火车票余额查询
▪大型航空信息提供商机票信息查询和产品定价
▪交通运输行业实时道路车辆监控
▪娱乐网站实时在线广告推送
▪等等
12306
•12306从2012年3月开始改造,采用10几台X86服务器实现了以前数十台小型机的余票计算和查询能力,单次查询的最长时间从之前的15秒左右下降到0.2秒以下,缩短了75倍以上。
2012年春运的极端高流量并发情况下,系统几近瘫痪。
而在改造之后,支持每秒上万次的并发查询,高峰期间达到2.6万个查询/秒吞吐量
pv就是访问者打开了你的几个页面
•高流量方面,主要涉及低延迟的余票查询。
Gemfire支持类Map-Reduce并行处理,能够按车次将余票、共用定义等数据拆分成多个独立的计算单元,对余票查询中最耗时的共用定义部分做预先处理,生成查询缓存。
当余票数据发生变化时,系统会动态更新查询缓存。
有了预处理及数据同步过程维护的动态查询缓存,单次查询可以控制在10ms-300ms之间,同时10分钟的固有延迟也不存在了。
•订单查询系统改造,在改造之前的系统运行模式下,每秒只能支持300-400个QPS的吞吐量,高流量的并发查询只能通过分库来实现。
改造之后,可以实现高达上万个QPS的吞吐量,而且查询速度可以保障在20毫秒左右。
新的技术架构可以按需弹性动态扩展,并发量增加时,还可以通过动态增加X86服务器来应对,保持毫秒级的响应时间。
•在以往的春运期间,12306售票系统部署Gemfire集群在2个数据中心,提供服务。
•在2015年春运购票高峰之前,考虑到超大并发会造成网络流量大以及阻塞的问题,特别在阿里云建立一个数据中心,由阿里云提供“虚拟机”的租赁服务,将基于Gemfire实现余票查询功能的系统以及Web服务部署在这些虚拟机上,以分流“余票查询”请求,解决因为高峰期超高并发造成的网络阻塞问题,以进一步提高服务品质。
为此,12306在2014年下半年在阿里云做了小规模的部署和调试。
2015年春运购票高峰期的12306高效平稳运行,也验证了混合架构的可行性。