ssdfans 發表於 2021-01-07 10:35:58
上周末系統變更，配合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。
責任編輯：lq
打開APP閱讀更多精彩內容
聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容圖片侵權或者其他問題，請聯繫本站作侵刪。 侵權投訴