发帖
雷达卡
2017年中国数据分析师行业峰会：数据库与技术实战_分会场（十）
第四届中国数据分析师行业峰会
主题：数据库与技术实战
时间：2017年7月29日（下午）
地点：中国大饭店
内容：
韩锋：大家下午好，欢迎来到数据库与技术实战的专场，首先我代表主办方对大家的到来表示欢迎！也对有道云笔记对我们提供全场的速记表示感谢！
下午我们安排了7个专题，时间比较紧，专题内容比较多，我们不安排问答环节了。三场后我们有一个短暂的休息时间，下半场开始我们会搞一个小的活动。今天下午我们有请了业内多位资深的专家，带来对数据库的经验和见解，首先有请来自哪儿网的资深DBA蒲聪，有请。
蒲聪：大家好我是去哪儿网资深DBA，今天讲一下“分布式数据库原理和架构设计”。先后6年时间在艺龙、百度都进行过数据库的MySQL和HBase运维管理，现在在去哪儿网也有PB级别的数据量了。
言归正传，分四点讲一下分布式数据库。第一，背景，数据库是如何诞生的。第二，面对大数据过去我们怎么处理，现在怎么处理，未来趋势怎么样。第三，去哪儿调研的开源分布式数据库TiDB。第四，说说TiDB在去哪儿网适用的场景和去哪儿网未来的规划。
第一，分布式数据库的诞生。
数据库是爆炸式增长的，我刚入行的时候，2011年在百度500G磁盘就很大了。到了去哪儿之后开始有了TB，爆炸式的增长。2020年PB对我们来说已经不是一个陌生的字眼了，我们遇到了这么多难题该如何克服？所以就诞生了各种各样的理论。
关系型数据库解决了业界大部分的问题，后来一段时间NoSQL数据库兴起了，关系级数据库本身是没法扩展的。随之而来，随着谷歌入门的开放，亚马逊入门的开放，接着Spanner、CockroachDB这些出来了，一些高效访问的会用OnceanBase里，有一段时间讨论关系型数据库是不是可以消失了。
最近流行的NewSQL数据库，不知道大家有没有用过。比如说原来关系型数据库SQL用着很分辨，在NoSQL里就没有，这是易用性。最重要的是事务的概念，有一段时间NoSQL不要事务了，因为事务本身会造成一定的性能要求，但是这样实现失误的时候难度更大，我们又回归了它希望是有事务的。对于关系型数据库和NewSQL数据库存在着的是什么？关系型数据库不能扩展，取决于硬件是多大就是多大。NoSQL数据库的问题是什么？就是不能支持事务，另外也没有SQL那么方便。
说到数据库的发展，我们不得不说一下谷歌的历程。不管怎么发展，最开始的祖先是谷歌。说说谷歌的故事，我们现在看到的很多产品其实是来自于谷歌的论文，比如说现在很流行虚拟化，最开始来自于谷歌，还也谷歌APP，BigTable论文最开始是它写的，但是谷歌错过了好几波。现在有好几个开源，包括DCOS的调度。2006年之前谷歌也是用关系型数据库的，MySQL，2006年发表了BigTable论文，但是那时候没有SQL的支持，只是支持行的事务，但是不支持跨行的事务。所以开发了MegaStore，至少需要事务ID，它又需要分布式协议。每一次要进行事务ID分配的时候都要走一遍分布式协议，它是高延时的，100—400毫秒之间。
这个过程中谷歌发现，虽然延时和高，但是很多人用。谷歌统计有300个应用在上面，用它的云平台，所以有一个Spanner/F1，全球首个分布式数据库。在MegaStore的基础上，有一个全球是分布式数据库就解决了很多问题。基于这篇论文，就诞生了NewSQL的数据库。
面对大数据我们过去怎么做？现在怎么做？如果是关系型数据库的话，我们采用什么方式？中间层的方式，也就是分布分表。架构是这样的，下面的底层是MySQL，上层有个中间层，根据接收到的命令五考虑分到哪一个MySQL集群中。
根据分布式中间层的架构，历史中诞生了无数个分布式中间件。百度的DDBS，youtube的也有，淘宝的，基于Cobar，360的，京东的。最近两年特别火的是分布式中间件，但是中间件有什么问题呢？第一执行计划，大家知道MySQL是单机的，分布式不适用，分布式事务更难。很多实现了分布式中间层的都有一定的折衷，其实没法实现跨节点的Join，这是第二个。还有延时的问题，以及扩容，4变8，8变16，16变32，32变64，非常复杂。百度以前的扩容，32到64的话，起码要花一个月来准备，非常麻烦。
还有用结合的方式，比如说大字段的，用HBASE来解决，响应比较快的话用REDIS解决，RIAK来解决，这也是相结合的方式。
还有一个概念，OLTP，从MySQL或者其他业务中抽取大业务仓库，用这些东西进行离线的计算，再得出报表，这是过去的方式。
在去哪儿这边有几种数据库，主要的是MySQL，还有redis、spark、麒麟。DBA组目前用的是redis额、MySQL和HBASE。但是现在的趋势不是这样的，最近谷歌新出了一篇论文，这个论文就讲到了一个概念，OLTP+OLAP是融合的时候了，数据库它能支持事务，又能支持离线分析。正好有一个融合的机会，包括谷歌最近出的这个，我们一般关系型数据库是行存储，离线分析是列存储，现在出了一种行列混合的模式，这就很好的加以融合，也是未来的趋势。
这是根据谷歌来的，以后只需要一个简单的客户端，像用MySQL一样，这样用就可以了。F1层主要是负责生成分布式的计划，然后无限的分层扩展就可以了。由此诞生了围绕着谷歌有了一些数据库，OceanBase、蟑螂数据库、TiDB。我们为什么选择TiDB做调研？它不开源。OceanBase他自己内部的版本和外部的版本有点差异，所以我们没有选择。另外他们在杭州，也不能接触到核心。蟑螂数据库在国外，是PG的接口，不太喜欢用。TiDB正好跟我们公司在一起，有很好的支持，我们也进行了很好的调研，发现还不错，所以我们决定调研它、使用它，及时反馈。
现阶段分布式数据库大概的架构都是怎么实现的，首先说一下TiDB是什么。它是兼容MySQL的，但是存储过程可能不兼容，这也是我们不建议在使用中用的。还有兼容、扩容，这是最基本的。作为运营人员，高回路非常重要。设计目标是80%的OLAP和100%的OLTP。他们认为我们一般用的比较负责的分析SQL是可以解决的，但是有一些特别复杂的，比如说能写几百行的，他们不能保证，还支持不了。另外我们都有开源的精神，不多说了。
说说核心特性，也是分布式数据库的特性，水平线性扩展，扩展很好理解，什么是线性？我机器越多我性能越好。故障自恢复高可用，智慧负责怎么理解？传统的主库挂了会到从库，主库有问题的话我要备份，做一个从库出来，这都是耗费人力的。当你机器成百上千，上万，几十万个节点的时候，就不好做了，数据自己移动、平衡就行了。
另外还支持事务，OLAP，在TiDB上，最开始是想OLTP的，实际上有很多的OLAP需求，他们很多都在优化器方面的优化工作。还有跨数据中心数据强一致，谷歌的副本可能有9个，会跨国家，跨州，美国这边挂掉了谷歌实际上是不受影响的，所以跨数据强一致也很重要。
接下来简单说说他们的架构，因为他的灵感来自于谷歌F1和Spanner，一个是负责接MySQL，一个是负责底层的存储。这是一个更详细的图，TiDB、TiKV、PD，这三个大家记住就行了，后面会详细给大家讲一讲。
先讲TiDB，TiDB实际上是无状态的，相当于一个中间层。它所要做的是什么？第一负责接受SQL，第二是执行计划和负责处理计算。他访问哪一个节点都是一样的，你前面加一个HA就可以进行负载均衡，相当于中间层。
PD主要是原数据处理，这个数据到底存储在哪个地方，副本是多了还是少了，负责数据的转移，哪一个负载更高我需要转移一下。另外事务ID的生成，为什么Spanner很难开源？因为生成事务ID他们是用硬件来实现的，是原子钟和GPS结合的方式。
TiKV是存储的，分布式数据库会把数据分片。
多个节点之间的调度会通过PD来进行调度。
简单说几个层，它是高度分层的。存储和计算是分开的，在实现的过程中是这种思路。另外它是用Raft来保证副本一致性和可扩展性的，没有分布式文件系统。主要是HDMS，但是它没有，这样就降低了运维的成本，因为我们要保证HDMS的高可用性。底下是用RocksDB，上一层用Raft来实现，我要实现多版本，再实现事务，主要是这么几层。
一个是RockDB，也是来自于谷歌，后来交给Facebook维护就变成了RockDB，也是根据现在的磁盘来做的。它是LSM的结构，速度很快也稳定，但是不能容忍磁盘故障。它就是本地存储的一个东西，所以在这上面它是没法扩展的，只能依赖磁盘的容量。
Rock层相当于存多个副本，某一个副本挂了，可以自动的进行高可用恢复。
Region的话，一个是Hash，一个是范围的分片，这样有个好处，就是适合范围的扫描。反三在各个节嗲，实现负载军很，读写通过Leader进行。它可以存储多份，这是RaftGroup。
这里分裂，比如说1—100，我从1—50，51—100这样分，相当于细胞分裂一样，就可以很好的分布在各个机器上。如果以RaftGroup来分片就是这样的情况。会传到Follower节点上，其他的也进行分裂，就是这么一个简单的方式。有兴趣大家还是看一下Faft的论文。
扩容也很简单，比如说讲增加一台机器，他认为负载比较高的是A，A正好是Leader，他会把Leader转移到B节点，再把Region副本复制到E节点上，再把A去掉，这样就扩容了，也很简单。
还有多版本控制，它实际上是key加上它的版本号，我们在读的时候就不用加锁，跟MySQL有点类似，我只要读以前的版本就行了。另外有一个好处，我可以恢复到历史版本，如果我们误删的数据，我们就要拿备份。现在不需要，如果你保存了，比如说我一小时之内版本保存，我就可以简单恢复到一小时之内。但是有一个折衷，你保存多版本，磁盘的耗用量更大。
这也是基于谷歌的一篇论文，也是相当于二节段提交。MySQL传统都是悲观锁，我们试图先去加锁，而其他的要进行等待。乐观锁呢，我们不会加锁，只需要在提交的时候写冲突检测。这样有什么好处呢？就是冲突业务量少的时候很好，但是大量冲突的时候是不合适的。它支持的级别是可重复读，也实现了外部的一致性，它是为了支持金融级的，也支持外部的一致性。
另外支持分布式的查询，可以简单说一下，原来我们只是在单台机器这是Count，现在可以把每台及其Count结果会聚，再进行结合。它的分布式的执行计划也是支持的，MySQL是不支持的，无非就是并行的思想，这也是他们官方的测试，主要是OLAP方面的测试。
OLTP的测试因为他们不方便透露，他们是分布式事务，相对比较少台机器的话，时延会大于MySQL。如果是多台机器的情况下，他们就会有强大的QBS。大到一定规模的时候，他们时延是恒定的。
再说说我们的适用场景，我们想用的是大数据量，MySQL可以很好解决，小数据量我们就不需要了。离线，可能大家想的有ES，但是我们这边还没有上，还在测试。有好几个业务说我要上离线计算，它也是很大的需求。适用的场景没有明显的热点，刚才说了是乐观锁，有热点也没有意义，就那么一行，他发挥不了多台机器的优势。另外二级索引，加个子段的索引可以吗？其实是不可以的。跨机房容灾、强一致。
最后说说我们的计划，现在出了RC3版本，我们正在做性能测试。现在功能测试的差不多了，下一步开始测性能。8月份我们准备上一些非核心业务，我也问了他们的人，他们说1.0正式版预计在8月下旬发布，我们也会持续的跟进。后续我们会上一些更核心的业务，未来我们想上的就是私有容器云的方式，让它更方便我们的管理。甚至去哪儿现在也在提供企业的公有云服务，后续也想这么搞。
韩锋：感谢蒲聪为我们带来的精彩分享，下面有请来自润乾信息系统技术有限公司高级技术总监张政宏先生，大家掌声欢迎。
张政宏：大家下午好，今天我给大家分享的题目是“新一代数据处理引擎”。主要给大家介绍一款由我们公司自主研发的，新型大数据处理引擎。
今天的分享主要分为三块，第一块是在日常工作中经常会发生的问题我做了一些简单的总结，还有对问题的思考。第二块介绍一下我们的产品，主要是介绍一下它的语法特征以及我们应用了哪些技术保证了它的高性能。第三块看一下我们的产品，在整个工程上的应用都有哪些场景。
先说一下我们日常工作中经常会碰到的问题，刚才前面的老师主要讲的是TiDB，其实它是OLTP和OLAP结合的产品。前段时间我也在群里收到了他们CEO的红包，在这里也做一个推广。
数据引擎主要还是关注OLAP的业务，我们下面讲到的主题还是跟数据分析密切相关的。我相信大家在日常工作中做过这样一类操作，我们先把文本入库然后再做计算。我相信在座很多同学还是这么做的，为什么会有这样一种看似是操作型的过程，而不是直接拿编程型的方式直接处理呢？我分析了一下原因，主要是两点。
第一，我们一些开发人员对现在好用的开源工具可能了解的还不是很够。我还是要解决这个问题，那我就要用常规的手段把它入到数据库里写SQL。
另外，现在的开源工具也挺好用的，但是有些场景就不太适合了，或者不太适合工程上的应用。比如说我们写一个结构化的文本计算，但是要受本地内存的限制。或者写一个表和表之间的Join关系就很难写了，另外新一代数据处理引擎都会涉及到集群运算。
有了分布式内存的模型就好了很多，但是因为没有自己的存储体系，所以它就需要Hadoop的存储体系帮助它。我们这里说的文本计算，带上Hadoop显然集成方面就没有必要了，现在看起来没有太好的方法用开源工具。
这样一种操作型的处理过程，就导致了我们下面要说的两种现象。
第一种现象，我们在客户那里发现入库时间和结算时间还长，计算可能半个小时就结束了，入库还需要三四个小时。
另外一种现象，大家都知道ETL是什么样的过程，有一部分数据是从关系源数据出来的，我们就把它变成了不是ETL这样的动作，变成了先加载到数据库，再做抽取和计算的动作，整个过程就不是很合理，搞得数据库就很臃肿。
即便我们的数据在数据库里面，但是还是有很多问题我们不太好解决，这里SQL就不太好写。大家知道SQL是命令式的描述语言，所有过程都要写在一句话里，实际上它是缺乏过程计算的语言。缺失过程计算，我们组内的运算就显得很麻烦，还有一些有序计算就更麻烦。
主流的商业数据库都会给它贴个后补的膏药，就是存储过程，弥补过程中的缺失。但是存储性能跟SQL不是一个数量级的，我们主流的商业数据库处理引擎和SQL的处理引擎实际上是独立的。我们相同的程序实验逻辑，用SQL写，存储性能就高很多。
存储过程还有耦合性的问题，我们用报表生成一个模板，用存储过程就会把存储过程写在数据库里。显然一个功能一个放在页面里，一个放在数据库后端，耦合性就很强。另外需要跟它边际权限，刚才提到了报表的业务，实际上数据只需要只读权限就够了，你给他开边际权限，就可以干任何事情。
我们管理水平很高，要经过几个人的审批才能操作这样一类事情。实际上管理成本的上升就带来了效率的下降，我们本身很简单的过程经常需要通过一个审批的过程才能实现，显然开发效率很低。
我们还会实践一些开源的数据库，但是缺失一些窗口函数，这些过程就更弱了。在库内用SQL去写，用开源的东西还有很多复杂的业务逻辑。我们的数据在数据库里也有在库外的，比如说要建立数据中心服务式的接口，数据中心就有很多种数据库，或者是NewSQL一大堆，我们要提供对外服务的接口，就需要多元混算。
我们在互联网公司经常会算广告计算，我们引流过来之后点击事件会在日志里，我们要跟商品做计算，这都属于混合计算的场景。实际上很多场景不需要经过一个数据集成的过程放在一个数据仓里做，如果我们有库外的计算引擎的话，这种事情就变得好作很多了。
另外大家对Hadoop的实践已经很多了，大家应该了解到这是学习成本、维护成本很高的产品，因为它设计的目标是超大容量的架构。另外Hadoop相关的SQL能力跟传统数据库相差很远，按照2013的标准来说，它实现了不到30%，这就给我们在数据分析领域里造成了很多的困难。
现实的情况，我们处理业务的数据量并没有那么大，用Hadoop分布式计算工具其实显得很重，尤其是我们做一些工程项目。你要带着Hadoop去玩儿，客户也觉得很累赘。另外我们用相同的业务复杂度，开源工具的实践并不理想，包括一些开源的数据库。大家如果用一些开源的数据库作为分析库的话，用起来还是不如商业数据库顺手。
另外我们商业的数据库还是很贵的，我们一个库够用了，用其他的方案可能更好一些，但是也许价格不菲。我们现在机器内存越来越大，上半年戴尔推出了160T内存的超大内存机器。将来我们的技术架构也会往这方面走，单机的性能包括大闪存，大SSD普遍的使用，实际上单机性能很高。如果我们有独立的计算引擎，其实可以处理很多事情了，而不需要在一些开源的工具上去浪费很多时间。
基于刚才一些问题的分析，如果我们在库外就有这样一种计算引擎，它拥有数据库全套的计算分析能力，而不依赖数据库。我们数据库还会干什么呢？业务稳定性更强，我们还是应该放在数据库里。对于业务稳定性不强的，大家老去算一些数，看一些报表的，这不如前台稳定性强，这种的我们放在库外，我们还可以用到数据相关的特征去加速它的计算。
另外我们经常需要一个良好的集成性，不能我做一个项目就带一个Hadoop玩儿，我要考虑很多事情。要跟现在很多主流的工程工具集成得很好，比如说我们要写一个数据分析的处理过程，这是很容易的。可是我要把它集成到我的项目里，跟Java程序集成起来可能就不太容易了。
最好这个工具是轻量级的，不要让我的运营维护很麻烦。我本身就是要搞数据分析的事情，其实我只是用了Hadoop里很小的内容，这就是杀鸡用了牛刀了。
数据处理工具我希望它的描述能力很好，开会前我碰到了我们的一个客户，说这块是专门写SQL的，有一些问题。处理引擎要有很强的描述能力，要解决在数据库里用SQL不好写的那部分。另外它一定要具备高性能，因为现在的数据是越来越庞大了。
下面介绍一下集算器，主要还是上面提到的两方面内容，看在适用面上有多好的描述能力，另外高性能方面应用了哪些技术，来保障这个性能。
润乾集算器是面向结构化数据计算的脚本语言，我们是一个动态的脚本语言。它提供了丰富的结构化的集算类库，也支持多线程并行。我们有很强的实施交付能力，很强的业务描述能力。因为它是过程式、函数式相结合的编程语言，又贴近人类自然思维，它对开发的帮助就很大。因为我们是库外计算的引擎，我们就可以抓住数据本身具有的特征，去开发一些算法和类库。我们在很多数据库里享受不到的优势就能发挥出来，这让它的性能得到了保障。另外有了数据库计算能力，而不依赖数据库库外计算的引擎，我们在设计体系结构和应用结构的时候就很方便，它的维护性跟管理性又得到了提升。
首先看一下集算器有那些应用场景，我借用了传统数据分析的三层结构，大致显示我们这个应用场景所在的位置。这四个主要是我们的一些业务场景，这四个业务场景架构都可以做成集群式的。
这以报表为例看一下应用结构，我们在传统LTP业务用到了一些框架，大家已经很习惯用了。但是我们在LTP分型业务里，中间层应用还很缺，我们就是为了弥补这一块的空缺。有了这样一个计算中间层，显然一些存储过程的算法，我们可以解耦到计算层里。报表有多元的处理，展现层也可以计算。有了这样的计算中间层，对于体系结构的设计和运行维护就方便了很多。
下面介绍一下集算器的语法特征，我们这里面的基本说法就是集算器是集合化和离散化的结合。什么是集合化呢？如果这种事做不好的话，可能要写几行代码，挺啰嗦的，如果就是一句话的话，描述起来就很简单。离散性就是说，我们取出来一个集合，需要对集合其中某些东西单拿出来算，这就类似于在高级语言里一条一条算一样。
OLTP这种业务经常会要求大家不要在数据库里写很复杂的SQL，我们需要让它单独拎出来算，因为OLTP是高并发的业务。我们在OLTP业务里也是一样的，有些用SQL很难算的业务，你把它搬出来算，用一个过程化的语言去描述它就相对简单了很多。
这里大家还会有一个疑问，为什么我们不提供结构化计算的类库去做这种事情呢？比如说我们在LTP业务里，经常会用一些框架做这种事情。实际上光有计算的类库还是不够的，大家知道我们在做分型业务的时候有很多中间结果，中间结果称之为动态变化的。动态变化的结果你要用常规的JAVA里的集合类型就很麻烦，我们做的处理是要被一层层包起来的，是批量式的处理。
我们又需要有匿名函数的处理，最好它是一种脚本语言。所以我们不能简单的给他提供一个结构化的计算类库，而是用语言呈现的这样一种基础方式。
用离散性给大家举两个例子，上面是用SQL写的，我们的计算任务是求张三、李四的年龄差和工资差。熟悉SQL的人一看就和明白，它是两个标量子差，相减就行了。右边懂点英语，有初中代数知识的人都知道它在干什么，这是最简单的例子，就是我们怎么解释离散性的问题。
另外一块就更高级了，我们称之为外键式的引用。我们求某个地区的交易记录，SQL的做法是交易表和地区表一观点，用地区明确就把相关的交易记录取出来了，而我们用集算器的做法，如果内存能放得下的话，我们漏在内存里，建立一次性的地区表编码的指针，实际上是多对一的。这样建立好了之后，从描述这件事情来说就很简单了，我们只需要用对象式的点取就可以表述它的关联关系了。
另外后面谈到高性能的时候，还会讲这样一种处理关系，对性能提升也是很有好处的。这是我们举的最简单的例子，大家知道SQL多表的关联其实很头疼，写来写去就会很晕。用这种方式还会保证不出错，为什么呢？大家知道SQLJoin的数一定是减一的，少的话就乘出去了。
分组子集，在SQL体系里，关系数据库里面分组就必须加上聚合，一定是groupby类似的操作，这就会给操作带来很大的方便。我们只关心分组后的子集结果，或者我们会根据子集的结果还要做相关的计算，你强迫我做聚合这显然就很不方便。在SQL一些相关的做法里，就是要把分组的ID取出来，再去做，显然就很不方便。
另外指的是非常规聚合，大家知道聚合就是sum、count之类的，把这个概念推广起来的话，很多表达就很容易，我们书写起来也很简单。大家对比一下SQL的长短，底下的SQL还用到了窗口函数，这样对比起来表现就非常容易。
有序分组，这是我们归纳总结的例子。有序分组是最简单的例子，比如是我们要求一顾股票连涨了多少天。这种运算大家如果用结构化的语言写会很简单，无非就是排个序，涨了+1，跌了清0，取个最大值。但是如果用SQL写的话，这是用甲骨文的窗口函数写的。这就表明了，在很多时候我们如果仅仅依赖关系数据库的计算能力，它表达起来很麻烦。如果我们把这一类的操作搬出来写，其实还蛮简单的。
另外一块就是更复杂的例子，找出连涨三天的股票。大家可以对比一下长短，牵扯到组合问题，分组和有序组合在一起用SQL写就很麻烦。
再谈一下用了库外的计算方式，在性能方面有哪些好处。我们使用了这样一些相关的技术提高了它的性能，首先说一下我们对聚合的理解。刚才也谈到了聚合，我们取一条记录或者取一个子集，我们都推广成一个聚合，它就好写了。这里面谈的是性能方面的问题，比如说我们要取一张表的前三条记录，它的前十名。如果在关系数据库里是个单表的话，建立了相关索引的话还是比较快的。但是如果是中间结果，用不到索引的时候，实际上关系数据库的机制就必须先做大排序。比如说一条记录我们取前十，排完序之后取出前十条。
大家写过一些程序的，其实知道是不需要这样去做的，但是在关系数据库里没办法，机制就必须这么搞，在于库外去算的话跟在数据库里的做法是不一样的。
外键指针对我们的描述能力有很大的帮助，同时外键指针化对性能有很大的提升。大家知道，在关系数据库里做Join，这是世界上最快的对齐方式，但是还是没有指针快。指针是从这样一个地址指向另外一个地址，是常数的时间。尤其表多了之后，性能提升就更加明显。究其原因，关系代数没有指针这种数据类型，导致了很多很高效的方法在数据库里都用不到，你搬出来的都可以用，理论上你自己写JAVA都可以进行，但是复用性很差。
这里我们做了一个测试，当你单表的时候，跟Oracle比差不多，但是做五张关联表的时候，用指标化就比Oracle高一倍，大家知道Oracle已经是商业数据库里最牛的了。包括现在很多内存数据库都放在里面，大家每次都要现算，它就用不到指针的好处。
外键序号化跟外键指针化差不多，我们数据落到盘里的时候就是天然有序的，或者我们有目的的做个排序，给它个序号。这时候我们就可以用序号找另外一个表的序号，这种时间也很快。实际上这一类事情放在关系数据库机制里就不行，因为数据库是不知道你这里已经排了序的，如果表很大的话还是会做分段的。数据库的特征就享受不到这种好处，它数据本身就在库外，你再搬到库内又享受不到这种好处，这就自讨苦吃了。
还有有序归并的情况，后面的操作我们都可以变成很低成本的有序归并的计算。ETL的过程中如果我们在库外处理的话，它的性能非常高，但是在数据库里就享受不到这样的好处。
总结一下，我们习惯性的会利用数据库的能力，然后去做相关的计算。但是如果我们在库外拥有一个跟数据库相同计算能力的引擎，我们就能享受到很多好处跟便利。第一就是描述方面更简单了，它有结构化语言的支持，另外我们可以抓住数据的特征，写一些高效的算法，我们后面的场景分析中还会跟大家做分享。
后面看看集算器在工程领域上的应用场景，分主题给大家阐述一下。数据的多样性很普遍，本身不在库外的数据我们又经常习惯性的做一些数据集成的动作，要放在数据库里，其实很不划算。如果我们在库与本身就有这样的计算能力，我们可能会很高效的处理完就完了。
我举了三个例子，就是我们在项目中碰到的，数据订阅的服务。你的合作伙伴或者你的老板，仅仅是要看一些数据就行了，订阅一些数据。比如说一些财务数据在用友里，ERP的数据在SAP里面。我要把两边数据结合起来看一下，这时候通常业务人员都会把数据导出来再算。如果没有库外的这种计算能力，都要通过技术人员的辅助去做相关的数据分析计算，才能去做。如果有库外引擎的话，我们去读相关的ERP跟财务的接口，我们就可以做到订阅服务。所以订阅服务业务稳定性并不是很强，运营人员提出一个需求就想看相关的数据有什么变化，如果此把它集成到数据库里，那就很啰嗦了。如果有个库外的引擎直接算，这就很方便。
再说一下我们在互联网上的一些应用，我们经常会抓取一些商品信息做分析，或者竞争对手的数据做分析。大家知道这个数据是海量的，我们经常要做结构化的分析，抓取我们可以用很高效的方式丢到消息数列里，再算的时候又要丢到数据库里。你往数据库里写的性能又不是很好，而且随意性也比较强。如果本身把它放在库外，用库外去算就很方便。
刚才提到了跨系统的数据整理，应对这种业务性、稳定性不是很强的方式，我们推荐大家不要再把数据放在数据库里了，而是在库外有很强处理能力的引擎就很方便。
ETL是一样的，从数据源来说分为两块。一块数据本身就是在关系型数据库里了，就是SQL导过来，也没什么好做的。另外一部分本身数据不是带关系数据源的，起来要尽量的用库外的计算能力，不要搞成ETL的动作，导致整个数据库非常臃肿。
另外讲一下报表方面的应用，还会分解一些其他的好处。因为我们做报表还比较擅长，这方面可以说的事情比较多。我们引入了一个独立的中间计算层，在应用体系上就有很多的好处，我们可以把一些数据库的算法外置到计算引擎。
它在库内，离数据更近，比SQL差一些。我们日常跑批的动作还是很合理的，但是这里要减少的是紧紧围报表计算来做的存储过程，这在开头问题的发现里也提到了，耦合性非常强，也不易于管理。我们这时候把相关的存储算法，移植到库外就很方便。
曾经碰到一个案例，他的需求差不多，一个是用DB2，一个是月Oracle，实际上你可以用一致的算法去搞。
另外中间表产生是很有道理的，一个是SQL一步写不出来，很复杂。另外数据量很大，它也需要落地之后再计算。基于这种批量处理中间表的产生是很合理的，为了报表查询产生的中间表，有时候我们叫汇总表或者宽表。这一类完全是为了前端报表展现，或者是用户体验冗余的中间表，实际上是完全不需要的。
我们库内有这样的存储能力搬到库外，做数据的外置，性能就会好很多。不同的集成商来搞，我们曾经在运营商那里看到很极端的现象，这种表能够上万。一个系统的设计几百量表已经很多了，大量的这种表都是为了报表服务的，管理起来就很不方便。如果你把相关的数据，为报表提供查询服务的数据，你为了用户体验和汇总表，这种宽表外置出来。而根据维度建模的数据还是需要放在数据库里面，因为除了报表固定动作的查询以外，我们要支持为报表固定动作查询服务的中间表外置出来。
有些项目随着它的下线不用就不用了，也不会在数据库里产生更多冗余的数据。在数据库里产生这样的表，数据库现状管理起来很不方便的。
最终报表的体验跟你在数据库里的时间，数据传输时间，页面呈现时间，三者是乘法的关系。大家知道JDBC性能普遍比较慢，如果我们能做多线程的取数，在取数环节上能加大它的通道，这也是很有用的处理方式。
第三块是数据汇总的功能，我们有了库外的数据引擎，我们也不在乎数据集群是同构的还是异构的。我们要向各个数据库发出取数的请求，再到我这里做汇总计算，这样就很方便。
T+0报表也差不多，我们经常会把当期的数据库做得很小，让LTP业务跑得很快，历史放得很大。我们碰到的案例，在业务系统放在DB2里，这TiDB又要做全量的T+0报表，这时候如果有一个库外的引擎去帮助它就很方便。
另外就是数据中心的服务，后面也是有多集群的，是多元的。这时候我们不能开SQL的接口，否则灵活性就太强了，我们可以用服务性的接口提供服务。服务性接口后面需要有很强计算能力的计算工具去支持，很多案例都不是在分装算法，而是在移动数据，把数据移动在数据库里，对外提供服务。当你的需求方发生了变化，你又要搞一圈，显然就很不敏捷，这一类的需求都是用库外集群的方式，这样就很方便。
另外谈一下数据集群的方式，我们说的四种业务场景都可以支持集群业务方式，是独立业务计算引擎。Hadoop本身是非常庞大的沉重解决方案，它对标解决的目标承载力是几百到几千台机器，才能发挥它的功效的，现在来说没有太大的意义，更多的意义是存储而不是计算了，它节不是作为计算产品摆在体系结构立了。
MPP是由一台机器升级为多个集群，好用的MPP是一体机，是用硬件去堆的。如果你只是网络里搞一个集群，搞MPP，效果是很差的。我们也测试过相关的MPP，如果你只是普通PC搭的数据架构，性能衰减是非常厉害的。衰减的原因是MPP是基于SQL传统的计算模型去做，搞的非常累，有些好处也享受不到。
我们NewSQL就是要打破在SQL上的算法和局限，才能加速我们的性能。集算器的集群是轻量级的，我们可以在一个机器上开多个进程，在多个机器上开独立进程，这个集群就跑起来了。我们是无中心的节点模式，返回结果都是很方便的。
大家有兴趣可以扫一下二维码，这是我们集算器产品的官方文档，这里的介绍比较详细，大家有兴趣的话可以阅读一下。今天的报告就到此结束，谢谢大家。
韩锋：感谢张志宏先生给我们带来的分享，下面有请来自热璞科技的刘小成，掌声欢迎。
刘小成：我分享的题目是“私有云数据库构建之道”，大家做数据分析的时候有没有想过，数据库本身也是需要维护、优化、管理的。从数据库角度看，我们怎么做到在数据分析的时候为规程是提供一个非常方便的数据库服务，这是我们要聊的议题。
我们首先聊一聊为什么要做这个事情，第二个简单过一下我们怎么做，最后结合数据分析要怎么做。
我目前就职于热璞科技，我毕业之后就一直做数据库这一块，也经历了原始的过程，到现在的数据化、服务化。现在大家都在构建自己的混合云，不会只用公有云和私有云。私有云和公有云在构建上没有什么本质性的区别，我们构建私有云的时候就是对技术的转型和技术的体系有很明确的针对性。
我前两天调研，发现互联网数据40%的速度在增长，这个数据指的是在公网或者在整个万维网暴露给大家可以拿到的数据是这样，因为最近暴露出了一个暗网。我们只是用到整个网络里面的很小一部分数据在做分析，很多数据我们还看不到。
我们现在面临的问题是数据爆炸性增长，从这些数据当中大家拿到，大家会把它变成价值、规则，各种各样的东西。对于数据库来说，首要目的是要把数据存下来，而且不丢。常规的方式，如果企业在做数据库这一块规划的话会发现，我们用分散性方式做数据库，就会面临有很多人买很多软件，要做很多硬件的规划，做硬件实施，所以成本就非常高。而且随着时间的推移，不管是人员变动还是什么原因，风险会越来越大，很多时候会出现机器、数据库之资源处于长期未使用状态，或者处于很大的浪费状态。
我们运维人员每天很被动的在运维，在救火，DBA最恨的可能就是抽数。
Database as a Service这样一个平台，我们要让使用数据库的部门用这样一个方式去做，任何一个数据库就是要做成服务化的方式。另外高可用，安全体系、兼容体系不涉及数据库，但是今天我们以开源的MySQL为范本来聊。
云数据库有一些特征，首先是服务化、多租户、快速响应、动态调整、成本控制、容灾，一旦谈到数据，首先就是安全，不管是数据本身的安全还是数据持续化的安全。这两个图很清晰的描述出了我们做资源规划的时候是什么样的，我们把物理资源、软件资源首先要做梳理，层次化。然后生命周期，从初始化到下线，要经历哪些过程。我们把这些资源分类之后就要做密度的整合，要形成一个高密度的组织方式。
层次化比较简单：应用层、数据库层、系统层、硬件层。生命周期也一样，每一个状态的变化一定是某个事情引起的，而某个事情我们把它认为任务调度，迁移因素，这些都是所有平台要做的事情。密度整合，就像我们做的规格运算，我们要把整个数据库的单元变成很清晰的规则计算，整合在一起，形成整个资源，特别是物理资源高的利用率。
调度这一块不细说了，有模块、自动化、标准化。我们要做调度的任务托管，就一定要把所有跟数据库运维相关或者管理相关的任务，全部放在平台里。备份是数据库必谈的事情，异地容灾、延时备库，做迁移、误操作、顶点恢复、测试、脱敏的，工具就不详细说了，就是MySQL现在用到的。
现在所谓做MySQL的复制，都是基于一个园林，从一开始的半同步复制，到现在MGR都是基于事务主库和从库关系之间的区分。以及不同的方案有很多，最开始的异步到CLUSTER，有一个权衡。
数据库跟硬件有些区别，要搜集的信息有点多，有运行状态、资源状态、性能状态、任务状态。有的是用来回溯查看性能和整个表的，有些是用来做警告和报警的。最终回形成的效果，就是要谈一谈预警、报表的问题。我们对整个数据库要有全方位的数据监控，安全体系这一块就更多一点，我们从四个维度理解就好了，一数据、审计、隔离、用户。备份是一种，隔离主要是资源的隔离，对用户来说，或者对使用者来说，他只想知道自己的数据库处于独享的状态。
企业现在都是在构建混合云的云架构，API就是云架构里面非常重要的角色。所有的组件，不管是部署的还是监控的、任务调度的都需要对外提供接口。咱们做的是PaaS平台，一定会依赖某个数据库平台，不可能让用户申请PaaS平台的时候还申请数据库平台。接口一般分为任务、资源、状态，所有的平台提供的功能都需要对上下游的云平台组件提供一个接口。
这就构成了整体的系统架构，比如说从分层来看有底层的资源层，硬件资源、软件资源、服务资源。还有托管平台，就是服务层。还有面向应用工具的、数据的、监控体系和安全体系，最后肯定会有自己的平台管理界面或者是管理的组件，包括用户、配置相关的东西。
有了这个之后我们要聊一聊怎么样在这样的平台里做进一步的操作，我们刚刚做的效果是具备把数据库托管起来的了。如果仅仅是这样的话，它实际上是个运维平台。一般我们人做决定的时候，它会通过当前的状态，加上自己以前的经验得出一个决策。但是对于机器和平台来说，我们首先需要四个因素：实体、属性、规则、数据。
我们对于这些资源的变动、变化都要提供一些规则出来，然后是数据。其实整个平台的核心或者关键点在于，我们怎么运用数据。有了这些之后，我们也可以把只能通过人做的事情，可以通过平台来完成。
我们从采集角度来讲，我们可以采集到基础数据、状态数据、运行数据，从不同维度来看他们是相互独立的，但是又是相互有联系的。有了这些数据之后，我们再细分一下，比如说从CPU硬件、磁盘网络、服务容量以及负载、性能、备份，能得出什么信息？所有的采集都是互相独立的，互相补依赖，但是当你在分析某一件事情的时候，发现全部都要用上。
比如说我们分析备份的问题，我们要知道整个企业的数据库备份的状态是什么样的，整体备份时间，以及备份期间对存储有什么影响等等一系列的疑问。你分析的时候干什么？比如说我们之前遇到的情况，可能会把我们的存储做好。另外磁盘的状态是什么样的，不管是硬件还是磁盘容量。另外关于负载这一块，最近我们有没有业务增长，为什么最近备份变化特别明显。备份不再是平稳增长的曲线，有可能是因为业务增长，负载也会受影响。因为你数据量变大了，可能优化这一块也要做。
我们就谈到了智能化的问题，智能化可能还不是那么智能，换句话来说我们也在逐渐探索这一块的东西。首先是评估，我们可能没这么清楚，但是我们要有一个全局的概念了解数据库处于什么水平，有了这个之后我们就可以做预警，就是刚刚所有的数据。接下来可以调优、资源整合、测试。
首先聊一聊评估，我们从几个方面看数据库的状态，如果性能、负载、管理、容量、安全几个方面，像雷达图一样，从各个维度评价。一目了然可以看出你的数据库处在什么状态，以及各个维度的趋势。我们可以打个分，这个分数有没有加值不重要，重要的是我们知道它在我们评估体系里是什么样的状态。
有了这个评分之后可以做资源程式化问题和整合的问题，如果我们清楚的知道数据库容量方面的趋势，我们就可以让它做整合。大的可以拆分，小的可以整合在一起，或者硬件条件已经不满足了可以迁移。如果我们认为单库容量已经到达上限了，我们可能要做的事情就是分布式，做垂直也是OK的。
预警这一块最有价值的就是这儿，我们要解决最开始提的数据库的问题，我们现在运维人员处在被动状态。你总是在等待问题的来临，总是在等待别人打电话跟你说我的数据库体慢了，有问题。我们做预警就是让你提前发现问题、解决问题，甚至是提前自动化解决问题。
另外规则匹配，就是我们去定义这个平台哪些是属于我们的预期范围，我们可以拿到所有相关联的数据进行全面的分析。当然有的问题，一如说你最近要锻炼一下身体，有的可能要复查一下才能解决。我们可以把这个预警本身做分级，有的预警只是提前提示，有的预警需要你马上处理。另外优化建议，数据库优化可以做很多。自动处理比较靠后，在规则以及前面的分析结果里对风险是可控的，就可以做到自动化处理。
大家肯定都在写SQL，大家有没有想过自己SQL有时候很慢，要找DBA调一下优，因为自己不是和专业。DBA也无非就是能加的索引而已，调优有三方面，配置、设计、SQL。
怎么优化SQL？现在我们谈到的是所有平台要做的事情，我们要确认这个SQL有没有必要优化，它的执行次数、周期，所在的数据标的容量是不是值得我们优化。它的优化代价、价值在哪里？我们要分析它的执行计划，以及目标表的数据量以及数据趋势，这样才有必要优化。我们看到它数据本身的趋势，我们可以给出的是，按照我们的规则可以做的就是在我们有限的规则范围内提出优化建议。比如说SQL改写，所谓的调整。
在这个基础之上，我们还可以进一步的模拟，我们不可以直接破坏线上的数据，但是可以模拟。在低峰或者测试环境模拟，SQL改动正确性是否达到了，优化结果是不是我们想要的，有没有破坏掉其他SQL结果，或者是别的SQL的执行效率。
优化真正要做到自动化、智能化是很难的，刚才提到的只是SQL本身，还有设计相关的。比如说表的设计，表数据量增长，这一系列信息都需要做到采集、分析，最终形成自动化的调优。
另外是测试，为什么会把测试放在智能化里面？这个准确说叫基准测试。这个测试并非功能性验证也非性能测试，而是我们要对数据库的状态有一个基准的把控。我们要知道，某一种特定的条件下数据库的表现是上来样的，这是我们的基准。如果我们的业务已经上线了，数据库在运行过程中，电商经常会提到一个问题。6·18、双十一业务增长量会很大，那请问数据库能扛住吗？这种问题是没法回答的。业务增长10倍，数据库增长不一定是10倍，可能是50倍，有可能是1倍，也可能没有增长。这种问题我们要细化，变成更准确的回答，就是我们数据库当前的情况，以及负载的情况要考虑。在周末、晚上，负载都是不一样的，以及每一天的SQL分布都不一样，所以我们要做第二个事情。
第一个是基准测试，第二个是模拟测试，也可以说是方针测试。我们要对线上已经存在的数据库服务进行非常准确的负载以及容量的把控，我们不知道业务增长10倍会发生什么情况，但是我可以知道数据库容量、性能增加10倍会发生什么，以及在业务高峰期我们会做什么样的准备和容灾计划，这是之前怎么做测试的一个持续图。
简单来说，我们要建立两个模型。一个模型就是你的目标数据库本身SQL分布的模型，哪种频率运行。以及数据本身的分布，数据的规模，加上这两个我们就可以做模拟测试了，最终得出一个结论。
另外讲一讲后面的效果，怎么做呢？从资源池、任务调度、监控、安全各个方面做这样一个平台，我们通过这样一个架构就是要把它变成代码，变成可运行的，变成服务或者是方案。有这个之后我们转化一下，首先我们要解决运行问题，要面向几种用户。面向应用程序、用户以及管理员。应用程序需要反馈数据库，用户需要申请，去管理资源，做交互。另外就是数据库，比如说今天用MySQL做样板，MySQL本身有一些节点。
有了这个架构之后，我们再梳理一下怎么做资源交付，最简单的交付流程就是要完成一套数据库资源，让我们的数据库服务对象或者是用户做到随时可以用。往资源池里添加资源是最基本的，有了资源之后我们的平台用户会申请这样的数据库资源，他提出我要什么样的数据库，然后由服务层完成整个资源的分配、托管，以及后续资源分配配置，有了这些之后程序员就可以直接反馈了。你可以看到你数据库里当前的状态，以及一些优化操作。
这是资源交互，另外我们刚刚提到的只是一个概念。一个用户不可能只有一个数据库，大家肯定都管理过数据库，数据库从来都是有很多个，不可能只有一个。有很多数据库资源，它处的状态，配置本身肯定是不一样的。这个用户会有三组数据库资源，有不同的架构。可以是三节点方式，也可以是集群分布方式。如果你面临自己一堆数据库的时候可以很清晰的知道，这个数据库有问题，那个数据库还OK。
我们看一看它为什么会得出这样的分数，分数本身不重要，重要的是它为什么会得出这样得分数。直观一点说，容量相关，它的CPU内存、磁盘方面的容量是不是已经超过、达到或者即将达到它的域值？比如说他本身申请的是50G内存，现在已经使用了48G，需不需要做扩容？以及数据安全，比如说备份是不是有效的，最近有没有做备份的恢复测试，以及备份的大小，备份占用的资源。另外性能表现，就是我们刚刚雷达图里提的维度，它的吞吐量是不是在希望值之内，有没有出现异常，节点是不是正常运行，有没有出现硬件故障和软件故障。
我们做了一个解决方案，就是怎么把自己的后台库扩容的问题，解决这个。64TB的存储能量，监控对象可以达到十万以上，而且对Zabbix是完整兼容，而且你当前使用的是单个MySQL，可以直接月我们这个脚本迁移到分布式方式去。另外这个是我们公司的一个产品，大家感兴趣的话可以扫码关注。
韩锋：我们先在群里抽个奖，可以找到我们的工作人员要礼品。
上半场干货很多，头脑有点转不过来，我这个话题大家可以放松一点。话题的题目叫“数据库的前世今生”，这是我对数据库的现状和未来的一点观点，以及对DBA职业未来发展的小观点，跟大家分享一下。
我是一个70后，做数据库很久了，最开始做开发，后来有兴趣就转做数据库这方面了。我分几个方向：数据库发展现状的整理；针对数据库相关的领域，包括大数据、云、硬件、虚拟化之间的关系；数据库管理的变化，以及对DBA职业发展的小观点。
我开始做数据库的时候大概是2001年，那时候做数据库没什么可选的，就三四种。现在你想做数据库的时候，发现有很多东西可以选。这也没有列全，列全的话图就没法看了。我们先做一个简单的整理，里面都包括了什么。大概分四部分：
第一是传统关系型数据库，Roacle、DB2、SQL Server为、SybaseIQ等等。
第二是非关系型的，Hbase、MongoDB。
还有不算是数据库的产品，包括Exadata、Netezza。
非数据库的，Memcached，实际上可以理解为数据的处理平台，跟数据库关系不太大。
很多公司运营的时候，实际上是提供了一个统一的数据库能力，包括了我们上面讲的数据库和非数据库，这些领域大家都会在泛数据库的概念里遇到。
这张图我们可以看到，有做数据仓库的东西，我们很少能找到一种架构支持多种应用的，我们不得不为了应对各种变化，比如说结构化多元化，以及导致多种架构来应对我们数据类的服务。这后面为什么会诞生出这么多种的类别和划分呢？实际上就是数据规模增大了很多。如果我们现在退化到15年前、20年前，那时候数据库应用规模很简单，可能有一个数据库可以通吃，都能解决这些问题，就不会发展出这么多种数据库的种类，这是近一二十年最明显的变化。
从另外一个维度看看，大概三种不同的类别对应数据价值和数据容量有什么样的选择。
TB级、PB级、EB级，传统交易型到分析型，结构和半结构化，实际上是有这样一个选择的。从数据密度来讲，传统的价值密度最高。什么样的数据有价值？可能是公司里的订单数据、客户价值。价值低的可能就是爬虫，从互联网上爬了很多数据，这些数据你不挖掘是没有什么价值的，你挖掘它才有价值。正是应对不同的数据体量，包括数据结构，以及价值的不同我们有不同的应对方案去支撑我们的业务。
跳过刚才这些东西，我们看另外一个层面的东西，对传统数据库集成的发展。因为我们的数据规模不断增大，我们不得不去应对更大的数据体量。两个方面，一种是数据规模，我们要把我们存储的能力扩大，另外一方面是计算能力扩大。什么样的策略呢？最开始我们用传统的单机模式就可以了，你扩CPU、内存、硬盘等等。到一定体量不行了，比如说SMP架构，它可以扩充你的计算资源，存储资源首先与共享存储，也就这样了。再后来有MPP架构，把计算资源扩充了，存储资源也进行了扩充，通过这样的方式更好的支撑你的业务。当然不能直接类比，它各自有各自的特点。
大家回去可以类比这个，我们用什么方式做扩展？MPP扩展就很简单，通过网络把集成资源和存储资源捆在一起。带来的缺点是上层软件决定了扩展能力，所以牺牲掉了很多东西。这样架构的软件都有同样的问题，必须要牺牲掉某些数据库的特性，才能达到一个比较好的扩展能力。
这是NoSQL，前几年炒得比较火，那时候说可以达到关系型数据库了。这两年大家对这方面的使用越来越务实了，越来越能够精确找到NoSQL和传统关系型数据库的定位。什么样的场合使用NoSQL，什么样场合使用关系型数据库，对NoSQL这么多种类怎么做取舍，在什么类型场景下使用。最近两三年，通过跟很多朋友交流，包括在很多公司看他们的方案，确实这方面大家慢慢务实了，而不是过去四五年这种炒作的状态，现在好了很多。
右边是所谓的CAP图，大家都很熟了，我就不讲了。
这是一个很老的PPT，就是所谓的去IOE，这应该是在2012年、2013年的时候，参加任何一个会都要有人讲这个事情。以阿里为代表，去IOE这个事情炒得非常热，大概2012年达到了高峰。最近两年声音小了很多，因为很多公司也在尝试做这个事情，发现这里事情很多，去IOE并不那么容易，大家就会更务实。原来不是像会上听的那么完美，他们有很多心路历程，但是会上不会讲这些事情。
确实有很多公司、很多厂商出来，去帮助企业解决怎么样用好开源数据库，怎么去替代传统大型集中商业数据库，一系列的问题都会有。慢慢这两年大家也确实务实了，我也负责过类似的工作，我跟领导的说法是，我们讲去IOE从来不是DBA的事情，或者不完全是DBA的事情。更多是对你整个应用体系架构的改变，所以要有个清晰的认识，我今天去这个东西，意味着谁要付出这个成本和代价，这要有一个很清晰的认识。
我总结了一张图，什么意思呢？左上角是精华。一个企业在什么情况下使用开源数据库，什么时候使用商业数据库，或者用开源软件和商业软件。在企业发展初期，你投入相对应成本的情况下，你开源收益往往低于商业收益，这个很正常。随着企业不断的发展，到了一定的规模，你会存在这样一个拐点，这个拐点之上你开源的软件收益要大于传统商业软件。
阿里发展到一定阶段，因为你的商业软件无法支持你的服务你必须做这个转变，这是被迫的。我们不拿成本衡量了，这是因素之一，但是不是唯一的。你企业发展到什么阶段，你要做一个评估，你企业想去IOE，要去在什么阶段是最好的？如果一个快速发展的企业要应对你大量的业务变化，要上规模，企业要生存下去，这时候你要招很多人，投入很多技术资源做这个事情吗？其实是不知道的，这时候我们关心的是快速的活下去，你真正活好了，一定体量才可以考虑这样的问题。
右边是因为这样一些东西，你才可以把这些事情成为一个可能。比如说硬件处理能力的提升，开源软件的成熟度，人才积累等等。正是这些因素，加之企业发展到达了一个阶段，这时候你才可以考虑是不是应该做这样一个尝试。
我们会有定期的数据库排行榜，做数据库的大家都比较熟悉，是国际的排行榜。国内也有公司在自己做排行榜，它实际上是对数据库的搜索做排行，搜索相关东西做了排序，基本上可以把它作为热度的排序。
现在数据库的发展还是属于比较稳定的状态，前面三大一直都比较稳定。我们国内也有人做这个事情，可能是MySQL到了第一位。国内很多传统企业包括互联网企业，慢慢在做技术的转型。在国外，可能更重视商业模式，所以对于数据库来说只要能支撑业务就行了。国外相对用Oracle的要很多，国内在搜索规模上比较小。我过去是做Oracle的，现在看Oracle，确实本身Oracle这个软件作为关系型数据库的引领者有二三十年的历史了，在数据库方面确实达到了一定的高度，很多人都在学他。
MySQL我认为它不是做得最好的开源软件，但是却是一个最流行的，生态圈建设最好的开源软件。前两天开数据大会，你开Oracle大会屋子是坐满的，但是开DB2的大会可能会场就一半的人，开MySQL的大会人都在外面站着，确实在国内用得很普遍，体量非常大，这是MySQL做得比较好的一方面。
过去一段时间MySQL走了一段时间弯路，卖给了Oracle，Oracle也不太理这个东西。后来Oracle对这一块也确实引起了很大的重视，这两年MySQL的社区版本、企业版本有很多变化，加快了自己更新迭代的速度。MySQL5.5、MySQL5.7、MySQL8.0，更新速度非常快。Oracle也感受到了危机，如果MySQL再向以前这么玩儿的话已经没法玩儿了，改变得也很多。
第三个是底蕴很深，时间也很长，有很长时间的数据库积累。原来是首先与微软的Windows平台。如果未来支持了跨平台的使用，从应用型角度来讲是没有人跟它做比较的。
下面是PG，我觉得是挺好的对象，我用的时间不长，但是是很优秀的学院派的开源数据库，大家可以了解了解。国外用得比较多，国内相对少一点。MongoDB也有自己的特点。
搜索类的、文档类的，我们都可以找到这些身影，数据库不断在有变化，但是第一集团是比较稳定的，这是目前大概的变化。
这是我自己的小总结，我看到了很多公司在尝试做一些东西，会弱化一些关系型数据库的特性，比如说跨表JOIN，事务等，做自己定制化的DB，这实际上是两三年前做得更多一点。我们可以充分利用开源数据库的功能，通过加入中间层达到高可用、水平扩展，很多公司也基于开源方案来做工作。集群数据库也有很多了，是很有特点的集群数据库。在某些场景下，建议大家考虑使用NoSQL，但是你要注意你的使用场景。
因为我们公司就有这样的例子，大家以前没有使过什么东西，速度很快，把所有东西都放里面，不停的扩。其实应该规范使用，会面临这样的情况，所以要注意使用场景。
还有硬件问题，传统数据库也还有很多的发展空间。比如说MySQL5.7，Oracle、BD都支持了新结构，自身功能里要不断加强，支持这样那样的特性，也要跟NoSQL做一些对比，实际上双方也是在不断融合的过程中。
下面谈一下大数据，我本身不是做大数据的，只是自己有一些了解。所谓的大数据就是四个V，大家在很多会议、文章上都看到了：容量、结构、密度、获取方式。
这是对技术发展做了一个评判，就是技术是什么发展阶段，是初始期、快速上升期、技术稳定期。这是2014年的图，这时候BigData在这儿，2015年的时候已经找不到了。什么意思？大数据从2014年、2015年的变化可以看到，已经不再是作为新兴技术存在了。为什么是这样的？我们现在讲所谓的大数据，大数据对应的是小数据。大数据是因为我们在过去的某一个历史发展阶段，我们面临着一些问题，比如说数据量大，数据格式的问题，导致我们必须用一种非传统数据库解决的方式来解决，我们起了个名字叫大数据。大数据一般都是什么能力？其实也完成了跟传统数据库变化不大的能力，也完成了存储计算的能力，在这个阶段我们叫它大数据，仅此而已。
来源：CDA数据分析师峰会：数据库与技术实战-分会场
阅读权限+下载200次/日+产品折扣+免费数据库+免费广告+人才库+海量论坛币
阅读权限+下载40次/日+产品折扣+免费数据库+海量论坛币
提升卡
置顶卡
沉默卡
变色卡
抢沙发
千斤顶
显身卡
京公网安备 11010802022788号
