关于tidb:黄东旭-关于基础软件产品价值的思考

好久没写货色了, 正好趁着春节的节后综合症发生写写文章热身一下，记得前几年偶然会写一些对于 TiDB 产品性能解读的文章，TiDB 5.0 发了那么长时间了，也应该写一写了。我其实在多个场合里表白过我对于 5.0 的器重，这个版本可能是对于 TiDB 来说的 MySQL 5.x，相熟 MySQL 生态的敌人必定晓得我在说什么，MySQL 5.x，尤其是 5.5~5.7 这几个重要的版本基本上为 MySQL 的疾速扩张奠定了松软的根底，也造就了一大批 MySQL 的用户和人才。我认为 TiDB 5.x 尤其在 5.2 之后，也看到了进入快车道的趋势，开始展现出生态统治力。对我而言，TiDB 是一个绝佳的样本，在此之前，中国外乡很少有这样从零到一做进去的开源根底软件产品，少数工程师和产品经理都是这些软件的「使用者」，更多的是构建业务零碎，而 TiDB 让咱们第一次得以「设计者」的视角参加其中：每一个性能个性的设置背地的思考，对根底软件产品的价值出现，体验还是很不一样的，借着这篇文章写点感触，另外的这个文章是春节前我在 PingCAP 外部给 Presales 和 PM 培训上的分享整顿而成，不肯定正确，仅供参考。
咱们做的事件，对于用户意味着什么？
要讲好根底软件的产品价值，首先要克服的第一个关卡：学会换位思考。其实 TiDB 每个版本都带着数十个的个性和修复，然而少数时候咱们的 Release note 只是忠诚的反映了「咱们做了什么」：

TiDB 4.0 GA 的 Release Note 截图

各位这里请不要了解错我的意思，这种类型的记录是很有必要存在的，然而仅有这个是远远不够的。例如在 TiDB 5.0~5.5 的版本外面，咱们引入了 n 多的新个性：聚簇索引，异步提交事务模型，优化了 SQL 优化器，反对了 CTE，引入了锁视图和继续性能诊断工具，改良了热点调度器，升高了获取 TSO 的提早，引入 Placement Rules SQL…这些名字在 TiDB 的开发者看来是没问题的，然而请留神，更重要的问题是：这些对于用户（客户）意味着什么？
要答复这个问题的思路有两种，我别离讲讲：

1. 通过一个假想的指标场景，而后通过产品去满足这个场景来展示价值。
2. 解决现有的计划（包含本人的老版本）那些最宜人的问题来展示价值。
   对于第一种思路，通常实用于比拟新的个性，尤其是一些过来素来没有的陈腐货色。用一个比拟好了解的例子：如果大家都在开马车的时候，你创造了一个汽车，这时候如果你以汽车解决了马儿要吃草的问题作为价值点显然是比拟荒诞的，更正当的是描述高速通勤的场景带来的便利性作为卖点。这种思路有两个关键点：
3. 首先这个场景最后是产品经理假想的（当然必定也会做过很多访谈和原野考察），所以如何确保这个场景是「高价值」且「具备普适性」的？对于一个胜利的根底软件，这点尤其重要，通常在我的项目晚期能抓到一个这样的点，就相当于胜利了一半，当然这个对产品经理的要求是十分高的，通常须要有很强的 vision 和推动力，这就是为什么很多产品型公司的 CEO 都是晚期的大号产品经理，因为在我的项目的晚期 CEO 须要同时领有这两样。当然更强的犹如乔布斯这种事实扭曲场，无中生有造出 iPod / iPhone 扭转了整个世界，这是何等的气魄和远见（我置信 Jobs 在构思 iPhone 的时候应该能设想到明天的世界）。这个没啥方法，根本就是靠人。
4. 你产品的价值是否在这个场景里有最间接的体现。最好的间接通常是直指人心的，是人间接能领会到的「感触」。对于开发者产品来说，我通常会抉择的锚点是「用户体验」，因为好的体验是不言自明的，汽车和马车比照在通勤舒适度和效率的时候，是完胜的；就像 TiDB 和 MySQL 分库分表的计划比弹性扩大能力时候也是一样，体验上也是完胜的。对于这一点倒是有很多办法去参考，有趣味的能够参考我那篇对于用户体验的文章。
   第一种思路实质上来说是 Storytelling，这种形式的益处在于：
