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