[NewLife.XCode]百億級性能

NewLife.XCode是一個有10多年曆史的開源數據中間件,支持nfx/netcore,由新生命團隊(2002~2019)開發完成並維護至今,以下簡稱XCode。

整個系列教程會大量結合示例代碼和運行日誌來進行深入分析,蘊含多年開發經驗於其中,代表作有百億級大數據實時計算項目。

開源地址:https://github.com/NewLifeX/X (求star, 795+)

 

大數據投名狀

先來看看“大數據演示平臺”:http://bigdata.newlifex.com

SQLite單表4億行訂單數據,文件大小26.5G,阿里雲1C1G的ECS服務器,由 NewLife.XCode + NewLife.Cube 驅動

如上,在4億行中查詢第1000頁,耗時16毫秒。

對於高手來說,這個算不得什麼,只要注意好索引就行。

 

這個“演示平臺”建立於兩年前,給兩家領先物流企業遞交了簡歷,其中一家因SQLite拒絕了,另一家給了數據架構師!

 

現在,每天1億個快遞包裹在路上,產生大量掃描數據。單表數十億數據很常見(Oracle按月分區),一款數據產品幾億明細數據比比皆是(MySql分表)。

 

代碼之巔、天外飛仙

再來看一下各種數據庫的極致性能,飛仙平臺 http://feixian.newlifex.com

SQLite插入第一名 56萬tps;

MySql插入第一名 60萬tps;

SQLite查詢(帶緩存)1126萬qps;

這是上百人用了各種機器(筆記本、臺式機、服務器)調整參數進行大量測試後得到的性能排行榜!

所有測試,由 NewLife.XCode 支持!

 

實際應用中,即使能達到上述性能十分之一,亦能立於不敗之地。有時候甚至還達不到百分之一。

儘管如此,極致性能的研究也給我們的應用方式以及數據庫參數設置指明瞭方向!

 

索引完備

使用關係型數據庫來做大數據,第一步必然是索引

單表超過1000萬數據,任何查詢都必須走索引!否則數據庫一定跟你說ByeBye!

 

前面SQLite單表4億數據,共有兩個索引,自增ID作爲主鍵,另外有訂單號索引。 

大表索引不宜過多,務必以數據的主要使用方式來建立一兩個即可,儘量不要超過三個,經索引過濾後的數據儘量控制住1萬行以內。

 

常見大型表索引用法:

1,日誌型

訂單操作表、快遞掃描表、傳感數據表等超大日誌型數據表,每日數千萬到數億行,只插入不修改,最重要的字段就是時間戳CreateTime,建立索引,同時可以按時間分區分表。

這種大表最常見用法就是根據時間戳去抽取來做業務處理,那就是鼎鼎大名的ETL。處理性能1000~10000tps

更高大上一點,就是抽取數據寫入Kafka/RocketMQ,名正言順進行大數據分析!處理性能10萬tps

因工作需要,我們依據時間戳抽取了30天共100億數據寫入Redis,供100+應用進行實時數據分析。處理性能100萬tps

