想象一个日常场景：你在海底捞上排了号、点了餐、退了菜、结了账，踏出店门就收到了手机上友邦 APP 推送的健康课程，边看边走到了路边等车。不一会儿，你叫的新能源网约车来了，下车后顺手给了司机一个五星好评。

这是很多人都习以为常的场景。但如果把时间拉回到 10 年前，同样的流程不会那么顺滑，很多如今在手机上轻点手指就能完成的操作也无法实现。宏观上讲，是互联网的飞速发展带来了这些变化，但是如果我们把视角推到互联网底层技术的变革上，就会看到密密麻麻飞速流转的数据与代码。互联网时代，指数级增长的数据被存储、分析和调用，背后是 40 年来数据库作为底层技术的支持。

数据库发展史上出现过层次数据库、网状数据库和关系型数据库，如今业内主流是关系型数据库。从早期的结构化数据到数据仓库，再到如今的云数据库，面对云时代海量的数据，企业对数据库性能的要求越来越高。作为国内基础软件领域首次也是唯一进入 Gartner 全球数据库领导者象限的阿里云数据库产品事业部负责人，李飞飞曾谈到“让数据真正地无缝流动”是他对数据库的愿景。

阿里云也推出了面向不同数据类型的云数据库。在企业级数据库赛道上，阿里云已经推出了云原生数据库家族，PolarDB、PolarDB-X、AnalyticDB、Lindorm 等。云原生数据库究竟为企业带来了怎样的改变，又在业务场景中将迎来哪些新要求？《数据 Cool 谈》第二期，让我们与友邦人寿、海底捞和上海新能源汽车数据中心的资深专家一起一探究竟。

不再担心业务洪峰

按需付费、按需扩展、高可用性以及存储计算分离……是云数据库的优势，也是以 PolarDB 为代表的云原生数据库正在做的事情。优于传统数据库的性能，让 PolarDB 获得了友邦人寿和海底捞的青睐。

保险行业也有类似“双 11”这样的业务高峰期，是保险公司一年一度冲刺业绩的重要时段。保险业务团队集中签单，做“后勤保障”的技术人员也神经紧绷。友邦人寿对 PolarDB 的高度认可，也源于一次业务高峰期。

“因为我们之前用 RDS 遇到了切数据、扩容的问题，我们担心如果业务量出现了爆发式的增长，RDS 没办法快速地扩容支持这个事情。”友邦人寿云计算架构师罗林强谈道，“大家去赌一赌业务洪峰没那么高，碰碰运气，还是说顶着变更可能会造成故障的风险把 RDS 替换掉。在业务高峰期前这么做，风险还是蛮大的。管理层非常重视业务高峰期期间的系统稳定性。”

同样的业务洪峰，不只在保险行业出现。电商行业中 2015 年淘宝大部分业务都开始在阿里云上稳定运行；交通物流行业中 12306 网站将春运高峰的 75% 余票查询业务切换到了阿里云上。能稳定支持淘宝“双 11”和铁路春运的业务高峰，让阿里云数据库在业内站住了脚，同时也带来了友邦人寿的信任。

友邦人寿的数据库在 2015 年之前遇到了一些瓶颈。传统的 IDC 之下，数据库出现了 CPU 性能问题，但由于自身管控能力不足，在 CPU 占用率飙高时，当时没有配套的监控及时查明原因。“除了开单给供应商或者重启数据库，什么也做不了。”罗林强无奈地谈到当时的情景。

重启数据库治标不治本，在业务洪峰期，重启并不能带来数据库性能的本质性改变。友邦人寿开始尝试将销售一年期小额保单的电商系统迁移到阿里云上。“电商系统偶尔有赠险活动，会出现流量峰值，但影响不大。”罗林强谈道。这次迁移算是友邦人寿的一次试水。直到 2016 年，电商系统在阿里云数据库的支持下始终稳定运行，进一步加强了友邦人寿的信心。2017 年，友邦人寿决定将公司战略性项目健康友行 APP（现名友邦友享）迁移上云。

当时，客户热情超出了业务预估，导致友邦人寿使用的 RDS 不断的扩容，扩容需要时间。由于 RDS 计算资源不足，所需算力更大，数据搬运时间变长。每日几十万的查询量，为友邦人寿在用的 RDS 带来了不小的压力。罗林强谈到，友邦人寿将健康友行 APP 的数据库迁移到了 PolarDB 上，这些问题才迎刃而解。他表示，PolarDB 一写多读的能力，相较 RDS 主备模式，更加灵活也更加省钱，在后期想要单独调用数据读取查询时，读写分离功能也能实现对应用的非侵入。

