珠穆朗瑪峰在國內資料庫中的什麼位置？

最近，看到乙個大型國有銀行資料庫案例重新整理了我的認知

“國外頂級資料庫”沒有拿到的三個系統，都是由國內一家資料庫廠商拿下的。

可以說，這一次，國產資料庫不僅翻身了，還攀公升到了前所未有的高峰。

這有多“離譜”？聽我給你弄清楚

這是乙個國有銀行在真實案例中，該行總行核心區域的多個系統擁有跨越10年以上的線上交易資料。

我們先來看看這個令人頭疼的架構圖，它涉及到大量的資料應用和資料服務系統，而國際上三大頂級資料庫和資料倉儲工具共同支撐著這個亂象。

這些線上交易有多少資料？

總容量超過500TB！儲存於：oracle、mongodb、hive以及資料倉儲中的其他資料庫。

這包括銀行近10年各個企業的存取款資訊和交易流水，作為總行，你可想而知所有儲戶10年以上的歷史交易記錄，有多大。

這些資料支撐著多個關鍵渠道系統、多維度交易資訊查詢、實時收支分析等重要系統，屬於銀行核心交易區域服務屬性最強，服務型別最全面商。

讓我們舉乙個大家都知道的例子：例如，您需要檢查過去 5 年的銀行存款記錄

這聽起來很簡單，但你會發現大多數銀行並不支援這種超長實時查詢。 我剛剛試過另乙個大型國有銀行只能查詢最近兩年的流量，而且一次查詢的時間跨度不超過三個月。

為什麼，因為歷史資料量太大，後端資料庫無法支援這個長週期，大跨度資料訪問。

即使在這裡使用也是如此三款頂級產品資料訪問週期最長只能小於5年，資料跨度不能超過1年，有些企業甚至長達半年。

“三大資料庫”躺平？是的！

作為業界頂尖的集中式資料庫，單機實力迸發，可以輕鬆控制數十TB甚至上百TB的結構化資料（如絕大多數核心交易場景）。

但是，像現在這樣，資料量已經達到了500TB以上，這有點超出了O記憶體資料庫的舒適區（當然，人也不是不可能，例如，如果你花了大價錢背上頂級的Exadata X10M，你也許可以得到它）。

在這種極端情況下，大量的“線上+線下”資料基本無法解決，希望實現實時分析和檢索，但又不想付出高昂的代價。

例如，在這個專案中，o-memory資料庫不能說是沒有努力的：為了避免超大桌子對效能的影響導致了許多“表分片”操作。

每半年將資料劃分為乙個表，建立幾十個表，不僅增加了系統的複雜度，還直接限制了查詢跨度（最多6個月）。

操作猛如虎，但這些資料從未被振興。

久而久之，這些資料及相關應用就成了一匹死馬......無法治癒

就這樣“爛”了嗎？不可能！因為這些資料和上層業務太重要了。

於是，今年年初，這家大銀行再次以“死馬就是活馬醫”的心態出擊。

他們評估了市場上各種流行的資料庫解決方案：MySQL、PG、完全自研、集中式、分布式、所謂的 O 記錄替換......

最終，經過反覆對比和驗證，這家大型國有銀行選擇了TIDB資料庫。

我們先說結果，TIDB成功將“死馬”變成了“活馬”，解決了這個問題。

那麼，TIDB究竟是怎麼做到的呢？

讓我們勾勒出改造後的架構，是不是比以前簡單多了？

資料聚合：TIDB 提供彈性擴充套件和高併發寫入能力，支援基於訊息中介軟體的實時聚合和檔案交換的離線載入，覆蓋多種資料來源。

資料處理：流-批合，流計算基於 TIDB 的動態資料路由和原生分布式能力，與上層應用解耦離線計算基於 TIDB 的行列混合和 MPP 能力，每天快速匯入 100 GB 的增量資料，以及數十億級資料的聚合和分析。

資料服務：利用TIDB的多維度資料接入能力，提供不同維度、不同條件的高併發T+0資料查詢、分析、推送、資料分發等服務。

資料儲存：Tidb 和 Tikv 用於統一儲存資料、冷熱分離、強化效能和 SLA、優化成本。

整個資料服務層被簡化，拆解“資料煙囪”，提供一堆整合服務，支援各種資料應用。

就這麼簡單嗎？不行，只能說TIDB的補坑能力太強了，從一開始就擊中了這種極端場景的兩個關鍵點。

關鍵點1：HTAP，混合事務分析處理

因為銀行裡的資料不僅是舊記錄，還有每天攝取的大量新交易資料。

需要攝取大量新資料，同時還要進行實時分析和處理，以做出即時和正確的決策。傳統的資料倉儲做不到，傳統的資料庫也無法處理。

例如大型銀行需要在處理高併發交易時檢測異常欺詐交易。

在這樣的場景下，就要依靠HTAP，即一站式架構，支援實時交易和實時分析，這樣才能有魚掌和熊掌。

