上周末系统变更，配合DBA在IBM小型机上升级DB2的数据库版本，貌似很平常的一件事，但是心里却起了波澜。
外面的世界早就变了样，而我们却依然在DB2这条路上惯性前行。
1977年，硅谷一个30多岁的男人，凭借IBM的一个“失误”，成功开发了世界上使用最广泛，最成功的关系型数据库产品，就是后来的Oracle。到了1995年，IBM才发布了其关系型数据库产品，DB2。
而我，直到2003年，才开始学习DB2，起步晚不说，还是个冷门。一转眼，在这条路走了十多年，为什么不换条路呢？
数字化转型的新基建
今天，像Oracle、DB2这样的传统关系型数据库已经风光了30多年，至于未来，他们应该还会存在，但是我们看到的是，越来越多的应用场景被新产品和新技术替代。
目前，大多数NoSQL都是面向特定任务而设计出来的，这让我们有了更多的选择，如果一味的只用关系型数据库，可能会适得其反。
键值，列式，文档和图，四种NoSQL就像是四大名捕，各个身怀绝技。尤其是图数据库，这两年特别火。根据Garnter的研究分析，未来几年，图数据库将会以100%的速度增长。
最近在看任泽平等人合著的《新基建》，书中提到凡是符合未来新时代经济社会发展需要的基础设施都叫“新基建”。
相对于传统的关系型数据库，新型的图数据库就像是数据中心里的“新基建”，可以从数据挖掘的视角，去审视和发现大数据中存在的有价值的关系。
什么是图数据库？
我们今天所说的图（Graph），是图论的主要研究对象，是由若干顶点（Vertices）和边（Edges）组成的，用来存储实体的相关属性以及它们之间的关系信息。
图实际上是一个很古老的概念，最早出现在瑞士数学家欧拉的学术论文中，试图解决一个叫“哥尼斯堡七桥”的问题。
随着社交、电商、零售等行业的迅猛发展，这些行业逐渐形成了一张张基于大数据的关系网，如何发现关系，利用关系是亟需解决的问题。
而在面对复杂复杂关系的处理上，图是最佳的解决方案。利用图表现对象与对象之间的关系，在图上运用数学算法求解就可以有效解决链接爆炸的问题，降低复杂性，简化查询。
说起图应用的案例，其实很多，最著名的就是Google的PageRank算法，再比如Linkedin用图管理社交关系，实现好友推荐，Amazon用图实现实时的商品推荐，商业银行用图做风控、实现反欺诈和反洗钱。
虎虎生威的TigerGraph
说起图数据库，不得不提大名鼎鼎的Neo4j，尤其是其Cypher查询语言，让人有种耳目一新的感觉。
不过由于Neo4j社区版的功能有限，影响了其适用范围。目前开源软件社区中还有其他几个竞品，DGraph和JanusGraph，这二者都原生支持分布式，但是不支持SQL。另外一个重要的特征是，DGraph支持原生存储，而JanusGraph需要借助外部存储系统，导致其运维成本非常高。
后来，朋友向我推荐了一个第三代图数据库（Graph 3.0）的新产品，TigerGraph，与其技术人员交流后，发现产品确实有过人之处。
总结一下我对TigerGraph学习和理解：
*支持原生图存储，使得空间占用更少，相比传统关系型数据库在容量上平均减少50%。
*支持并行计算的分布式部署，高效并行加载数据，支持数据分片，利于横向扩展。
*支持HTAP混合交易负载，可以很好的处理数十亿的实体和数千亿的关系，实现亚秒级的查询响应和更多跳的深度链接分析。
*提供GSQL的专用查询语言和GraphStudio可视化开发套件。不过TigerGrpah的GSQL与Neo4j的Cypher语法有一定的差别，目前二者正在制定新一代的GQL，专门用于图数据库查询。
当然，TigerGraph还有很多特性，比如支持用户可扩展的图算法库等，唯一美中不足的地方，TigerGraph是一款闭源软件。
关于图的一些思考
虽然图数据库在国内互联网行业应用较多，但是在金融保险领域的案例其实还很少。我司早期尝试利用图数据库技术实现了家族营销的业务创新。
组织是人的组织，组织内部的关系也很重要。今天看到网上有文章讲保险代理人的模式，从传统的金字塔开始向前端小团队、后端大平台的方向发展，利用平台赋能扁平灵活的小组织。关于营销组织中的痛点，是不是也可以通过图计算进行优化，提升代理人队伍的管理效率呢？
另一方面，在我自己专业的业务连续性管理方面，也是很好的图计算应用场景，但是从建模到落地实施，估计也是长路漫漫。目前市面上的产品，好像也没听到过哪家是基于图的方式研发的。
早期我们看到的MySQL对与Oracle的替代，使用的是分库分表，读写分离的套路，其实不过是一个维度上的两个点在竞争，但当你升到更高的维度，用图的方式重构数据时，就不再是弯道超车，屌丝逆袭了，而是变道超车，决胜千里。
目前的很多创新，都是在外围展开的，对于真正核心的应用改造，无论在应用场景，还是理念上都有所欠缺。都知道创新这条路不好走，但如果是战略性的，就要敢于投入，毕竟一旦成功，收益远大于支出。
梦想总是要有的，万一实现了呢。
DBA这碗饭还能吃多久
在一些有规模的公司里，DBA大概分成两类。一类面向运维的，主要负责稳定运行、性能调优等；另一类，面向应用开发，主要是业务建模。
在Oracle最新的19C中，已经开始讲自动驾驶“Self-Driven”的概念了，试图通过人工智能完成数据库自治。
从前，Oracle数据库除了专业的模型设计外，还提供大量的可配置参数，给了传统DBA很大的操作空间，而现在，随着数据库产品自身越来越智能，DBA可操作的余地变少了，价值越来越低，就算遇上难缠的性能问题，也可以通过闪存这样硬件帮忙把坑填了，而且速度还杠杠的，绝对比DBA优化好使。
另一方面，自动化运维平台也越来越普及，很多工作，在页面上点点按钮就搞定了，复杂的实施工作都被平台屏蔽掉了。就好像那句话， 离开了平台，你还是DBA，但有了平台，你就是操作员。
没有岗位是一成不变的，随着像图数据库这样的新技术的出现，让一些传统架构下的复杂事务，变得简单高效，性能甚至是百倍的提升。而分布式，多副本的集群技术，也让原来的可用性和性能问题也逐渐弱化，DBA们也差不多是时候考虑转转型了。
写在最后
当年，董事长提过新三大件，“买房、买车、买保险”。
房子，最重要的是什么？位置、位置、位置
汽车，最重要的是什么？安全、安全、安全
保险、最重要的是什么？保障、保障、保障
今天，你看看卖房的中介，从链家的VR视频看房，到基于行业图谱的贝壳找房，各个都是科技赋能的高手。
但是，对于保险公司，最重要的是，队伍！队伍！队伍！
董事长说我们是一家伟大的销售公司，科技赋能业务。当我们把各个渠道的代理人、客户和产品等这些实体和关系，借助图数据库技术，充分发挥计算优势，进行深度的链接分析时，就是科技赋能队伍，从而打造出一支高效能的、武装精良的特种部队。
如果把传统的关系型数据表比作Excel，那么Graph就可以被比作PPT。两样技能肯定都是需要的，但是如果用来展现，你说哪个好？当然是，有图有真相。
DBA从来都不是我职业的全部，但我依然选择做一个隐形的DBA。