上周末系統(tǒng)變更，配合DBA在IBM小型機上升級DB2的數(shù)據(jù)庫版本，貌似很平常的一件事，但是心里卻起了波瀾。

外面的世界早就變了樣，而我們卻依然在DB2這條路上慣性前行。

1977年，硅谷一個30多歲的男人，憑借IBM的一個“失誤”，成功開發(fā)了世界上使用最廣泛，最成功的關系型數(shù)據(jù)庫產(chǎn)品，就是后來的Oracle。到了1995年，IBM才發(fā)布了其關系型數(shù)據(jù)庫產(chǎn)品，DB2。

而我，直到2003年，才開始學習DB2，起步晚不說，還是個冷門。一轉(zhuǎn)眼，在這條路走了十多年，為什么不換條路呢？

數(shù)字化轉(zhuǎn)型的新基建

今天，像Oracle、DB2這樣的傳統(tǒng)關系型數(shù)據(jù)庫已經(jīng)風光了30多年，至于未來，他們應該還會存在，但是我們看到的是，越來越多的應用場景被新產(chǎn)品和新技術替代。

目前，大多數(shù)NoSQL都是面向特定任務而設計出來的，這讓我們有了更多的選擇，如果一味的只用關系型數(shù)據(jù)庫，可能會適得其反。

鍵值，列式，文檔和圖，四種NoSQL就像是四大名捕，各個身懷絕技。尤其是圖數(shù)據(jù)庫，這兩年特別火。根據(jù)Garnter的研究分析，未來幾年，圖數(shù)據(jù)庫將會以100%的速度增長。

最近在看任澤平等人合著的《新基建》，書中提到凡是符合未來新時代經(jīng)濟社會發(fā)展需要的基礎設施都叫“新基建”。

相對于傳統(tǒng)的關系型數(shù)據(jù)庫，新型的圖數(shù)據(jù)庫就像是數(shù)據(jù)中心里的“新基建”，可以從數(shù)據(jù)挖掘的視角，去審視和發(fā)現(xiàn)大數(shù)據(jù)中存在的有價值的關系。

什么是圖數(shù)據(jù)庫？

我們今天所說的圖（Graph），是圖論的主要研究對象，是由若干頂點（Vertices）和邊（Edges）組成的，用來存儲實體的相關屬性以及它們之間的關系信息。

圖實際上是一個很古老的概念，最早出現(xiàn)在瑞士數(shù)學家歐拉的學術論文中，試圖解決一個叫“哥尼斯堡七橋”的問題。

隨著社交、電商、零售等行業(yè)的迅猛發(fā)展，這些行業(yè)逐漸形成了一張張基于大數(shù)據(jù)的關系網(wǎng)，如何發(fā)現(xiàn)關系，利用關系是亟需解決的問題。

而在面對復雜復雜關系的處理上，圖是最佳的解決方案。利用圖表現(xiàn)對象與對象之間的關系，在圖上運用數(shù)學算法求解就可以有效解決鏈接爆炸的問題，降低復雜性，簡化查詢。

說起圖應用的案例，其實很多，最著名的就是Google的PageRank算法，再比如Linkedin用圖管理社交關系，實現(xiàn)好友推薦，Amazon用圖實現(xiàn)實時的商品推薦，商業(yè)銀行用圖做風控、實現(xiàn)反欺詐和反洗錢。

虎虎生威的TigerGraph

說起圖數(shù)據(jù)庫，不得不提大名鼎鼎的Neo4j，尤其是其Cypher查詢語言，讓人有種耳目一新的感覺。

不過由于Neo4j社區(qū)版的功能有限，影響了其適用范圍。目前開源軟件社區(qū)中還有其他幾個競品，DGraph和JanusGraph，這二者都原生支持分布式，但是不支持SQL。另外一個重要的特征是，DGraph支持原生存儲，而JanusGraph需要借助外部存儲系統(tǒng)，導致其運維成本非常高。

后來，朋友向我推薦了一個第三代圖數(shù)據(jù)庫（Graph 3.0）的新產(chǎn)品，TigerGraph，與其技術人員交流后，發(fā)現(xiàn)產(chǎn)品確實有過人之處。

總結(jié)一下我對TigerGraph學習和理解：

支持原生圖存儲，使得空間占用更少，相比傳統(tǒng)關系型數(shù)據(jù)庫在容量上平均減少50%。

支持并行計算的分布式部署，高效并行加載數(shù)據(jù)，支持數(shù)據(jù)分片，利于橫向擴展。

支持HTAP混合交易負載，可以很好的處理數(shù)十億的實體和數(shù)千億的關系，實現(xiàn)亞秒級的查詢響應和更多跳的深度鏈接分析。

提供GSQL的專用查詢語言和GraphStudio可視化開發(fā)套件。不過TigerGrpah的GSQL與Neo4j的Cypher語法有一定的差別，目前二者正在制定新一代的GQL，專門用于圖數(shù)據(jù)庫查詢。