抽取數據時以每批次抽取5000~20000行爲宜,依次調整查詢時間段,重量級螞蟻調度系統(https://github.com/NewLifeX/AntJob)具備動態步進抽取能力,可自動調節最優抽取間隔。

總結起來一句話:按時間戳輪數據!

2,狀態表

訂單運單都是有狀態數據,在整個生命週期中,狀態會多次改變。許多業務往往要求兩個或多個狀態相匹配,那就要求有一張龐大的狀態表。

狀態表最合適的主鍵就是訂單號,並且一般分表分庫存儲,常見分表公式 Crc16(code)%1024,分表數以單表不超過1000萬爲宜。

使用1024狀態表的數據庫一般是分佈式玩法,比較合適分8庫,每個庫128表,很多應用服務器各司其職,大家共同操作一張表的機率大減。

3,統計分析表

統計表主鍵一般由統計日期和分類構成,爲了方便可建立字符串ID主鍵,由 {date}_{cid} 組成,也可以對 date + cid 兩個字段建立唯一聯合索引。

之所以建立 {date}_{cid} 的ID主鍵,主要是爲了方便寫明細數據,無需等待統計表插入後(假如使用自增)纔得到統計ID。

明細表一定必須根據統計ID來查,由統計ID跟其它主要業務字段構成主索引。

 

合理查詢

既然有了索引,那麼大表的任意查詢都必須命中索引(或者部分使用索引) 。

爲了索引,爲了降低數據庫負擔,有時候寧可多查一點,先把數據查出來,再在內存裏面做二次處理!

大數據的瓶頸一定是數據庫,應用服務器往往性能過剩!

因此,完全可以把一部分“計算”由數據庫轉移到應用服務器之中來進行處理。

 

大表少用join關聯,寧可多次查詢;

 

字段精煉

常聽到許多人說每天處理數據多少多少TB/PB,聽起來數據分析還可以論斤稱?挺尷尬的!

雖然數據庫很容易遇到IO瓶頸,但很多人達不到那一步。

數據容量上的優化空間還是極大的。

大表字段精簡原則:

  1.  能存ID就別存Name。經常見到用戶、商家、地區等信息,又存ID又存Name,甚至還存一個Code。此時需要XCode的擴展屬性
  2. 適當冗餘。爲了便於查詢,可以適當冗餘一些字段,但絕不能濫用。比如商家所在地區,如果查詢用不到而只是分析時使用,就不需要保存商家ID以外還保存地區
  3. 只查詢需要的字段。這一點跟XCode推崇 select * 並不相悖,絕大部分百萬級以內小表可以這麼幹,但是千萬億萬級大表則需按需查詢了。

 

充分利用緩存

 少用join關聯,慎用字段冗餘,即可大量發揮XCode的緩存優勢。

10萬乃至100萬維表數據可儘量緩存起來,隨時配合億萬級大表進行數據分析。

 

另一方面就是數據庫緩存,需要DBA大力支持!

 

系列教程

NewLife.XCode教程系列[2019版]

  1. 增刪改查入門。快速展現用法,代碼配置連接字符串
  2. 數據模型文件。建立表格字段和索引,名字以及數據類型規範,推薦字段(時間,用戶,IP)
  3. 實體類詳解。數據類業務類,泛型基類,接口
  4. 功能設置。連接字符串,調試開關,SQL日誌,慢日誌,參數化,執行超時。代碼與配置文件設置,連接字符串局部設置
  5. 反向工程。自動建立數據庫數據表
  6. 數據初始化。InitData寫入初始化數據
  7. 高級增刪改。重載攔截,自增字段,Valid驗證,實體模型(時間,用戶,IP)
  8. 髒數據。如何產生,怎麼利用
  9. 增量累加。高併發統計
  10. 事務處理。單表和多表,不同連接,多種寫法
  11. 擴展屬性。多表關聯,Map映射
  12. 高級查詢。複雜條件,分頁,自定義擴展FieldItem,查總記錄數,查彙總統計
  13. 數據層緩存。Sql緩存,更新機制
  14. 實體緩存。全表整理緩存,更新機制
  15. 對象緩存。字典緩存,適用用戶等數據較多場景。
  16. 百億級性能。字段精煉,索引完備,合理查詢,充分利用緩存
  17. 實體工廠。元數據,通用處理程序
  18. 角色權限。Membership
  19. 導入導出。Xml,Json,二進制,網絡或文件
  20. 分表分庫。常見拆分邏輯
  21. 高級統計。聚合統計,分組統計
  22. 批量寫入。批量插入,批量Upsert,異步保存
  23. 實體隊列。寫入級緩存,提升性能。
  24. 備份同步。備份數據,恢復數據,同步數據
  25. 數據服務。提供RPC接口服務,遠程執行查詢,例如SQLite網絡版
  26. 大數據分析。ETL抽取,調度計算處理,結果持久化

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章