5. 十分好验证，当你把故事想明确了，那天然典型的用户旅程就进去了，这时候你把本人作为一个假想的用户残缺的体验一遍即是验证，这也是我通常应用的测验咱们自家产品经理工作的形式😁。
6. 用户很好承受，情理很简略：人人都喜爱听故事，人人都喜爱看 Demo，人人都喜爱抄作业。
   对于第二种思路，通常实用于一些改进型的个性，其中的关键点在于：待解决的问题到底多痛？没有完满的软件，在重度用户那边肯定会有各种各样的问题，而且这类问题通常这个性能的开发者是难以领会到的，这时候要做的也很简略，就是弯下腰去理解，去应用，去感触。我常常会去和咱们的客户交付团队的一线同学聊天，在做这次分享之前也不例外，大抵的对话如下：

我：对于咱们的 SQL 优化器，你感觉日常工作中，让你最头疼的问题是啥？
Ta：执行打算渐变。
我：对了，那是 hint 不太够用吗？而且 3.0 就引入了 SQL Binding？这些帮上忙了吗？
Ta：对于一些疑难杂症来说你很难通过 hint 来指定的特定的执行打算（而后附上了一个实在的业务场景中的例子，一条百行的 SQL，的确无从下手），另外 SQL Binding 问题在于，我绑定了 SQL 执行打算当前，之后如果有更好打算，还须要从新来？
我：咱们 4.0 不如引入了 SQL Plan Management 吗？外面的主动演进性能不正好是解决这个问题的吗？
Ta：没错，然而咱们生产环境都不敢开，对于极端重要的 OLTP 场景，不能容忍执行打算主动变更带来的抖动危险。
我：咱们的产品做什么事件，能让你感觉日子好过一点？
Ta：1. 对于简单的 SQL 可能抉择指标执行打算，让我抉择 binding 就好，而不是通过 Hint 结构；2. SPM 发现更好的执行打算，只须要及时告诉我，我来做变更，而不是主动决策变更。

下面最初一句的两个反馈，我听到当前觉得很有启发，其实这两个需要都是很中肯，而且开发的代价并不大，然而的确节约了很多的工夫和 DBA 的心智累赘。
相似的例子还有很多，然而重点是：找到产品的重度使用者，深刻开掘他最头疼的问题，有时候会有意想不到的播种（例如去 OnCall 的现场察看大家的操作）。而且这类问题的解决，通常也会随同着很好的体感，TiDB 在最近几个版本中的一些对于可观测性的改良，根本都是通过相似的察看得来。
然而第二种思路的价值展示，肯定要找到适合的听众，例如：通常咱们为利用开发者（数据库的使用者）解决的问题和数据库运维者（DBA）是不一样的。面对谬误的对象，后果有可能会是鸡同鸭讲。
当用户在说：「我要这个」的时候，Ta 其实在说什么？
在中国根底软件的产品经理和解决方案工程师难找，我感觉是有历史起因的，就像下面我提到，过来很长时间，咱们通常是站在一个「使用者」的视角去对待软件，这意味着从问题到解决方案通常是显著的，例如，假如我须要做一个高性能，反对亚毫秒低提早读写的 User Profile 零碎，数据量不大，能够容忍数据失落，那我就用 Redis 好了！然而作为 Redis 的产品经理来说，ta 很难为了 User Profile 这个很特化的场景去设计 Redis 的性能。

