搜狐基金使用 MySQL 遇到瓶頸?來看 TDengine 如何解決難題
該專案需要實時展示國內基金的淨值和收益(貨幣基金),在保證滿足折線圖展示的功能基礎上,還需要加入統計排行、分頁展示等功能,為使用者提供最全面實時的查詢服務。此前搜狐基金團隊使用的 MySQL 資料庫在面對海量資料時存在能力瓶頸,在此背景下,其決定基於 TDengine 嘗試一下全新的方案。
選型背景
在使用 TDengine 之前,我們使用的是 MySQL 資料庫。
由於所購買的資料來源的基金資料都是混在一起的,包含來自國內的2萬隻基金,跨越幾十年(從九幾年至今)的數千萬行較寬的資料,如果透過 MySQL 來儲存這些資料,我們首先要把每個基金的資料分表,有一定程度的工作量,所以我們決定先全量儲存這些資料在一張表中。
但這種大表會導致查詢的效能非常低下,為了應對這一問題,我們透過離線查詢生成每天的基金資料圖片返回給使用者,暫未對外提供自定義查詢服務。
與此同時,經歷了以上種種,我們也在懷疑傳統關係型資料庫面對海量資料的能力瓶頸。這時候,我們瞭解到了 TDengine ,它的核心是一款時序資料庫(Time Series Database),它“一個裝置一張表”的特殊設計,與我們正在做的“一個基金一張表”的分表工作不謀而合。因此我們決定基於 TDengine 嘗試一下全新的方案。
使用經歷
透過充分調研和測試後,我們發現:
由於“超級表”的存在,資料建模變得非常清晰,幾乎所有查詢都可以以“超級表”為核心用簡單的 SQL 完成。
此外,由於“自動建表”這個特色功能,我們可以無需校驗就能夠直接建表,這讓我們得以非常輕鬆地完成各只基金資料的拆分建表以及寫入工作。
可以說,接入 TDengine 的前期準備工作十分順利。
我們使用三臺 4C 16GB 的伺服器組建了 TDengine 的叢集。
資料庫建立語句如下:
值得一提的是,基金資料是一日一條,屬於低頻次資料。對於這種資料,預設的配置是不夠的。一開始我們的查詢效能並不快,基本都是在秒級別甚至還有更高。
透過文件和部落格以及官方團隊的支援,我們放大了 duration 和 stt_trigger 引數,這樣確保了不會產生過多的檔案碎片影響讀寫效能,後續的查詢全部被最佳化至毫秒級別。
因此我們總結出來一點經驗就是:不同的寫入頻率屬於不同的業務場景,最好不要使用同一個庫,而是要分庫處理比較好。
超級表建模如下:
當前在日常使用時,業務查詢在 100 qps 的情況下,均可以實現毫秒級實時返回資料。
從超級表的設計特點出發,我們在超級表維度上做統計分析就方便多了,比如:篩選型別和日期的全量基金查詢——
select time, code, name, manager_id, manager_name, unit_net_value, pre_unit_net_value, accumulate_net_value, pre_day_rate, pre_week_rate, pre_month_rate, pre_three_month_rate, pre_half_year_rate, pre_year_rate, pre_cur_year_rate, pre_start_rate, last_time, last_unit_net_value, last_accumulate_net_value, asset_size from fund_net_value where time = #{date} and (type = '003009' or type = '003010')
又比如,查詢目前基金淨值排行和收益排行,透過簡單的 SQL 即可實現——
select time, code, name, manager_id, manager_name, unit_net_value, pre_unit_net_value, accumulate_net_value, pre_day_rate, pre_week_rate, pre_month_rate, pre_three_month_rate, pre_half_year_rate, pre_year_rate, pre_cur_year_rate, pre_start_rate, last_time, last_unit_net_value, last_accumulate_net_value, asset_size from fund_net_value where time = #{date} and order by ${column} ${sort} limit #{offset}, #{size}
與此同時我們搭建了 Grafana 視覺化監控體系,利用各種監控工具和軟體來收集、儲存和分析監控資料,並透過視覺化介面提供實時的監控圖表和警報,幫助專案相關負責人即時識別修改問題,進一步提高了服務的可靠性和穩定性。
寫在最後
總而言之,在保證穩定高效執行的前提下,我們已經透過 TDengine 逐步平滑替代原有功能。考慮到國內基金專案只是一個開始,圍繞著股票等其他專案,我們仍需要對這款國產時序庫做更多的研究與學習。
企業簡介
搜狐公司是中國著/名的的綜合性網際網路企業,主要業務領域包括新媒體、通訊以及移動增值服務,整合了娛樂中心、體育中心、時尚文化中心等多重角色。
作者介紹
武朋,搜狐智慧平臺高/級開發工程師。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70014783/viewspace-2993512/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 打破Kafka帶來的瓶頸?Kafka
- 使用 sar 和 kSar 來發現 Linux 效能瓶頸Linux
- Android高階工程師普遍進階難題:遇到瓶頸我們該如何去提升自己?哪個方向?Android工程師
- 如何解決SQL Server資料庫的軟硬體效能瓶頸OCSQLServer資料庫
- 如何使用 Wireshark 分析 TCP 吞吐瓶頸TCP
- 解決資料庫高併發訪問瓶頸問題資料庫
- 流量高峰時期的效能瓶頸有哪些、以及如何來解決
- 如何用實時資料追蹤來解決專案瓶頸?
- 效能測試如何定位瓶頸?偶發超時?看高手如何快速排查問題
- 前端瓶頸如何打破???前端
- 如何突破前端瓶頸???前端
- 伺服器IO瓶頸對MySQL效能的影響伺服器MySql
- 壓測平臺 - 使用 LVS 負載均衡解決網路流量成為瓶頸的問題負載
- 5G多卡聚合技術如何解決通訊指揮車應用瓶頸
- 使用chrome開發者工具中的performance皮膚解決效能瓶頸ChromeORM
- 顯示卡瓶頸是什麼,如何識別顯示卡GPU瓶頸並解決以提升PC效能GPU
- 如何解決MES交付困難問題?
- 如何解決企業銷售難題
- 人到中年了的瓶頸
- 做Java開發,遇到瓶頸是保持現狀還是尋求突破?Java
- Android初學路上會遇到的瓶頸【安卓巴士博文大賽】Android安卓
- 擴充套件jwt解決oauth2 效能瓶頸套件JWTOAuth
- 如何解決使用JSON.stringify時遇到的迴圈引用問題JSON
- 小家電發展遭遇瓶頸未來仍大有可為
- 學習前端遇到瓶頸了?這些‘好’習慣都會毀掉你前端
- 如何監控 Log4j2 非同步日誌遇到寫入瓶頸非同步
- printStackTrace()造成的併發瓶頸
- 效能測試瓶頸調優
- 企業在使用點晴OA系統遇到操作問題如何解決?
- 處理高併發 IO瓶頸解決紅包程式
- 效能測試瓶頸之CPU問題分析與調優
- Redis效能瓶頸揭秘:如何最佳化大key問題?Redis
- 使用ABAP併發程式設計解決一個實際應用場景中的效能瓶頸問題程式設計
- NVMe儲存效能瓶頸的主要來源:檔案系統
- UiBot RPA如何解決系統間整合難題?UI
- 企業雲盤如何解決辦公難題
- 還在用分庫分表?看TiDB如何解決海量資料無感擴容難題TiDB
- oracle快速定位資料庫瓶頸Oracle資料庫