我叫汪洋，来自平安科技，在平安科技做了八年，目前负责两个团队，存储产品团队和数据库产品团队，全都跟数据有关。

平安科技是平安集团的全资子公司，它有三个职能，一个集团的高科技内核，二是创新孵化器，这两年也开始将技术和服务对外输出。

今天我讲的是平安在开源数据库方面的应用实践。对于很多金融公司来讲，受到一行两会的监管，在采用开源数据库的时候，基本保持观望的态度。而任何一家组织架构的转型，包括引入一些新的技术，都是有风险的，尤其是对于金融公司。大家都知道，平安集团就是一家综合金融公司，它覆盖了金融产品的方方面面。

那么为什么平安在这种情况下开始引入架构的转型，开始引入一些开源数据库，并且在内部推广？希望我今天的分享能给金融同业或其他公司带来一些借鉴。

如果我们能够让应用程序团队自己部署程序并维护底层基础设施，那么我们将更接近DevOps模型，并可以更快地采用云服务，这恰恰是我们IT战略的两个核心要素。

在 2013-2014 年的时候，很多像平安这样的传统公司都在探索怎么样进行互联网转型，那时 Gartner 提出双模式发展。

双模式发展就是为了适应传统企业向互联网转型的需要，一方面企业对于传统的应用系统仍然需要三高，即高可用高可靠高性能；另一方面要快速响应，在自己的领域内能够向互联网转型，这就要求敏捷开发，敏捷交付。这个时候过去的单体架构带来很多问题：

而微服务架构的崛起，能够把一个单体架构拆成各个模块，针对模块进行扩容，因为每个模块有不同的负载特性，模块之间是松偶合的，微服务架构的崛起就带来它底层的持久化存储的需要。

微服务架构带来了多态性的存储。

为什么会有多态性，因为我们的数据不再向以前一样：以前的我们追求高一致性，都是企业化数据，但是在很多互联网场景下我们做秒杀时并不需要那么高的一致性，它的数据格式也是不一样的，因此也出现了不同的存储引擎。

随着微服务的发展，可根据他自己的特性、数据格式、采取不同的数据库。

现在不是 One for all，而是 Best fit，每个业务场景都有特定的数据库。所以我说技术没有对错，没有最好，只有适合业务场景的技术。

以 Oracle 为例，大约二十年前我学习的时候只有几本书，现在的书可能一个房间都装不下，安装 Oracle 软件也是，都很大。

但是装 MySQL，都是轻量的，只有几十或几百兆，部署也相对简单，这有利于快速试错，快速把市场需求转换为产品原型，快速推向市场。总之技术都是服务于业务。

还有我们是被开发人员倒逼，他们为了满足业务需求使用开源数据库，如果运维方面跟不上的话，运维会成为背锅侠，因为最终生产出问题是落在了运维身上。

从整体看，开源数据库并不是免费的，使用开源数据库是一个循序渐进过程，在使用开源数据库时不能牺牲系统稳定性，因此需要许多其他方面的成本投入。

学习成本是针对开发和运维人员的，因为数据库对开发人员从来不是一个黑盒子，当数据库体量变大时，肯定会遇到各种各样的问题，所以开发和运维都存在一个学习周期。

虽然世面上很多迁移工具可以节省开发人员的投入，实际上这些工具没有尽善尽美，特别是在代码迁移上，虽然转换过来功能可行，但你会发现代码几乎是不可读的。

所以宁愿把业务逻辑重构，重新看一遍，再用新数据库语法重新写一遍，在迁移过程中，数据迁移占小，代码迁移才是大头。

需要对数据库有很深的了解，才能在发生问题时快速定位，解决问题，事件响应机制、监控指标等都是维护成本。

掌握开源技术也需要一个过程，充分应用现有开发和运维技术，比如我当初为什么会选 PostgreSQL，PostgreSQL 对现有一直在 Oracle 系统上的运维和开发团队来说，学习曲线是相对来说比较短，能够快速进行迁移。

增加运维成本的风险，人员招聘、人员培训都有一个周期，数据库团队、产品、运维机制都需要在生产环境中不断的锤炼，才能变得不断完善、成熟。

▲ 如何选择合适的开源数据库（1）

每个数据库都是服务一个业务场景的需求，平安集团的好处是业务场景非常丰富：产险、寿险、养老险、壹钱包、健康互联网、智慧城市等。

我们可以在业务场景中充分的验证这些开源数据库，哪些数据库适用于哪些业务场景，在场景中不断的打磨运维和开发团队。

你在使用的数据库有没有合适的替代方案，比如我想从 Oracle 迁移出来，选择什么数据库。在四五年前，我选择的是 PostgreSQL，现在证明当时的决定是对的。

你可以看到 AWS 有很多 RDS 服务，所有迁移的方案，都是从 Oracle 迁移到 PostgreSQL, 也就是说 PostgreSQL 跟 Oracle 是相近的，他们间的迁移成本和学习成本都相对是较少的。

过往有过 Oracle 经验的开发比较容易迁移到 PostgreSQL。

根据每个系统负载类型可以选择不同的开源数据库。