优良的根底软件产品经理通常会抉择通用的技能点，用尽可能小的性能汇合来蕴含更大的可能性（这样的灵活性是被激励的，例如：UNIX），所以这就对于根底软件厂商的售前和解决方案工程师提出了更高的要求：很多业务须要的「个性」是须要多个「技术点」组合进去的，或者通过疏导到正确的问题从而提供更好的解决方案。上面我会通过几个例子来阐明这个观点：

第一个例子，咱们的常常被用户问到：TiDB 有没有多租户性能？
这个问题的我的回复并不是简略的「有」或者「没有」，而是会去开掘用户真正想要解决的问题是什么？潜台词是什么？在多租户的例子中大略逃不出上面几种状况：

1. 潜台词 1：「每个业务都部署一套 TiDB，太贵了」，价值点：节约老本
2. 潜台词 2：「我的确有好多套业务应用 TiDB, 对我来说机器老本不是问题，然而配置管理太麻烦，还要挨个降级，监控什么的还不能复用」，价值点：升高运维复杂度
3. 潜台词 3：「我有些场景特地重要，有些场景没那么重要，须要区别对待，对于不重要的我要共享，然而对于重要的要能隔离」，价值点：资源隔离 + 对立管控
4. 潜台词 4：「我有监管要求，例如不同租户的加密和审计」，价值点：合规
   搞清楚状况后，对于这几种不同的状况，我就拿其中一个作为例子：节约老本，开展说说。下一步就是思考咱们手上有什么菜了。
   对于 TiDB 5.x 来说，大抵有上面几个技术点和下面这个个性相干：
5. Placement Rule in SQL（灵便的决定数据搁置的性能）
6. TiDB Operator on K8s
7. XX（PingCAP 的一个新的产品，临时还没公布，请期待，大抵是一个多集群可视化管控的平台）
8. TiDB Managed Could Service
   对于节约老本的诉求，通常的起因是冷热数据比例比拟迥异，咱们察看到少数大集群都合乎 2/8 准则，也就是 20% 的数据承载 80% 的流量，而且尤其是对于金融类型业务，很多时候数据是永远不能删除的，这就意味着用户也须要为冷数据领取存储老本，这种状况依照对立的硬件规范去部署这其实是不划算的，所以站在用户的角度，是很正当的诉求。
   下一步须要思考的是：世界上没有新鲜事，用户当初是通过什么方法解决这样的问题呢？
   相似冷热拆散这样的场景，我见过比拟多的计划是冷数据用 HBase 或者其它比拟低成本数据库计划（例如 MySQL 分库分表跑在机械磁盘上），热数据依然放在 OLTP 数据库里，而后定期依照工夫索引（或者分区）手动导入到冷数据集群中。这样对于应用层来说，就要晓得的哪些数据去哪里查问，相当于须要对接两个数据源，而且这样的架构通常很难应答突发的冷数据读写热点（尤其是 ToC 端业务，偶然会有一些「挖坟」的突发流量）。
   而后下一个问题是：咱们的产品解决这个问题能给用户带来哪些不一样？如果还是须要用户手动做数据搬迁，或者搭建两个配置不同的 TiDB 集群，那其实没什么大的区别，在这个场景外面，如果 TiDB 可能反对异构集群，并且主动能将冷热数据固化在特定配置的机器上，同时反对冷数据到热数据主动替换，对用户来说体验是最好的：一个 DB 意味着业务的改变和保护老本最低。在 TiDB 5.4 外面公布了一个新的性能，叫做 Placement Rules in SQL, 这个性能能够让用户应用 SQL 申明式的决定数据的散布策略，天然能够指定冷热数据的散布策略。更进一步，对于多租户要求的更简单数据分布形式，例如不同租户的数据搁置在不同的物理机上，然而又能通过一个 TiDB 集群对立管控，通过 Placement Rules in SQL 这个性能也能实现。
   
   Meta Feature：解决方案架构师的宝藏
   说到这里，我想进一步开展一个概念，有一些性能和其它性能不一样，这类性能能够作为构建其它性能的根底，组合出新的个性。这类性能我称之为：Meta Feature，下面提到的 Placement Rule 就是一个很典型的 Meta Feature, 例如：Placment Rule + Follower Read 能够组合成靠近传统意义上的数据库一写多读（然而更灵便，更加细粒度，特地适宜临时性的捞数或者做长期的查问，保证数据陈腐的状况下，不影响在线业务），Placement Rule + 用户自定义的权限零碎 = 反对物理隔离多租户；Placement Rule + Local Transaction + 跨核心部属 = 异地多活（WIP）；Placement Rule 还能够将精心设施数据的搁置策略，让 TiDB 防止分布式事务（模仿分库分表），晋升 OLTP 性能。