RDS 在友邦人寿业务上的局限性同样也在海底捞有所体现。餐饮行业具备就餐高峰时间集中的特征，高峰期的排号、点餐等场景都要求数据库有高并发和弹性的能力，维持业务稳定性。作为国内餐饮行业三巨头之一的海底捞，在全国有近 8500 万会员，在全球开店，部分门店实行 24h 运营，对数据库有高稳定性、同城容灾备份、快速高可用切换的诉求。

海底捞技术 Leader 张坤透露，为了实现会员管理、运营和营销，发起了海底捞史上最大的 IT 项目——海底捞 APP，数据量级在 10 亿左右。因此，海底捞对底层数据存储的诉求有三点：十亿级数据灵活多维度查询；降低研发上手和使用成本；运维简单，有非常好的扩展能力。如今海底捞 APP 在交互类数据库选型上主要考虑两点：深挖会员需求，提高会员满意度；丰富技术能力，支持业务拓展。

在考察了业内的云数据库产品后，海底捞认为无论从场景还是生态上还是在技术能力上，PolarDB 与业务诉求更加契合。“问题出现就要解决问题，现在我们正逐步把更多的系统、数据库都迁移到 PolarDB 上。”张坤谈道，“海底捞还将 PolarDB 全球数据库 GDN（Global Database Network)，用在全球官网上，通过在管理后台发布相关的内容，即可同步到其他区域，实现跨国、跨城市数据实时同步。”

不再担心数据繁杂

Lindorm 是阿里云数据库推出的专门为物联网 AIoT 打造的云原生多模数据库，核心特点就是提供大规模、多模异构数据存储的云原生数据库服务，让数据看得见、存得起。这与上海新能源汽车数据中心业务层面对数据库的诉求不谋而合。

上海市新能源汽车公共数据采集与监测研究中心技术总监王成名介绍，上汽新能源汽车数据中心接入了 58.9 万辆车的数据，每一辆车包含 128 项静态和动态的数据项，还有类似结构化的电池溯源数据和类时序数据库的氢能源汽车数据平台等。

可以看到，上汽新能源数据中心的数据包括：新能源汽车的数据，电车溯源的数据，燃料企业及加氢站的数据和智能网联汽车数据，数据类型有结构化、半结构化以及流媒体二进制的数据。数据类型多样，数据量巨大。

2014 年到 2019 年，上汽新能源一直基于开源 Hadoop 体系自研开源，但是很快发现，相较于将大量精力放在技术底层运维上，更应该将精力放在业务分析和技术开发上。横向对比了市面上的多家云厂商后，王成名谈到，海量数据需要存储分层，实时数据需要实时归档，冷热数据需要一体化存储，系统需要大规模运维，这些都是当时技术选型的诉求，恰好 Lindorm 提供了这样的解决方案，所以上海新能源汽车数据中心成为了 Lindorm 的第一批用户。

Lindorm 可以支持不同类型的数据类型，比如宽表、文件、时序等。存储方面，Lindorm 提供了容量和性能两种选择，也恰恰是上汽新能源汽车中心对数据库的综合选择标准。

“我们在使用 Lindorm 之前是自研的模式去做，用线下 IDC 和开源的 Hadoop 体系里面的一个组件。由于我们是多技术架构融合的架构，带来的问题就是运维成本很高，开源性能也有局限性，比如默认压缩，查询性能限制。我们发现运维能力和数据性能也不够，所以就用了 Lindorm。用下来发现，从数据入口上统一了入口，多模也降低了技术使用成本。不仅在技术成本上降低了，经济成本也降低了。”王成名谈道，“我可以把它以 API 的方式去兼容那些典型的业务处理场景。数据库发展从单体到分布式，再到多模，降低了技术人员开发门槛，成本降低了。”

如今，上海新能源汽车数据中心希望 Lindorm 可以通过技术手段挖掘分析越来越复杂的流媒体数据，目前来看，通过特征提取后结构化建模和湖仓一体化或许是两种可行的解决方案。

“解决问题，降低成本”是云数据库被选择的坚定理由，但是云数据库为企业带来的改变不止于此。“其实上云不只是增加了我们的弹性的能力和稳定性，而是能够让我们有机会离开 IDC 到一个新的环境里，思考重新架构应用。我们现在还没有做到架构重构，但是我们在往那个方向走。” 王成名谈道。

写在最后

云时代下，大数据和数据库的技术边界、离在线数据处理的技术边界越来越模糊。企业对于云数据库的诉求，不仅仅在于支持现有业务的运行，还希望做到上层应用无感知的稳定。弹性扩容、安全稳定、多写多读、容灾备份、云原生多模、存储计算分离……这些是如今企业需要的数据库能力。

可以看到的是，结合云原生，数据库从时序数据向多模数据演进，加强对半结构化、非结构化等数据类型的实时处理、融合处理能力，提供一站式的数据管理与服务，把传统的 OLTP、OLAP、MPP 数据库打通，将是数据库厂商在技术上深耕的方向。