作者：某物聯(lián)網(wǎng)公司設(shè)施云平臺(tái)負(fù)責(zé)人
用戶簡(jiǎn)介：我們是一家提供全鏈智慧園區(qū)整體解決方案的物聯(lián)網(wǎng)公司，致力于打造可持續(xù)發(fā)展的智慧園區(qū)。
基礎(chǔ)設(shè)施平臺(tái)簡(jiǎn)介
基礎(chǔ)設(shè)施平臺(tái)是集團(tuán)一線作業(yè)人員日常工作中高度依賴的重要系統(tǒng)，涵蓋了各類基礎(chǔ)設(shè)施的管理、報(bào)修、保養(yǎng)等一系列數(shù)字化辦公功能，同時(shí)實(shí)現(xiàn)了對(duì)基礎(chǔ)設(shè)施、作業(yè)人員、項(xiàng)目成本等多種維度的精細(xì)化管理。其使命在于不斷提升一線作業(yè)效率，提高業(yè)主的服務(wù)滿意度。
以下為該平臺(tái)手機(jī)端應(yīng)用截圖。工作中心頁面提供了大量常用的業(yè)務(wù)功能，同時(shí)還包含了面對(duì)一線、項(xiàng)目、集團(tuán)等多個(gè)維度的報(bào)表功能，是一個(gè)典型的 HTAP 混合負(fù)載場(chǎng)景。
面臨的挑戰(zhàn)
隨著數(shù)據(jù)規(guī)模達(dá)到億級(jí)別、業(yè)務(wù)規(guī)模不斷擴(kuò)大以及數(shù)字化需求的增加，該平臺(tái)面臨的挑戰(zhàn)變得愈發(fā)嚴(yán)峻。在日常的業(yè)務(wù)高峰期，特別是在一些關(guān)鍵業(yè)務(wù)期間，如每周初、月初和月末，一線作業(yè)人員和集團(tuán)運(yùn)營(yíng)業(yè)務(wù)部門的工作都可能受到一些影響。這主要是由于底層數(shù)據(jù)庫在資源、架構(gòu)和性能方面存在一些不足。
應(yīng)用架構(gòu)
原先采用 MySQL 數(shù)據(jù)庫的主從架構(gòu)來為平臺(tái)提供服務(wù)(16VC/64GB)，其中包括：
- 主庫存儲(chǔ)業(yè)務(wù)數(shù)據(jù)（450GB），用于支撐應(yīng)用中的絕大部分的業(yè)務(wù)功能，峰值 QPS 2500+；
- 從庫除了業(yè)務(wù)數(shù)據(jù)外，還有 ETL 轉(zhuǎn)化之后的匯總數(shù)據(jù)（200GB），峰值 QPS 1000+，支撐：
- 應(yīng)用中的 BI 報(bào)表功能，集團(tuán)的大屏實(shí)時(shí)展示；
- ETL 數(shù)據(jù)計(jì)算，在業(yè)務(wù)數(shù)據(jù)基礎(chǔ)上進(jìn)行加工，并寫入到匯總庫中；
- 當(dāng)主庫不可用時(shí)，支撐應(yīng)用的高可用。
MySQL?不堪重負(fù)
- 在業(yè)務(wù)高峰期，主庫的 CPU 使用率達(dá)到 90%，應(yīng)用響應(yīng)非常慢；
- 在業(yè)務(wù)高峰期，從庫的 CPU 使用率也達(dá)到 90%，個(gè)別 BI 報(bào)表無法打開；
- 凌晨在從庫上運(yùn)行的 ETL 作業(yè)耗時(shí)非常久，有時(shí)到需要運(yùn)行到第二天工作時(shí)間，嚴(yán)重影響 BI 報(bào)表服務(wù)。
為何引入 TiDB
在引入 TiDB 前，我們研討了基于 MySQL 當(dāng)前架構(gòu)的擴(kuò)容方案，將實(shí)例規(guī)格從 16VC/64G 擴(kuò)展到 32VC/128G，甚至再加一個(gè)從節(jié)點(diǎn)，然后在應(yīng)用層進(jìn)行讀寫分離設(shè)計(jì)。
該擴(kuò)容方案可以解決在并發(fā)時(shí)資源不足的問題，從而在一定程度上緩解高峰期服務(wù)響應(yīng)慢的情況。然而，它并不能解決 SQL 本身執(zhí)行速度較慢的問題。例如，在從庫執(zhí)行凌晨的 ETL 作業(yè)期間，雖然負(fù)載并不高，但是 ETL 運(yùn)行時(shí)間很長(zhǎng)。方案上還是存在一定的不足：
- 核心工單表 5 億多行，擴(kuò)容后，該表的查詢和寫入 SQL 性能仍然沒有提升；
- BI 報(bào)表查詢以及 ETL 轉(zhuǎn)化作業(yè)時(shí)，涉及大量復(fù)雜的 Join/聚合計(jì)算，涵蓋了多張大表，即使擴(kuò)容了也還是慢；
- 花費(fèi)成本高，同時(shí)改善空間有限：
- 3 倍的資源成本，從 32VC/128GB 變成 96VC/384GB；
- 改造成本，需要對(duì)應(yīng)用代碼進(jìn)行讀寫分離的改造，隨著未來該系統(tǒng)接入更多項(xiàng)目時(shí)，可能還需要投入更多精力進(jìn)行分庫分表的改造工作。
最終我們計(jì)劃選擇原生分布式數(shù)據(jù)庫來解決該系統(tǒng)面臨的問題，其中 TiDB 分布式數(shù)據(jù)庫這些能力非常吸引我們：
- 原生分布式架構(gòu)，能夠徹底解決大數(shù)據(jù)量下讀寫性能問題；
- HTAP 混合負(fù)載，BI 或者 ETL 中包含大量復(fù)雜”Join/聚合“的 SQL，性能可以大幅提升；
- MySQL 兼容，使得應(yīng)用架構(gòu)和代碼幾乎不用調(diào)整便能完成應(yīng)用的移植。
以下為?TiDB?的集群**配置（合計(jì)約 76VC）**
| 計(jì)算規(guī)格 | 數(shù)量 | 配置 | 備注 |
|---|---|---|---|
| ir3.2xlarge.4 | 3 | 8VC/32GB/本地 SSD 盤 | TiKV |
| ir3.4xlarge.4 | 1 | 16VC/64GB/本地 SSD 盤 | TiFlash |
| c7.2xlarge.4 | 3 | 8VC/32GB/200GB（通用 SSD） | TiDB |
| c7.xlarge.2 | 3 | 4VC/8GB/200GB（超高 IO） | PD |
| elbv3.basic.1az | 1 | 網(wǎng)絡(luò)型(TCP/UDP) | 小型 II | 負(fù)載均衡 |
OLTP 與 OLAP 負(fù)載徹底隔離的 HTAP 架構(gòu)設(shè)計(jì)
應(yīng)用架構(gòu)無需改動(dòng)
為了實(shí)現(xiàn)最小成本的系統(tǒng)移植，我們?cè)谝惶?TiDB 中同時(shí)支撐 OLTP（應(yīng)用基礎(chǔ)功能）、OLAP（BI 報(bào)表、ETL 作業(yè)）兩種負(fù)載，同時(shí)確保兩種負(fù)載之間互不影響，并且提供了最大的可用性保障。以下是我們針對(duì) TiDB HTAP 架構(gòu)進(jìn)行的一些設(shè)計(jì)。
存儲(chǔ)節(jié)點(diǎn)規(guī)劃
我們將 TiKV1 和 TiKV2 規(guī)劃為 OLTP 區(qū)，將 TiKV3 和 TiFlash 規(guī)劃為 OLAP 區(qū)
數(shù)據(jù) Leader 隔離
默認(rèn)情況下 TiDB 中數(shù)據(jù) Leader 的分布是隨機(jī)的，而 SQL 請(qǐng)求默認(rèn)都是發(fā)往 Leader 執(zhí)行，所以默認(rèn)機(jī)制下無法滿足我們的隔離要求。所以我們進(jìn)行了如下設(shè)計(jì)：
- 將OLTP所用到的業(yè)務(wù)數(shù)據(jù)的 leader 固定在 TiKV1/TiKV2 上
策略一： policy_eyas（業(yè)務(wù)庫策略）
預(yù)期效果：數(shù)據(jù)的 Leader 在 zone1 和 zone2 上，zone3 上不會(huì)產(chǎn)生 Leader（只有 Follower）
-- 創(chuàng)建策略
create placement policy policy_eyas leader_constraints = "[-zone=zone3]";
-- 為業(yè)務(wù)庫指定策略,讓業(yè)務(wù)讀寫都發(fā)生在 TiKV 節(jié)點(diǎn) 1,2
alter database eyas placement policy policy_eyas;- 將 OLAP 中 ETL 作業(yè)產(chǎn)生的匯總數(shù)據(jù)的 leader 固定在 TiKV3 上
策略二：policy_bi（匯總庫策略）
預(yù)期效果：數(shù)據(jù)的 Leader 只在 zone3 上，zone1 和 zone2 上只有 Follower （沒有 Leader）
-- 創(chuàng)建策略
create placement policy policy_bi leader_constraints="[+zone=zone3]" follower_constraints ='{"+zone=zone1": 1,"+zone=zone2": 1}';
-- 為匯總庫指定策略,讓匯總庫上的讀寫都發(fā)生在 TiKV 節(jié)點(diǎn) 3
alter database bi_eyas placement policy policy_bi;
alter database da_ping placement policy policy_bi;- 為所有數(shù)據(jù)設(shè)置一份TiFlash副本
alter database eyas set tiflash replica 1;
alter database bi_eyas set tiflash replica 1;
alter database da_ping set tiflash replica 1;目的：加速 BI 報(bào)表和 ETL 中復(fù)雜查詢 SQL 的性能
計(jì)算隔離
我們同樣也針對(duì)計(jì)算節(jié)點(diǎn)進(jìn)行了隔離，TiDB1 和 TiDB2 兩個(gè)計(jì)算節(jié)點(diǎn)接入負(fù)載均衡供應(yīng)用節(jié)點(diǎn)使用，并且限制其只能訪問 TiKV 上的數(shù)據(jù)（原因：應(yīng)用基礎(chǔ)功能無須使用 TiFlash）。
config:
isolation-read.engines:
- tikv
- tidb對(duì)于 BI 應(yīng)用和 ETL 平臺(tái)，我們則是讓其直連 TiDB3 計(jì)算節(jié)點(diǎn)。由于它們都存在大量復(fù)雜”Join/聚合“的SQL，我們希望這樣的 SQL 可以通過優(yōu)化器自動(dòng)決定去 TiKV 或 TiFlash 引擎執(zhí)行，以獲得最大的性能，參數(shù)如下：
config:
isolation-read.engines:
- tikv
- tiflash
- tidb
labels.zone: zone3注意：在 TiDB 數(shù)據(jù)庫中，默認(rèn)所有的讀請(qǐng)求都是發(fā)往數(shù)據(jù)的 Leader，而在 ETL 作業(yè)中的輸入基本都是查詢業(yè)務(wù)庫（非常復(fù)雜的 Join/聚合）、BI 報(bào)表中也有相當(dāng)一部分會(huì)實(shí)時(shí)查詢業(yè)務(wù)庫（而業(yè)務(wù)庫的數(shù)據(jù) Leader 在 TiKV1/TiKV2 上），這樣的 SQL 一旦出現(xiàn)將發(fā)往 TiKV1/TiKV2 上執(zhí)行，此時(shí)會(huì)影響到應(yīng)用核心功能。
為了避免這一問題，我們?yōu)?TiDB3 設(shè)置了一個(gè) Label: zone3（與 TiKV3 的 Label 一致），此時(shí)便可以實(shí)現(xiàn)就近副本的讀?。═iDB3 上即使有非常復(fù)雜的業(yè)務(wù)庫的查詢，也只會(huì)在 TiKV3 的 Follower 副本上或 TiFlash 上執(zhí)行）：
set global tidb_replica_read = 'closest-replicas’;使用效果：性能大幅提升
應(yīng)用部分（頁面端到端耗時(shí)）
- 應(yīng)用核心功能基本優(yōu)化到 1 秒內(nèi)，大幅提升了一線的使用體驗(yàn)和作業(yè)效率；
- BI 報(bào)表性能大幅提升，之前打不開的報(bào)表均能快速展示，提升運(yùn)營(yíng)管理效率。
| 一級(jí)模塊 | 二級(jí)模塊 | 之前（秒） | 現(xiàn)在（秒） |
|---|---|---|---|
| 首頁 | 6.53 | 0.74 | |
| 服務(wù)臺(tái) | 工單跟蹤 | 1.34 | 0.078 |
| 新建工單 | 2.13 | 0.98 | |
| 保養(yǎng)管理 | 制定保養(yǎng)計(jì)劃 | 0.73 | 0.59 |
| 選擇保養(yǎng)設(shè)備 | 0.78 | 0.87 | |
| 調(diào)整保養(yǎng)計(jì)劃 | 0.71 | 0.57 | |
| 保養(yǎng)任務(wù) | 3.08 | 0.63 | |
| 巡檢管理 | 巡檢計(jì)劃 | 0.57 | 0.98 |
| 巡檢任務(wù) | 1.45 | 0.34 | |
| BI**報(bào)表** | 平臺(tái)使用評(píng)價(jià)得分 | 6.3 | 5.51 |
| 平臺(tái)使用評(píng)價(jià)得分 | 7.78 | 5.8 | |
| 人員執(zhí)行數(shù)據(jù) | 14.28 | 4.71 | |
| 集團(tuán)首頁 | 38.24 | 35.91 | |
| 平臺(tái)公司首頁 | 63 | 24.5 | |
| 項(xiàng)目首頁 | 32.17 | 23.92 | |
| 項(xiàng)目月度運(yùn)行報(bào)告 | 打不開 | 105.52 | |
| 平臺(tái)使用評(píng)價(jià)得分 | 打不開 | 119 | |
| 平臺(tái)公司月度運(yùn)行報(bào)告 | 63 | 60 | |
| 平臺(tái)使用評(píng)價(jià)得分 | 67 | 68.69 | |
| 各評(píng)價(jià)指標(biāo)排名 | 107 | 7.72 | |
| 故障類型分析 | 打不開 | 6.47 | |
| 個(gè)人搶單統(tǒng)計(jì)表 | 5.4 | 4.25 | |
| 巡檢工時(shí)異常統(tǒng)計(jì) | 打不開 | 5.36 |
注：一張報(bào)表包含若干條 SQL，最大的報(bào)表包含 200 多條 SQL（串行執(zhí)行、頁面逐一渲染展示）
ETL 作業(yè)
ETL 作業(yè)性能大幅提升，之前最久的作業(yè)執(zhí)行超過 5 小時(shí)，現(xiàn)在的執(zhí)行時(shí)間僅為 48 分鐘，性能提升了 80% 以上。
| 作業(yè)名稱 | 之前（時(shí):分:秒） | 現(xiàn)在（時(shí):分:秒） | 降低 |
|---|---|---|---|
| sr_insp_pm_hebing | 1:13:19 | 00:19:44 | 54分鐘 |
| 大屏_維保 | 0:17:11 | 00:05:40 | 12分鐘 |
| insp_elevator_supervision | 0:24:54 | 00:03:10 | 21分鐘 |
| insp_order | 3:34:43 | 00:31:26 | 3小時(shí) |
| 項(xiàng)目管理 | 0:48:53 | 00:06:55 | 42分鐘 |
| 實(shí)時(shí)集團(tuán)考核 | 1:00:32 | 00:21:14 | 40分鐘 |
| 實(shí)時(shí)考核階段2 | 0:00:57 | 00:00:09 | 48秒 |
| 實(shí)時(shí)計(jì)劃進(jìn)度分析 | 0:13:41 | 00:00:27 | 12分鐘 |
| table_sr_order | 5:02:39 | 00:48:28 | 4小時(shí)14分鐘 |
| Taodaytask | 0:31:56 | 00:04:08 | 27分鐘 |
| 今日大屏數(shù)據(jù) | 0:47:12 | 00:02:34 | 45分鐘 |
遇到的問題和解決辦法
雖然 TiDB 高度兼容 MySQL，幾乎不需要改造，但在測(cè)試過程中發(fā)現(xiàn)了以下兩處問題。
SQL 不兼容
5 條 SQL 報(bào)錯(cuò)：ON condition doesn't support subqueries yet，原因?yàn)?TiDB 在 join 中不支持 on 判斷使用子查詢，如：
1. select t1.* from sbtest1 t1 join sbtest2 t2 on t1.id=t2.id and t2.id in (select id from sbtest3)
2. select t1.* from sbtest1 t1 join sbtest2 t2 on t1.id=t2.id and exists (select 1 from sbtest3 t3 where t3.id=t1.id)解決辦法：改寫成 join 表的形式
特定寫法下 SQL 性能退化
像查詢列中包含 case when in subquery 這樣的寫法時(shí)，執(zhí)行時(shí)與這個(gè) subquery join 的時(shí)候變成了笛卡爾積，性能退化十倍以上。
解決辦法：上線版本為 TiDB 6.5.0，當(dāng)時(shí)通過將 case when in subquery 改寫成 exists 后解決，目前該問題已經(jīng)在高版本中已經(jīng)修復(fù)。文章來源：http://www.zghlxwxcb.cn/news/detail-826641.html
總結(jié)
TiDB 自今年 3 月上線以來，性能提升非常明顯。目前已經(jīng)平穩(wěn)運(yùn)行了超過半年時(shí)間，這充分增強(qiáng)了我們深度使用 TiDB 的信心。未來，我們計(jì)劃利用 TiDB HTAP 架構(gòu)來支撐更多業(yè)務(wù)場(chǎng)景的需求，持續(xù)創(chuàng)造價(jià)值。文章來源地址http://www.zghlxwxcb.cn/news/detail-826641.html
到了這里，關(guān)于HTAP 還可以這么玩？丨TiDB 在 IoT 智慧園區(qū)的應(yīng)用的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