Meta Feature 通常不太会间接裸露给终端的用户，因为灵活性太强，用户会有肯定的学习老本和上手门槛（除非通过精心的 UX 设计），然而这类能力对于架构师 / 解决方案提供商 / 生态合作伙伴尤其重要，因为 Meta Feature 越多，一个零碎的‘可玩性’越高，造出来的差异化计划也越多。然而通常咱们会犯一个谬误：灵活性是否等于产品价值？我认为不是的，尽管工程师（尤其是 Geek）对这类凋谢能力有天生的好感，然而对于终端用户到底是否说好这样的故事，我是存疑的，看看 Windows 和 UNIX 的终端用户的市场占有率就晓得了。在这个例子上最近我听到了个绝佳的例子，和大家分享：你并不能对一个美式的爱好者说拿铁更好，因为你能够灵便的管制含奶量，奶升高到 0 就蕴含了美式。
咱们再看一个场景，对于批处理。相熟 TiDB 历史的敌人必定晓得咱们最早这个我的项目的初心其实是从 MySQL Sharding 的替换开始的，起初缓缓的很多用户发现：反正我的数据都曾经在 TiDB 里了，为什么不间接在下面做计算？或者原来一些应用 SQL 做的简单的数据变换工作遇到了单机计算能力瓶颈，而且因为一些业务要求，这些计算还须要放弃强一致性甚至 ACID 事务反对，一个典型的场景就是银行的清结算业务，原本年老的我还不太了解，这类批处理业务间接 Hadoop 跑就好了，起初理解分明状况当前才发现还是年老了，对于银行来说，很多传统的清结算业务是间接跑在外围的数据库上的，而且业务也不简略，一个 Job 上百行的 SQL 粗茶淡饭，很可能开发这个 Job 的开发商曾经不见了，谁也不敢轻易改写成 MR Job，另外对于批量后后果，可能还要回填到数据库中，而且整个过程须要在短短几个小时内实现，完不成就是生产事变。本来如果数据量没那么大，跑在 Oracle，DB2 小型机上也没啥问题，然而最近这几年随着挪动领取和电子商务的衰亡，数据量越来越大，增长也越来越快，Scale-Up 肯定迟早成为瓶颈。TiDB 在其中正好切中两个很高的价值点：

1. SQL 兼容的能力（尤其在 5.0 反对 CTE 后和 5.3 引入的长期表性能，简单 SQL 的兼容性和性能失去很好晋升），也反对金融级的一致性事务能力。
2. 横向的计算扩大能力（尤其在 5.0 反对 TiFlash MPP 模式后，解锁了在列式存储上进行分布式计算的能力），实践上只有有足够多的机器，吞吐可能扩大下来。
   对于银行的批量业务来说，令人头疼架构革新问题变成了简略的买机器的问题，你说香不香。然而在 TiDB 晚期设计的解决方案中，有几个痛点：
3. 大批量数据导入
4. 分布式计算
   对于第一个问题，通常一个典型的 TiDB 做批量工作的流程是：下档（每日的交易记录通过文件的模式公布）-> 将这些记录批量写入到 TiDB 中 -> 计算（通过 SQL）-> 计算结果回填到 TiDB 的表中。档案记录可能是一大堆文本文件（例如 CSV）格局，最简略的写入形式必定就是间接一条条记录用 SQL Insert 的形式写入，这个形式解决点小数据量问题不大，然而数据量大的话，其实是比拟不划算的，毕竟大多数导入都是离线导入，尽管 TiDB 提供大事务（单个事务最大 10G），然而站在用户的角度有几个问题：