TIDB是HTAP架構資料庫領域的標桿產品，因此處理此類場景更加方便。

關鍵點二：原生分布式資料庫

這家大銀行目前 500 TB 的資料已經被誇大了，但未來會越來越多，日復一日，年復一年。

如果按照傳統集中式資料庫的思路，就算現在能承受，以後也要躺平。

因此，考慮分布式架構資料庫非常重要

但是，也有分銷的技術路線。

一些“分布式資料庫”需要依賴庫表分片中介軟體或資料訪問**，這限制了事務處理和高可用性。

此外，基於演算法提供分庫分表操作，無法自動擴容，需要人工干預。 更糟糕的是，上層應用仍然需要經歷大量的改造。

TIDB 是一款真正的原生分布式資料庫，具有儲存和計算分離、自動資料分片、自動彈性伸縮、零侵入上層應用等特點。

上下游涉及的業務系統有幾十個，如果要改造應用，工作量會太大。

HTAP+ 是原生分布式的新架構中的四層中的每一層都由這兩個特技來調平。

正是憑藉這兩個絕技，TIDB成功實現了“一換三”，徹底活化了資料！

過去，我經常在江湖上看到一些“換人”的案例，說到“酸”的經歷，大黨員們只能笑著一言不發。

但tidb這個“一選三”的替代品，沒有酸，只有涼，效果簡直是爆炸性的

一、對接業務規模

TIDB支撐的單棧一體化資料服務平台，已對接近100個上下游業務系統，覆蓋全行近230個業務產品、3000多個交易場景。

二、系統資源規模

系統集群擁有約2700+應用虛擬節點（承載上下游業務應用）和300+資料庫物理節點（承載資料）。

集群大小可以根據需要進行擴充套件。

3. 資料容量規模

將原有的 500 TB 單副本資料全部遷移到新系統，新系統採用多副本設計，可靠性更高，總資料規模達到 PB。

其中，最大的資料表記錄了超過1000億行。

4、查詢分析經驗

新系統可支援10年以上的永久查詢和單跨5年的大規模查詢和實時分析，交易資料的完整性、準確性、資料統計更加統一，資料更具爆發力，見下文。

日均收處理億條增量資料，線上寫入TPS約10000條，日均通知推送約3條5億筆交易，核心處理環節耗時控制在5秒以內

日均線上查詢事務數超過1000萬，峰值QPS超過50000，應用側平均響應時間在100ms以內

平均每天載入上千條批量文字，最大線下分析規模為基於40億行原始細節的指標結果資料約4億行，為包括反洗錢、主管部門等監管場景在內的多個下游系統提供資料上傳和推送服務。

吞吐量、彈性伸縮、部署密度、資源利用率大幅提公升，實現靈活高效的資源配置，精細化降本增效。

當然，還有乙個不容忽視

通過採用TIDB解決方案，該行成功完成了這套核心系統的國產化

在這一點上，我們終於可以說：

這個資料庫應用的“珠穆朗瑪峰”，TIDB成功登頂了！

但是，你知道嗎？Tidb是乙個超級登山者。

人們不僅攀登“珠穆朗瑪峰”，多年來，國內外各種“危險山峰”，TIDB都曾攀登過。

我們以資料庫要求最苛刻的“國內金融山”為例

國內各大銀行、保險公司、券商隨處可見TIDB的足跡。

例如，今年4月，Pingcap中標中國建設銀行國內資料庫計算機向下移動。

多年來，TIDB已成功應用於：中國建設銀行、上海浦東發展銀行、北京銀行、浙商銀行、杭州銀行、廣發銀行、中國人壽財產保險、平安科技、微眾銀行等多家金融企業的核心業務場景。

平安集團旗下平安科技基於TIDB構建了平安自有的資訊創新分發資料庫UBISQL，賦能生態圈內的企業。

接下來，我們來看看國外那些“頂山”

從 Databricks 到 Pinterest，從 Bolt 到 Shopee，從 Capcom 到 Line......TIDB經受住了來自全球3000多家行業客戶的海量資料的考驗。

正是這些實戰攀登經驗，讓TIDB現在能夠面對國內金融業的極限挑戰，舉重，最終成功登頂！

放眼行業，TIDB可能是唯一一家同時服務於各大國有銀行和全球頂級網際網絡廠商的資料庫產品，而TIDB堅持了8年多的獨立開源路線，也是其產品值得信賴的法寶，保持持續領先地位。

TIDB 和 Pingcap 的攀公升仍在繼續......

在它的背後，是一連串閃閃發光的腳印：Tidb 專案在 GitHub 上有超過 35,000 顆星星;TIDB 被 3,000 多家公司用於生產服務於20多個國家的客戶。

TIDB“登山”的路上，有許多標誌性事件。

例如，我剛剛看到了 TIDB 提公升杭州銀行國家核心系統上線的訊息傳出，這或許是國內第一家城商行核心系統採用國家微服務+原生分布式架構的案例，無疑是乙個里程碑。

沒有比腳更長的路，沒有比人更高的山......