《YunTable-云时代的数据库》由会员分享，可在线阅读，更多相关《YunTable-云时代的数据库（27页珍藏版）》请在金锄头文库上搜索。
1、YunTable -云时代的数据库,目录,云计算时代的数据库 YunTable的简介和设计 NoSQL产品之间的比较 YunTable的使用场景 YunTable今后的规划,自我介绍,吴朱华 CSDN和TechTarget特邀云计算专家。 曾在IBM中国研究院参与过多款云计算产品的开发工作，包括著名的IBM WebSphere CloudBurst。 现正专注于YunTable和YunEngine这两个新一代云计算产品的开发工作，并即将发表剖析云计算一书。,云计算时代的数据库,云计算时代的需求,低延迟的读写速度：应用快速地反应能极大地提升用户的满意度； 支撑海量的数据和流量：对于搜索这样大型应
2、用而言，需要利用PB级别的数据和能应对百万级的流量； 大规模集群的管理：系统管理员希望分布式应用能更简单的部署和管理； 庞大运营成本的考量：IT经理和CFO们都希望在硬件成本、软件成本和人力成本上面能够有大幅度地降低；,关系型数据库的限制,扩展困难：由于存在类似Join这样多表查询机制，使得数据库在扩展方面很艰难； 读写慢：这种情况主要发生在数据量达到一定规模时由于关系型数据库的内部逻辑非常复杂，使得其很容易发生死锁等的并发问题，而这将导致其读写速度下滑严重； 成本高：企业级数据库的License价格很惊人，并且随着系统的规模，而不断上升； 有限的支撑容量：现有关系型解决方案还无法支撑Goog
3、le这样海量的数据存储；,NoSQL数据库,业界为了解决前面提到的几个需求，推出了多款新类型的数据库，并且由于它们在设计上和传统的SQL数据库相比有很大的不同，所以被统称为“NoSQL”。 在设计上，NoSQL非常关注对数据高并发地读写和对海量数据的存储等。在我看来，它与关系型数据库相比，在架构和数据模型方面做了“减法”，而在扩展和并发等方面做了“加法”。 主要产品有：BigTable、HBase、Redis、Cassandra和MongoDB等。,NoSQL数据库的优势,简单的扩展：典型例子是Cassandra，由于其架构是类似于经典的P2P，能轻松地添加新的节点来扩展这个集群； 并发的读写
4、：主要例子有Redis，由于其逻辑简单，而且纯内存操作，使得其性能非常出色； 低廉的成本：这是大多数分布式数据库共有的特点，因为主要是开源软件，没有昂贵的License成本。,NoSQL数据库的不足之处,不提供对SQL的支持：如果不支持SQL这样的工业标准，将会对用户产生一定的学习和应用迁移成本； 支持的特性不够丰富：现有产品所提供的功能都比较有限，大多数NoSQL数据库都不支持事务，也不像MS SQL Server那样能提供各种强大的附加功能； 现有产品的不够成熟：大多数产品都还处于初创期，和关系型数据库几十年的完善不可同日而语；,YunTable的简介和设计,YunTable的简介,在研发
5、YunEngine的时候，发现在业界还缺乏一款在架构上非常简洁，并可适应多种云计算场景的NoSQL数据库，所以在那时就开始进行研发YunTable了。 YunTable的目标不是做一个类似BigTable这样比较大而全的数据库，而主要是做一个精简版的分布式Key-Value数据库，上层的云计算应用将会根据其自身的需求去利用YunTable或者做修改，从而使YunTable能适应云计算各种场景，并且非常易用。 现在已经在10月初正式开源，并发布其0.8版，项目地址http:/ 在数据模型方面基于Key-Value； 在分布式架构方面采用了Single-Master的设计； 在存储方面利用了SST
6、able的格式； 其次，在结构方面，YunTable主要有两大模块组成： Master节点：作用是管理整个YunTable集群，在集群中只存在一个。 Region节点：作用是存储数据，在集群中会有多个。,Key-Value,Key-value这种数据模型在结构方面和传统的关系型相比较简单，有点类似常见的HashTable，一个Key对应一个Value，但是其能提供非常快的查询速度、大的数据存放量和高并发地操作，并非常适合通过主键（Key）来对数据进行查询和修改等操作，虽然不支持复杂的操作，但是可以通过上层的开发来弥补这个缺陷。,Single-Master,在分布式的设计上面，选择了在语义和实现
7、上都非常简单明了的Single Master模式来管理整个集群。 一般来说，一个Master节点能管理上千个Region节点，为了能管理这样大的集群，所以Master节点只负责Region节点之间数据的分布，实际数据的处理则与Master无关，而由Client端和Region节点之间进行交互来完成。 为了避免Master出现单点失败的情况，YunTable将在今后版本中引入Shadow-Master这种机制。,SSTable,简单而言，SSTable是一个用于存储已排序Key-Value对的文件格式，并且是不可变动的（Immutable），也就是写了之后，只能将其更新附加在其之后，而不能直接进
8、行修改，这样是为了让系统能执行Disk所擅长的顺序访问，而不是随机访问。 在内部格式方面，SSTable文件主要有Index和Data Block这两部分组成。 在实际运行时，系统常会把Index载入内存，以确保查询的效率。,YunTable的架构,如何适应不同的云计算环境,云计算主要常见的有两类场景： 需要低延迟和高并发的读写能力（类似OLTP）。 海量数据的存储和操作（类似OLAP）。 那么YunTable是如何适应这两种环境？ 首先，坚持Key-Value、Single-Master和SSTable这样经典和通用的设计。 其次，在数据存储方面，加入Hotness这个机制，主要是通过设置H
9、otness值来决定之前为了完成查询而读取到内存中的Data Block的生存时间，假设如果是低延迟的情况，那么将Hotness值设置长一点，如果是海量数据，则相反。,NoSQL产品之间的比较,主要的NoSQL数据库,BigTable/HBase：在数据模型上面属于Column-Family，采用了Single Master的分布式架构，主要为了存储海量的数据，不强调低延迟。 Cassandra：在数据模型方面继承BigTable，也是Column-Family ，采用Dynamo的机制，其分布式架构类似P2P。 Redis：是Key-Value的，对List和Set这些操作有原生的支持，由于
10、数据集都是放置于内存中，所以读写速度非常快，但是对分布式支持非常有限。 MongoDB：是Document DB，提供功能相对而言，比较完善，在分布式方面，有Replica Sets这样的新一代Master/Slave Replication机制。,NoSQL数据库之间的比较,YunTable的使用场景,具体场景,PaaS平台：由于PaaS平台的需求比较复杂，所以需要对其后台的数据库进行很多定制化，而YunTable由于其架构简单，所以非常适合，这方面的例子有YunEngine。 Key-Value的数据存储：YunTable现在已提供名为YunCli的命令行，通过这个命令行能够方便上传和查询基于Key-Value格式的数据，将来也会提供相应的SDK。,YunEngine,YunCli,YunTable今后的规划,具体的里程碑,