5. 批量写入通常是离线的，这种场景用户的外围诉求是：快！在这种场景下，残缺的走完分布式事务的流程是没必要的。
6. 尽管有 10G 的边界，对于用户来说也很难切割得准确。
7. 大事务的写入过程中意味着须要更大的内存缓存，这点经常被疏忽。
   一个更好形式是反对物理导入，间接分布式的生成底层存储引擎的数据文件，分发给存储节点，直接插入物理文件，也就是 TiDB 的 Lightning 做的事件。在最近的一个实在用户的场景察看到，Lightning 应用 3 台机器，大略在 72h 内实现了 ~30T 的原始数据的转码和导入工作，大略导入吞吐能做到 380GB/h。所以在批量的场景中，能应用 Lightning 物理导入模式的话，通常是一个更快且更稳固的解。
   另外的一个痛点，计算瓶颈（听起来还听不合理的，哈哈哈），在晚期 TiDB 还不反对 MPP 的时代，TiDB 只反对 1 层的算子下推，也就是 Coprocessor 散布在 TiKV 中的计算的后果只能汇总在一台 TiDB 节点上进行聚合，如果两头后果过大，超过了这个 TiDB 节点的内存，就会 OOM，这也就是为什么过来 TiDB 须要引入 Spark 来进行更简单的分布式计算的起因（尤其是大表和大表的 Join），所以在过来对于简单的批量业务还是须要引入一批 Spark 的机器通过 TiSpark 对 TiDB 的计算能力进行补充。然而在 TiDB 5.0 后引入了 TiFlash 的 MPP 模式，能够通过多个 TiDB 节点进行计算结果聚合，于是计算能力并不再是瓶颈了，这意味着，很有可能在一些 TiDB 的批量计算场景中，5.0 可能节俭一批 Spark 的机器，意味着更简略的技术栈和更高的性能。
   更进一步，引入 Spark 还有一个起因，就是在计算结果回填的阶段，因为 TiDB 的事务大小限度，以及晋升并发写入的效率，咱们会应用 Spark 来对 TiDB 进行分布式的数据插入。这个过程实践上也是能够通过 Lightning 改良的，TiFlash MPP 能够将后果数据输入成 CSV，Lightning 是反对 CSV 格局的数据导入的。
   所以原来的链路实践上有可能变成：Lightning 导入数据到 TiDB -> TiDB 应用 TiFlash MPP 进行计算结果输入成 CSV -> 再次通过的 Lightning 将 CSV 后果写入到 TiDB 中；有可能比应用 TiSpark + 大事务的计划更快更省资源，也更稳固。