如果你选择一个开源数据库活跃度不高，你心里没底，你不知道它能不能发展下去，我们选择开源数据库希望尽可能的能用很长时间。

▲ 如何选择合适的开源数据库（2）

数据库处于出生期、成长期、成熟期、老年期的哪一个区域，需要了解它的生命周期，了解它在国外国内的一些应用情况来增加使用信心。

数据库本身的开发语言，能否匹配到现在团队成员所具备的技能。运维需要快速定位问题发生在哪一步，研发人员需要对开源数据库的代码进行改造，让他更适配应用场景，所以开发语言也是考虑因素。

我们在布局整个数据库组合时，要考虑在哪些数据库类型上进行布局，有很多数据库类型，但不是每个数据库类型都需要，所以需要选择。

希望所选择的数据库是未来技术发展的趋势。

如果数据库种类太多也会增加运维成本，因为每一个数据库都需要学习成本，在满足业务场景的需求下选择尽可能少的数据库产品，尽量做到标准化。

▲ 引入和应用策略（1）

现有的系统是已经运行生产的系统，它对运行的可用性有较高的要求，不能因为引入开源数据库就对系统性能造成影响。应该按照重要性进行分类，平安根据数据库按重要性分为三类。

不同业务线开放程度不一样，平安一些传统的大公司，如寿险、产险、银行，他们相对来说比较谨慎；但是一些互联网公司，如陆金所、壹钱包、健康互联网，他们比较积极进取，愿意进行新技术的尝试，当然要确保不会对业务造成大的影响，完善后再推广到传统公司。

数据库产品团队有一百多人，不太现实让每个人都去掌握多种数据库，特别在刚开始的时候，我会让一两个人去负责某个数据库产品，以点带面去对其他开发人员进行培训。其他的比如制定数据库架构、运营和开发的指南手册；对运营、开发以及 DBA 提供培训。

▲ 引入和应用策略（2）

另外，持续进行架构优化；积累开发和运营经验；学习源代码；建立自己的研发团队；加入开源社区，这些都是在引入时需要有一定的计划。

▲ 平安在使用的数据库产品

以下是平安各业务使用的不同类型开源数据库的选型策略：

▲ 数据库选型策略

第一个案例是我们今年在 1 月 8 号产险“财神节”活动使用 TiDB，25 个节点的集群，有主从两套架构，包括 TiDB, TiKV, 总共 25 个节点，主从之间通过 BinLog 做到异步同步。

业务高峰期数据，如每秒 10000+DML、平均每秒 1000 单、红包秒杀 TPS3000 等。单从 TPS 来看，数据不是很大，但对于每个业务场景，要看相对值而不是绝对值，因为每一个 Transaction 的复杂度是不同的，对于产险，一个 Transaction 中有多达上百个 SQL 语句。

其实这个产品当时搭建了 25 个节点，我们的标准规格是 NVMe，一时很难找到这么多的 NVMe 机器，因此采用 SSD，也是很好的满足了产险秒杀活动的需要。

第二个案例是寿险客户管理系统基于我们自研的 DRDS。因为客户信息数据非常重要，所以我们是把写的负载仍然放在 Oracle, 然后是实现读写分离。

读是用另外一个数据库集群、另外一个资源来实现，并且是在这个读上面来使用单独的架构，这是 35 个节点的集群，15 个节点是记录客户信息的变化，20 个节点是记录保单信息的。

通过客户服务和保单服务，来实现两个 DRDS 的集群，当客户查询的时候，就是去相应的集群上访问查询。

第三个案例，InfluxDB 是时序数据库中的佼佼者，时序数据库发展前景也是非常不错的，特别是在 IoT 时代，不停有大量的数据产生，对这些数据存储需要能支持高并发的写入，它具有非常强的优势；另外根据时间序列对数据进行分析聚合，在实际场景中也得到广泛的应用。

我们自己的数据库产品团队，是将它用在了监控系统上，去采集很多数据，我们现在有更多的监控对象，如 cpu, memory, nginx, I/O, 各种数据库等。

InfluxDB 的写入性能每秒可达到 35w，这在关系型数据库里面，单机的、在有index的情况下，很难想象能达到每秒 35w。还有并发查询与 PostgreSQL 相比的数据，时序数据库还是有比较明显的优势。

引入众多开源数据库之后，我们在平安云上，通过 Cloud Database 的方式，对外提供服务。一个方向是我们现在正在做云数据库容器化的部署，以期达到更高密度的部署、更强的自愈能力、更容易扩展的价值。

另一个方向是更多自研数据库产品，基于这些数据库产品开发出自主可控的数据库，比如基于分布式 KV 数据库开发出图数据库产品。

最后一个就是刚刚提到的 Cloud Database, 云提供商是有天然的做AIOps 的优势，因为做AI最重要的就是数据，数据量要大，而且数据样本要非常丰富。

小的公司要做 AIOps 是不太可能的，所以我们可以基于平安云来收集这些数据库的运营信息，结合人工智能和机器学习，进行更精细的异常检测、故障预测，能够进行更精细化的资源管理，来不断完善我们的产品。

以上，就是我关于平安在开源数据库方面的应用实践的一些分享，谢谢大家！