當然，TigerGraph還有很多特性，比如支持用戶可擴展的圖算法庫等，唯一美中不足的地方，TigerGraph是一款閉源軟件。

關于圖的一些思考

雖然圖數(shù)據(jù)庫在國內(nèi)互聯(lián)網(wǎng)行業(yè)應用較多，但是在金融保險領域的案例其實還很少。我司早期嘗試利用圖數(shù)據(jù)庫技術實現(xiàn)了家族營銷的業(yè)務創(chuàng)新。

組織是人的組織，組織內(nèi)部的關系也很重要。今天看到網(wǎng)上有文章講保險代理人的模式，從傳統(tǒng)的金字塔開始向前端小團隊、后端大平臺的方向發(fā)展，利用平臺賦能扁平靈活的小組織。關于營銷組織中的痛點，是不是也可以通過圖計算進行優(yōu)化，提升代理人隊伍的管理效率呢？

另一方面，在我自己專業(yè)的業(yè)務連續(xù)性管理方面，也是很好的圖計算應用場景，但是從建模到落地實施，估計也是長路漫漫。目前市面上的產(chǎn)品，好像也沒聽到過哪家是基于圖的方式研發(fā)的。

早期我們看到的MySQL對與Oracle的替代，使用的是分庫分表，讀寫分離的套路，其實不過是一個維度上的兩個點在競爭，但當你升到更高的維度，用圖的方式重構(gòu)數(shù)據(jù)時，就不再是彎道超車，屌絲逆襲了，而是變道超車，決勝千里。

目前的很多創(chuàng)新，都是在外圍展開的，對于真正核心的應用改造，無論在應用場景，還是理念上都有所欠缺。都知道創(chuàng)新這條路不好走，但如果是戰(zhàn)略性的，就要敢于投入，畢竟一旦成功，收益遠大于支出。

夢想總是要有的，萬一實現(xiàn)了呢。

DBA這碗飯還能吃多久

在一些有規(guī)模的公司里，DBA大概分成兩類。一類面向運維的，主要負責穩(wěn)定運行、性能調(diào)優(yōu)等；另一類，面向應用開發(fā)，主要是業(yè)務建模。

在Oracle最新的19C中，已經(jīng)開始講自動駕駛“Self-Driven”的概念了，試圖通過人工智能完成數(shù)據(jù)庫自治。

從前，Oracle數(shù)據(jù)庫除了專業(yè)的模型設計外，還提供大量的可配置參數(shù)，給了傳統(tǒng)DBA很大的操作空間，而現(xiàn)在，隨著數(shù)據(jù)庫產(chǎn)品自身越來越智能，DBA可操作的余地變少了，價值越來越低，就算遇上難纏的性能問題，也可以通過閃存這樣硬件幫忙把坑填了，而且速度還杠杠的，絕對比DBA優(yōu)化好使。

另一方面，自動化運維平臺也越來越普及，很多工作，在頁面上點點按鈕就搞定了，復雜的實施工作都被平臺屏蔽掉了。就好像那句話， 離開了平臺，你還是DBA，但有了平臺，你就是操作員。

沒有崗位是一成不變的，隨著像圖數(shù)據(jù)庫這樣的新技術的出現(xiàn)，讓一些傳統(tǒng)架構(gòu)下的復雜事務，變得簡單高效，性能甚至是百倍的提升。而分布式，多副本的集群技術，也讓原來的可用性和性能問題也逐漸弱化，DBA們也差不多是時候考慮轉(zhuǎn)轉(zhuǎn)型了。

寫在最后

當年，董事長提過新三大件，“買房、買車、買保險”。

房子，最重要的是什么？位置、位置、位置

汽車，最重要的是什么？安全、安全、安全

保險、最重要的是什么？保障、保障、保障

今天，你看看賣房的中介，從鏈家的VR視頻看房，到基于行業(yè)圖譜的貝殼找房，各個都是科技賦能的高手。

但是，對于保險公司，最重要的是，隊伍！隊伍！隊伍！

董事長說我們是一家偉大的銷售公司，科技賦能業(yè)務。當我們把各個渠道的代理人、客戶和產(chǎn)品等這些實體和關系，借助圖數(shù)據(jù)庫技術，充分發(fā)揮計算優(yōu)勢，進行深度的鏈接分析時，就是科技賦能隊伍，從而打造出一支高效能的、武裝精良的特種部隊。

如果把傳統(tǒng)的關系型數(shù)據(jù)表比作Excel，那么Graph就可以被比作PPT。兩樣技能肯定都是需要的，但是如果用來展現(xiàn)，你說哪個好？當然是，有圖有真相。

DBA從來都不是我職業(yè)的全部，但我依然選擇做一個隱形的DBA。

責任編輯：lq