在这个计划上咱们能够再延长一下认真想想，下面的计划优化其实是利用了 Lightning 的大批量数据写入能力，实践上有‘大写入压力’的数据导入场景，都能够通过这个思路改良。我这里分享一个 TiDB 的用户实在反馈：这个客户业务零碎上到 TiDB 后，会有定期大表导入的场景，他们心愿先将大空表通过 Placement Rule 指定到特定闲暇主机，而后通过 Lightning 疾速导入数据，不须要思考限流等措施也能够升高对整体集群的影响，实现疾速导入；相同的，如果 TiDB 没有这个调度能力，客户只能通过限流的形式放弃集群稳固，然而导入速度会很慢。这个例子是通过 Placement Rule + Lightning 实现了在线的批量写入，也是很好的响应了一下后面对于 Meta Feature 的形容。
原本在线下的分享中还有对于‘分库分表’vs TiDB 的例子，因为篇幅关系就不开展了，感兴趣的能够依照下面的思路去思考。
更隐式，但更大更长期的价值：可观测性和 Troubleshooting 能力
最初一部分，大家也能看到，最近其实我始终在致力的传播这个 Message，对于一个根底软件产品来说，一个重要的长期竞争力和产品价值来自于可观测性和 Troubleshooting 能力。这个世界没有完满的软件，而且对于有教训的开发者来说，疾速的发现和定位问题的能力是必备的，对于根底软件的商业化来说，服务反对效率和 Self-serving 也是规模化的根底。我这里说一些咱们最近做的一些新的事件，以及将来面临的挑战。
TiDB Clinic (tiup diag)
为什么要做这个事件？过来咱们在做故障诊断的时候，是一个苦楚的过程，除了我在之前的对于可观测性的文章中提到的老司机的教训只在老司机脑子里的问题外，我察看到其实耗费工夫的大头来自于收集信息，尤其是部署在用户本人的环境中，用户对于系统诊断并不相熟，求助咱们的服务反对的时候，常常的对话是：
服务反对：请运行这个命令 xxx，而后通知我后果
客户：（2 小时后才给了后果）
服务反对：不好意思，麻烦在你们的监控界面上看某个指标的图表
客户：截图给你了
服务反对：不好意思的，时间段选错了。。。而后调整一下 grafana 的规定，再来一遍
客户：！@##￥#￥%
服务反对（隔了几天换了集体值班）：请运行这个命令 xxx，而后通知我后果
客户：之前不是给过了吗？
这样一来一回异步又低效的问题诊断是很大的苦楚的起源，以及 oncall 没方法 scale 的外围起因之一。用户的痛点是：

1. ‘你就不能一次性要完所有的信息吗？我并不知道给你哪些’
2. ‘信息太大太多太杂，我怎么给你？’
3. ‘我的 dashboard 在内网里，你看不到，我也只能截图’
4. ‘我不能裸露业务信息，然而能够提交诊断信息’
   然而反过来，TiDB 的服务反对人员的痛点是：
5. ‘原来猜想的方向不太对，须要另一些 metric 来验证’
6. ‘无奈残缺重现故障现场的 metrics 和零碎状态，我心愿自在的操作 Grafana’
7. ‘不同的服务反对人员对于同一个用户的上下文共享’
   于是就有了 Clinic 这个产品了，在用户批准的前提下：
8. 通过 tiup 一键主动收集和系统诊断相干的各种指标
9. 通过一直学习的规定引擎，自动化诊断一些常见谬误
10. 针对不同租户的诊断信息存储和回放平台（相似 SaaS）
    如果相熟 AskTUG（TiDB 用户论坛）的敌人，可能会看到相似这样的链接：https://clinic.pingcap.net/xxx（例如这个 case：https://asktug.com/t/topic/57…）
    对于用户来说，只须要在集群内执行一个简略的命令，就会生成下面这样的一个链接，把重要的诊断信息与 PingCAP 的业余服务反对人员共享，咱们在后盾能够看到：
    
    
    其实 TiDB Clinic 也是对于根底软件的维护性的一个新尝试：诊断能力的 SaaS 化，通过一个在云端一直强化的规定引擎，将故障的诊断和修复倡议和本地的运维部署结耦。这样的能力会变成用户抉择 TiDB 的一个新的价值点，也是 TiDB 很强的生态护城河。
    TiDB Dashboard 中 Profiling
    我心目中对于一个根底软件产品是不是好，我有一个特地的规范：自带 Profiler 的，基本上都是良心产品，可能把 Profile 体验做 UX 优化的，更是良心中的良心。例如 Golang 的 pprof，用过都说香。其实这个点说起来也不难做，然而关键时刻能救命，而且通常出事的时候也没法 Profile 了，这个时候如果零碎通知你，本人在故障的时候保留了一份过后的 profile 记录，这种雪中送炭似的帮忙的体验是很好的。

