【.com原稿】如今，硬件的性价比越来越高，网络传输速度越来越快，数据库分层的趋势逐渐显现。人们不再坚持使用一种解决方案来解决所有的存储问题。而是通过分层，让缓存和数据库负责各自擅长的业务场景。TiDB作为一个HTAP数据库，不仅以高性能实现了OLTP特性，还提供了基于实时事务数据的实时业务分析需求。2018年5月18-19日，由主办方主办的全球软件与运维技术峰会在北京召开。在“大数据处理技术”环节，PingCAPCTO黄东旭带来了主题演讲《How can HTAP help you：ATiDB Story》。他分享了TiDB的设计思路、实际应用场景，以及部署和运行TiDB集群的最佳实践。什么是TiDB数据库？TiDB是一个数据库。我们知道市面上有很多像MySQL、Oracle这样的数据库。为什么需要一个新的数据库？相信90%的人都用过MySQL。但是当MySQL的数据量比较大或者并发开始失效的时候，你有什么选择呢？事实上，没有太多选择。一种是完全不使用MySQL，而是使用NoSQL。例如，HBase或Cassandra用作数据库。但相应的代价是SQL复杂查询能力的丧失，以及整个MySQL生态系统的丧失。NoSQL可以带来横向横向扩展的能力，但是会面临整个业务代码的重写。这在很多情况下是不现实的。所以很多时候还是得用MySQL，但是MySQL在数量上有各种限制。所以我们过去能做的就是Sharding，水平分区，分库分表。但是很多时候，虽然你做了水平切分，分库分表，但是Scale还是一个非常大的问题。还有一点就是，如果你使用读写分离，或者你可能使用像Cassandra这样的final一次性系统，这个新的支付单对于开发者来说是比较大的。如果你没有一个强一致持久化的存储系统，你的业务层代码会很难写，尤其是一些金融场景或者对一致性要求高的业务。另外，我们的数据仓库、大数据分析方案和数据库方案基本上是完全分开的。近两年大家使用的RabbitMQ或者Kafka等管道系统，都在试图搭建数据库和数据仓库之间的桥梁。有没有办法直接在数据库层面做实时OLAP？或者你现在用的是MySQLSharding，你要做一个简单的跨业务join分析，你得把这个数据导入到Hadoop或者通过ETL的数据，然后在仓库里做分析。维护ETL的过程是一件很麻烦的事情。还有一个问题就是数据分析师不一定是工程师，也不是技术很强的人，所以在技术选型上会有各种限制。我们可以直接在数据库上做一些就地查询吗？这是一个问题。另一个是大趋势。每个人都在考虑如何将数据库等服务与现有的云架构集成。比如不能直接把一个MySQL实例放到一个Container里面，因为如果Container挂了，数据就没有了。如何为云环境或者弹性伸缩的容器环境设计弹性伸缩的数据库，其实是一个很大的问题。还有一个特别大的痛点，就是人在做高可用的时候会出错。现在做数据库会遇到这些问题的原因是什么？我个人认为像MySQL和Oracle这样的关系型数据库并不是为分布式而设计的。另外，即使你不愿意做分库分表之类的操作，本质上也只是把MySQL再照搬一遍，并没有为它做一个分布式系统来优化存储和计算。这就是问题所在，这也是为什么我们觉得我在做一些跨业务的查询或者一些跨物理的查询，在本机上写会比较麻烦。但最终这种情况正在改变，因为2000年后，分布式系统理论开始成为主流。这有一个历史发展背景，就是以前硬件贵，网络环境不好。所以尽量在本地进行计算。因为SSD的出现，现在磁盘IO基本不是什么大问题，Intel很快就会发布持久内存。像这样的技术基本上解决了数据库IO层的问题。现在在谷歌内部，在同一个数据中心读取远程磁盘的吞吐量和延迟与读取本地磁盘基本相同。在这种情况下，您可以将整个数据中心视为一台计算机。当你重新设计数据库时，它本质上是一个分布式系统。第三点是大家的思维在发生变化，大家不再幻想有一个完美的方案可以解决所有的存储问题。易于维护TiDB这个项目是三年前开始的。项目就是上面介绍的背景。我过去一直在PeaPods中维护MySQL集群。后来因为关系型数据库不好维护，所以经常想有没有一个数据库可以结合MySQL和NoSQL的优点。所以这是初衷。我们要创建一个功能齐全的SQL，最好能兼容现有的，至少是这些常用的复杂查询和子查询。然后同时用一个MySQL的协议和用法来面对客户或者用户。这一点很重要，它可以大大降低用户试用你产品的成本。事务的第二点就是事务，事务是万万不可少的。我觉得近十年NoSQL社区一个特别大的问题就是追求可扩展性，但是放弃对强一致性事务的支持是错误的。过去没有实现此功能的原因是此功能会导致系统延迟和性能下降。但我认为以牺牲数据准确性为代价来实现这个功能是不现实的。这就相当于本来这件事情应该由数据库来做，但是这些NoSQL系统却把这件事情强行交给了业务层。这将给写作业务带来巨大的问题。另外一个就是扩展的易用性，也就是能不能做到。我在这里使用了一个词，叫做按钮缩放。我只是把一台机器扔进去，没有做任何重新分片或修改配置。系统自己扩容，自己做rebalancing，这与传统的sharding方案有本质区别。高可用那什么是HA？HA即高可用，这是传统方案难以解决的问题。即一切都需要人工进行数据校验和流量切换。没有办法实现真正??的HA。这个数据库能不能自己自动运维，自己修复，自己保证系统的可用性。我们在这方面也做了一些工作，就是我们整个底层数据模型完全抛弃了主从模型，完全基于Raft、Paxos等分布式选举算法。这一点更重要，因为如果不能保证一个系统的可用性，再谈性能就没有意义，尤其是OLTP系统。我的系统可不可以在上面不仅支持ACID事务，还可以使用Spark或者Hadoop来利用整个集群的计算资源和能力，进而加速一些复杂的SQL查询。这实际上是可能的。开源最重要的一点就是必须绝对开源。如果通用技术软件不开源，就绝对没有未来。因为现在时代变了，以前那种闭门造车，然后招很多推销员，敲门问要不要试试的老办法是不对的，尤其是平台软件。而且开源会更有利于软件的推广。您拥有的用户越多，用户给您的反馈就越多。这比在内部开发软件要快得多。这就是为什么这个项目才启动了三年，我们就有了2000多个客户。TiDB数据库的四大“杀手级特性”下面我总结一下TiDB数据库有哪些应用场景可以在自己的业务中使用。用例1：MySQL分片和合并第一个场景是MySQL。比如现有业务用MySQLSharding，没问题。现在TiDB在业务层实时兼容了这个MySQL访问协议。并且我们做了一个工具Syncer，可以把TiDB当做MySQL的MasterSlave，业务层前端可以做一个主库MySQL，TiDB做从库可以看成是一个大MySQL。以前我们有一个说法叫一主多从，现在有了TiDB可以反过来说一主多从。可以将这多个MySQL组的不同表、不同业务、不同库、实时Binlog数据同步聚合到一个大型的分布式MySQL中。这个分布式MySQL就是TiDB。在这个MySQL之上，你可以使用一些更复杂的查询，比如join和groupby。所以这是一种用户场景。什么是同步器？刚才简单提到了Syncer是一个可以伪装成MySQLSlave来同步数据的工具。它本质上是一个BinlogListener，监听MySQL的Binlog并将其转化为数据库语句。用例二：直接替换MySQL还有一个应用场景很简单粗暴。最简单的情况就是业务增长很快，但是原来的业务是MySQL写的，没有分库分表，没有架构。摩拜单车早期使用的是MySQL。后来发现业务开始快速增长，公司在团队规模为30人时开始使用TiDB。然后不到一年的时间，整个公司的人数增长到800人，数据从一个小数据集变成了后来TiDB上的几十TB的数据，所以不需要分库分表。因此，在业务快速增长的场景下，TiDB是一个不错的选择，对于OLTP业务，TiDB也是一个不错的选择。在吞吐量方面，TiDB基本可以实现线性扩展。机器越多，性能越好。对于延迟，TiDB也表现非常出色。UseCase3:DataWarehouse另一种使用场景是直接使用TiDB作为数据仓库。TiDB在OLAP性能评估中表现非常出色。如果有一些特别复杂的SQL，TiDB的SQL层还是处理不了的。我还创建了一个名为TiSpark的开源项目。它实际上是一个Spark插件，可以让用户直接使用SparkSQL对TiKV进行实时大数据分析。第三个应用场景，TiDB本身就是一个存储和计算分离的项目。其下的Key-Value层也可以独立使用。你可以用它来替代Hbase，同时支持跨行事务。TiDB项目其实是受到GoogleSpanner系统的启发，通过NoSQL层来支持事务。TiKV提供了两层API，一层是支持跨线交易的API。第二层API称为weakAPI，主要用于单行事务，不提供跨行事务的ACID支持，但换取整体性能和延迟的进一步提升。因此，如果有必要，交易可以使用交易API。如果对性能有要求，但又不需要强一致性事务的跨行事务，就使用weakAPI。弱API与Hbase具有相同的一致性级别。Usecase4：作为其他系统基于通用KV层的基石，我们可以做很多我们想做的事情。TiDB不仅仅是一个简单的数据库项目，它应该是其他分布式系统的构建块，可以作为其他系统的基石。TiDB本身提供了MySQL接口，但是社区的小伙伴直接给TiKV层封装了一个Redis协议层。然后让用户直接使用Redis协议来做TiKV。这样就变成了一个持久化的ScalableRedis。那么另外一个案例，就是在今日头条中使用的，就是对外提供一个S3。如果你想构建自己的S3，没有问题。但是搭建S3最难的是源信息管理，而不是它的数据节点，所以如果你已经有一个支持跨事务的源信息存储系统，你可以自己搭建S3。我知道社区里有一些同学已经搭建了一整套新的分布式存储服务。API目前还没有开源，但我想在不久的将来会开源。如何从MySQL迁移到TiDB？既然TiDB这么好，那现在怎么把MySQL迁移到TiDB上呢？因为TiDB实际上是基于MySQL生态的，当然可以使用MySQLDump。我们做了一个数据导入导出工具，叫Lightning。我们为什么要做这个？比如以前我们直接使用MySQL协议，使用MyDumper和Myloader，就是简单粗暴的导出导入。那么TiDB到底想做什么呢？因为大家都知道MyDumperdumps是一条一条的MySQL语句。然后在TiDB这边，从SQL，到它的解析器，到执行计划，到引导事务，到KV，最后写入单机的RocksDB。一遍又一遍的重复这个过程是一个很慢的过程，如下图：我们想，有没有办法直接绕过所有中间的东西，直接使用MyDumperDump出来的SQL语句直接生成底层的RocksDB数据格式什么？当然。这就是闪电正在做的事情。你可以把它看作是MySQLDumper的升级版，它直接转储SQL语句。然后我们直接在TiDBLightning项目内部做了这个RecordtoKV，也就是直接生成底层的键值对。然后在内部同时做数据分片，提前分片。第三种是直接绕过中间的所有SQL，直接生成RocksDBSSD文件，相当于把存储的格式文件发送到不同的机器上。然后本机直接把文件加载到数据库就完成了，中间其实很快。部署TiDB，我们选择的技术方案是Ansible，一键即可完成所有部署。那么包括性能调优在内的一切都是完全开源的。我们目前正在将TiDB项目捐赠给CNCF基金会，并正在与Kubernetes集成。目前处于测试阶段，未来一定会开源。当然，如果你说你想在本地玩玩，但是TiDB的组件那么多，我能不能在本地搭建一个完整的TiDBCluster一条命令来测试呢？当然。我们这里有DockerCompose，有两条路径，一是gitclone，二是startup。它将开始包括仪表板、数据迁移、可视化、TiDBMySQL服务端点、TiSpark都将在您的Docker容器中创建。此外，这还不够。我们通过数学方法正式证明了一些核心算法是正确的。此TLA+的源代码文件是开源的。如果你想在自己的分布式系统中使用TLA+做数学证明，可以参考我们写的文档。所以我认为测试是这家公司最重要的资产。总结一下，有几个大问题是我这段时间想的比较多的。比如你整个集群云化之后，数据库层面的Multi-tenancy怎么办？你怎么能这样做？更有效的资源隔离和复用？现在没有很好的解决办法，因为整个IO的隔离还是比较大的问题。第二个是自治，这个数据库能不能有智能化，就是我不再需要人工运维了。这个数据库可以自己部署、维护和更新。那么如果数据有问题，可以自己修复；如果性能有问题，可以自行调优。我们还尝试将一些指标从我们的操作中导入到Tensorflow中以自动调整它们。这个工作正在做，接下来CMU应该是一些比较有意思的工作。还有就是软件和硬件的结合，就是如何利用这些新时代的硬件来提高你整个数据库的稳定性。PingCAP联合创始人兼首席技术官黄东旭。他是分布式系统和数据库开发方面的专家。在分布式存储方面有着丰富的经验和独到的见解。他是Codis（一种常用的分布式Redis缓存解决方案）和TiDB（一种分布式关系数据库）的联合创始人。【原创稿件，合作网站转载请注明原作者和出处为.com】
