YunTable-云时代的数据库.ppt

目录 云计算时代的数据库 YunTable的简介和设计 NoSQL产品之间的比较 YunTable的使用场景 YunTable今后的规划 自我介绍 吴朱华 CSDN和TechTarget特邀云计算专家。 曾在IBM中国研究院参与过多款云计算产品的开发工作，包括著名的IBM WebSphere CloudBurst。 现正专注于YunTable和YunEngine这两个新一代云计算产品的开发工作，并即将发表《剖析云计算》一书。 云计算时代的数据库 云计算时代的需求 低延迟的读写速度：应用快速地反应能极大地提升用户的满意度； 支撑海量的数据和流量：对于搜索这样大型应用而言，需要利用PB级别的数据和能应对百万级的流量； 大规模集群的管理：系统管理员希望分布式应用能更简单的部署和管理； 庞大运营成本的考量：IT经理和CFO们都希望在硬件成本、软件成本和人力成本上面能够有大幅度地降低； 关系型数据库的限制 扩展困难：由于存在类似Join这样多表查询机制，使得数据库在扩展方面很艰难； 读写慢：这种情况主要发生在数据量达到一定规模时由于关系型数据库的内部逻辑非常复杂，使得其很容易发生死锁等的并发问题，而这将导致其读写速度下滑严重； 成本高：企业级数据库的License价格很惊人，并且随着系统的规模，而不断上升； 有限的支撑容量：现有关系型解决方案还无法支撑Google这样海量的数据存储； NoSQL数据库 业界为了解决前面提到的几个需求，推出了多款新类型的数据库，并且由于它们在设计上和传统的SQL数据库相比有很大的不同，所以被统称为“NoSQL”。 在设计上，NoSQL非常关注对数据高并发地读写和对海量数据的存储等。在我看来，它与关系型数据库相比，在架构和数据模型方面做了“减法”，而在扩展和并发等方面做了“加法”。 主要产品有：BigTable、HBase、Redis、Cassandra和MongoDB等。 NoSQL数据库的优势 简单的扩展：典型例子是Cassandra，由于其架构是类似于经典的P2P，能轻松地添加新的节点来扩展这个集群； 并发的读写：主要例子有Redis，由于其逻辑简单，而且纯内存操作，使得其性能非常出色； 低廉的成本：这是大多数分布式数据库共有的特点，因为主要是开源软件，没有昂贵的License成本。 NoSQL数据库的不足之处 不提供对SQL的支持：如果不支持SQL这样的工业标准，将会对用户产生一定的学习和应用迁移成本； 支持的特性不够丰富：现有产品所提供的功能都比较有限，大多数NoSQL数据库都不支持事务，也不像MS SQL Server那样能提供各种强大的附加功能； 现有产品的不够成熟：大多数产品都还处于初创期，和关系型数据库几十年的完善不可同日而语； YunTable的简介和设计 YunTable的简介 在研发YunEngine的时候，发现在业界还缺乏一款在架构上非常简洁，并可适应多种云计算场景的NoSQL数据库，所以在那时就开始进行研发YunTable了。 YunTable的目标不是做一个类似BigTable这样比较大而全的数据库，而主要是做一个精简版的分布式Key-Value数据库，上层的云计算应用将会根据其自身的需求去利用YunTable或者做修改，从而使YunTable能适应云计算各种场景，并且非常易用。 现在已经在10月初正式开源，并发布其0.8版，项目地址/p/yuntable/。 YunTable的设计 首先，从设计角度而言，YunTable主要从BigTable中借鉴了很多优秀的设计，并进行简化，总体而言，主要有下面这三大特色: 在数据模型方面基于Key-Value； 在分布式架构方面采用了Single-Master的设计； 在存储方面利用了SSTable的格式； 其次，在结构方面，YunTable主要有两大模块组成： Master节点：作用是管理整个YunTable集群，在集群中只存在一个。 Region节点：作用是存储数据，在集群中会有多个。 Key-Value Key-value这种数据模型在结构方面和传统的关系型相比较简单，有点类似常见的HashTable，一个Key对应一个Value，但是其能提供非常快的查询速度、大的数据存放量和高并发地操作，并非常适合通过主键（Key）来对数据进行查询和修改等操作，虽然不支持复杂的操作，但是可以通过上层的开发来弥补这个缺陷。 Single-Master 在分布式的设计上面，选择了在语义和实现上都非常简单明了的Single Master模式来管理整个集群。 一般来说，一个Master节点能管理上千个Region节点，为了能管理这样大的集群，所以Master节点只负责Region节点之间数据的分布，实际数据的处理则与Maste