其实这个性能来自于几个咱们理论解决过的 oncall case，都是一些通过 metric 没法笼罩到的问题，有一大类故障，是遇到硬件瓶颈了，大略逃不过 CPU 和磁盘，磁盘瓶颈绝对好查，大抵看有没有大的 IO（Update / Delete / Insert）或者 RocksDB 自身的 Compaction 就好，然而 CPU 瓶颈的查找形式就含糊许多，Profiler 简直是惟一的形式：

1. CPU 的要害门路上的 Call Stack 是什么样子
2. 这些要害门路上的函数调用暗示了什么？
   第二个问题通常是查问题的要害，会给出一个优化的方向，例如咱们发现 SQL Parse/ 优化的 CPU 耗费特地大，这就暗示了应该应用 Plan Cache 这样的机制可能晋升 CPU 的利用率。
   目前 TiDB 在 5.x 中提供了两种 Profile 形式：手动 Profile 和主动继续 Profile，两种利用场景不同，手动的通常用于针对性的性能优化；主动继续 Profile 通常用于零碎呈现问题后的回溯。
   面临的挑战
   快结尾了，说点挑战。PingCAP 是在 2015 年成立的，到当初曾经马上就要 7 岁了，在这 7 年里，正好经验了一些很重要的行业改革：
3. 数据库技术从分布式系统过渡到云原生；尽管很多人可能感觉这两个词并不是一个层面上的概念，因为云原生也是分布式系统实现的呀？然而我感觉云原生是一种设计零碎的思考形式的基本扭转，这点我在我其余很多文章里提过，就不赘述了。
4. 开源的数据库软件公司找到了可规模化商业化的模式：在云上的 Managed Service。
5. 寰球的根底软件畛域正在经验从‘能用’变成‘好用’的阶段
   这几点别离代表两个方向上的认知扭转：
6. 在技术上，须要实现从依赖计算机的操作系统和硬件变成依赖云服务，这一点对于技术的挑战是微小的，例如：应用 EBS 的话，是否 Data Replication 还是必须的？应用 Serverless 的话，是否可能突破无限的计算资源的限度？如果这个问题再叠加上已有的零碎可能有大量的现有用户会变得更加简单，当然，云原生技术并不等于私有云 Only，但如何设计出一条门路，缓缓的过渡到以云原生技术为根底的新架构上？这会是对于研发和产品团队一个微小的挑战。

7. 第二个扭转会是更大的挑战，因为商业模式在转变，在传统的开源数据库公司，支流的商业模式是以服务反对为主的人力生意，高级一点是相似 Oracle 这样的卖保险的生意，然而这些商业模式都没有方法很好的答复两个问题：

   1. 商业版和开源版的价值差别
   2. 如何规模化，曾经靠人力是无奈规模化的

   而 SaaS 的模式则能够很好答复这两个问题，而且基础设施类的软件和 SaaS 的模式交融后会有更大的放大效应，我在《大教堂终将倒下，但集市永存》一文提及过，然而真正的挑战在于：一个面向传统软件售卖 + 服务反对导向的软件公司的组织如何调整为一个面向经营的线上服务公司？以研发体系为视角，举几个小例子：1. 版本公布，对于传统软件公司来说，一年公布 1～2 个版本就不错了，然而线上服务有可能一个礼拜就降级一次，不要小看这个发版节奏的差别，这个差别决定了整个研发和品质保障体系模式的差别。2. 如果在云上提供服务，那么就须要配套的经营支持系统（计费，审计，故障诊断等）以及相应的 SRE 团队，这些零碎可能并不在传统的软件研发体系外面，另外对于用户体验和开发者体验的关注变得尤其重要。

当然挑战也不止这些，也都没有标准答案，不过我还是对将来充满信心的，毕竟这些趋势实质上都是在减速技术到社会价值和商业价值的转化以及升高门槛，都是好的且求实的转变，这对于 PingCAP 这样的公司来说当然是利好，后方是星辰大海，一切都是事在人为，大有可为。原本就想写一篇小文，没想到写着写着就扯得有点长了，就到这里吧，祝大家新春愉快。