我們怎樣把保險(xiǎn)公司團(tuán)保明細(xì)單查詢提速?2000 ?倍

時(shí)間：2021-12-08 17:13:17

關(guān)鍵字：數(shù)據(jù)庫 SQL 代碼性能優(yōu)化

手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]問題描述C保險(xiǎn)公司業(yè)務(wù)系統(tǒng)中，團(tuán)體保險(xiǎn)明細(xì)查詢速度很慢。查詢時(shí)輸入保單號(hào)，要返回團(tuán)體保單包含的所有被保險(xiǎn)人的信息。較小的保單，包含1萬個(gè)被保險(xiǎn)人，返回頁面需要等待7.5分鐘。較大的保單，包含100萬被保險(xiǎn)人，返回頁面等待了4個(gè)小時(shí)沒有出來。團(tuán)體保險(xiǎn)明細(xì)比較大，分兩個(gè)數(shù)據(jù)庫保存。每...

問題描述

C保險(xiǎn)公司業(yè)務(wù)系統(tǒng)中，團(tuán)體保險(xiǎn)明細(xì)查詢速度很慢。查詢時(shí)輸入保單號(hào)，要返回團(tuán)體保單包含的所有被保險(xiǎn)人的信息。較小的保單，包含1萬個(gè)被保險(xiǎn)人，返回頁面需要等待7.5分鐘。較大的保單，包含100萬被保險(xiǎn)人，返回頁面等待了4個(gè)小時(shí)沒有出來。團(tuán)體保險(xiǎn)明細(xì)比較大，分兩個(gè)數(shù)據(jù)庫保存。每個(gè)團(tuán)體保單的數(shù)據(jù)，在兩個(gè)庫中都有可能出現(xiàn)。數(shù)據(jù)庫是Oracle，SQL語句共163行，如下圖：分析解決

面對性能問題，需要仔細(xì)分析數(shù)據(jù)和計(jì)算的特征，定位性能關(guān)鍵點(diǎn)，通過改變數(shù)據(jù)的存儲(chǔ)方式和計(jì)算方法逐步優(yōu)化。第一步，確認(rèn)需求前提。團(tuán)體保險(xiǎn)明細(xì)查詢是應(yīng)用系統(tǒng)中的一個(gè)功能，需要查詢最新數(shù)據(jù)。如果采用ETL定時(shí)將數(shù)據(jù)導(dǎo)出計(jì)算的方式，不能滿足這個(gè)要求。因此，還是要想辦法從數(shù)據(jù)庫取數(shù)、庫外計(jì)算，來優(yōu)化性能。第二步，了解業(yè)務(wù)需求特征。團(tuán)體保險(xiǎn)明細(xì)數(shù)據(jù)存放在兩個(gè)數(shù)據(jù)庫db1、db2，每個(gè)數(shù)據(jù)庫都有兩個(gè)表m1、m2。這四個(gè)表在查詢時(shí)要合并查詢結(jié)果，我們統(tǒng)一稱為團(tuán)體保險(xiǎn)明細(xì)表。四個(gè)團(tuán)體保險(xiǎn)明細(xì)表有所不同，但是都可以查詢出主要字段：保單號(hào)、保險(xiǎn)成員號(hào)、批改次數(shù)、業(yè)務(wù)編號(hào)1、業(yè)務(wù)編號(hào)2、業(yè)務(wù)標(biāo)志，還有姓名、性別年齡等個(gè)人信息“批改”是針對保險(xiǎn)合同的調(diào)整，系統(tǒng)將調(diào)整后的最新保險(xiǎn)明細(xì)也保存在團(tuán)體保險(xiǎn)明細(xì)表中，不會(huì)修改原保險(xiǎn)明細(xì)，保留軌跡。在數(shù)據(jù)中通過“批改次數(shù)”字段體現(xiàn)。查詢時(shí)，要查詢批改次數(shù)最大的一次，也就是最新的數(shù)據(jù)。明細(xì)數(shù)據(jù)中還有一部分是無效數(shù)據(jù)。要看業(yè)務(wù)編號(hào)1和業(yè)務(wù)標(biāo)志連接成的字符串是否在無效集合中。無效集合是指：同一個(gè)保單號(hào)的數(shù)據(jù)中，批改次數(shù)小于9，并且業(yè)務(wù)標(biāo)志為D或者U時(shí)，業(yè)務(wù)編號(hào)2和字母A連接成的字符串形成的集合。如果業(yè)務(wù)編號(hào)1和業(yè)務(wù)標(biāo)志連接成的字符串出現(xiàn)在無效集合中，這條記錄就是無效的記錄，要舍棄掉。第三步，梳理研究計(jì)算過程。SQL雖然比較長，但是可以分成幾個(gè)部分。第一部分是兩個(gè)數(shù)據(jù)庫的4個(gè)團(tuán)體保險(xiǎn)明細(xì)表，各自按照保單號(hào)查詢需要的數(shù)據(jù)，再用union合并在一起。第二部分是條件過濾，包括去掉無效數(shù)據(jù)和另外幾個(gè)簡單的條件。第三部分是用窗口函數(shù)row_number() OVER(PARTITION BY 保險(xiǎn)成員號(hào) ORDER BY 批改次數(shù) desc)，查找批改次數(shù)最大的明細(xì)記錄。第一部分單獨(dú)執(zhí)行時(shí)，返回的結(jié)果數(shù)據(jù)量是幾萬到幾百萬，全部返回的時(shí)間比較長。如果用數(shù)據(jù)庫JDBC游標(biāo)的話，很快就能返回部分?jǐn)?shù)據(jù)，比如幾秒就可以返回幾千條。第二部分，單獨(dú)從數(shù)據(jù)庫中取得無效集合只需要幾秒，而且返回結(jié)果數(shù)據(jù)量不大，可以全內(nèi)存。但是，第一部分和第二部分合并執(zhí)行的時(shí)候，速度就變得很慢，即使是游標(biāo)方式分批返回，也還是很慢。如果再加上第三部分，就更慢了。第四步，設(shè)計(jì)呈現(xiàn)方案。根據(jù)SQL分段執(zhí)行的情況，確定采用流式大報(bào)表的方式實(shí)現(xiàn)提速，原理如下圖：從數(shù)據(jù)庫取數(shù)和呈現(xiàn)采用兩個(gè)異步線程，取數(shù)線程發(fā)出 SQL 后不斷取出數(shù)據(jù)經(jīng)過復(fù)雜計(jì)算后，緩存到本地。再由呈現(xiàn)線程從本地緩存中獲取數(shù)據(jù)進(jìn)行顯示。這樣，已經(jīng)取出并緩存的數(shù)據(jù)就能快速呈現(xiàn)，不再有等待感。第五步，設(shè)計(jì)計(jì)算過程優(yōu)化方案。我們考慮將取數(shù)和計(jì)算分三段實(shí)現(xiàn)。第一段，上面說的第一部分SQL加上按照保險(xiǎn)成員號(hào)和批改次數(shù)降序排序之后，用數(shù)據(jù)庫JDBC游標(biāo)依然能夠快速分批取出部分?jǐn)?shù)據(jù)。加上排序，可以在分批取出數(shù)據(jù)時(shí)，保證一個(gè)保險(xiǎn)成員的數(shù)據(jù)相鄰取出，在后續(xù)第三段中，就能夠快速找到批改次數(shù)最大的最新數(shù)據(jù)。第二段，我們將這個(gè)保單的無效集合一次性取出到內(nèi)存中，對第一段分批取出的數(shù)據(jù)進(jìn)行過濾，計(jì)算出符合條件的有效明細(xì)。無效數(shù)據(jù)并不多，不會(huì)過濾掉太多的明細(xì)數(shù)據(jù)。第三段，根據(jù)被保險(xiǎn)人號(hào)是否改變，判斷是不是一個(gè)被保險(xiǎn)人的第一條數(shù)據(jù)。因?yàn)槊骷?xì)數(shù)據(jù)按照被保險(xiǎn)人和批改次數(shù)有序，所以當(dāng)被保險(xiǎn)人號(hào)改變的時(shí)候，第一條數(shù)據(jù)就是當(dāng)前被保險(xiǎn)人批改次數(shù)的最大值。這樣就起到了，和上面說到的窗口函數(shù)一樣的作用。由于每個(gè)保險(xiǎn)成員的數(shù)據(jù)量都不大，一般是最多十幾條數(shù)據(jù)（對應(yīng)幾次到十幾次批改），而且無效數(shù)據(jù)并不多。所以第一部分分批取出的數(shù)據(jù)量不需要很多，就可以向前端批量返回?cái)?shù)據(jù)了。這是流式大報(bào)表能夠快速展現(xiàn)的必要條件。第六步，設(shè)計(jì)代碼實(shí)現(xiàn)方案。使用延遲游標(biāo)的方法實(shí)現(xiàn)上述三個(gè)分段。延遲游標(biāo)的原理是，先依次定義三個(gè)分段的游標(biāo)計(jì)算，定義的時(shí)候并不真的執(zhí)行計(jì)算，而是在三個(gè)分段都定義好之后再執(zhí)行。延遲計(jì)算的好處是可以一次遍歷完成三個(gè)分段計(jì)算，不必生成中間結(jié)果占用空間，可以把查詢結(jié)果分批提交給前端去展現(xiàn)。第三段游標(biāo)計(jì)算比較復(fù)雜，需要用程序游標(biāo)來實(shí)現(xiàn)。原理如下圖：程序游標(biāo)要做到被調(diào)用的時(shí)候，邊計(jì)算邊返回結(jié)果，這樣才能達(dá)到流式大報(bào)表的要求。實(shí)際效果

根據(jù)計(jì)算特征擬定了優(yōu)化方案后，需要選擇合適的工具來實(shí)現(xiàn)計(jì)算和展現(xiàn)的性能優(yōu)化。直接使用Java當(dāng)然可以實(shí)現(xiàn)，但編碼量過大，實(shí)現(xiàn)周期過長，容易出現(xiàn)代碼錯(cuò)誤隱患，也很難調(diào)試和維護(hù)。而開源的集算器SPL語言提供上述所有的算法支持，包括延遲游標(biāo)、游標(biāo)有序分段取出、程序游標(biāo)等機(jī)制，能夠讓我們用較少的代碼量快速實(shí)現(xiàn)這種個(gè)性化的計(jì)算。前端呈現(xiàn)需要支持流式大報(bào)表機(jī)制的報(bào)表工具，我們選擇了潤乾報(bào)表來實(shí)現(xiàn)。僅僅經(jīng)過1天時(shí)間的編程、調(diào)試和測試，就完成了性能優(yōu)化的驗(yàn)證，而且查詢的響應(yīng)速度非?？臁］^小的保單，包含1萬個(gè)被保險(xiǎn)人，原來返回頁面需要等待7.5分鐘，優(yōu)化后的報(bào)表首頁只需要3秒即可展現(xiàn)出來。較大的保單，包含100萬被保險(xiǎn)人，原來返回頁面等待了4個(gè)小時(shí)沒有出來，優(yōu)化后的報(bào)表首頁僅7秒即可展現(xiàn)出來，響應(yīng)速度提高了2000倍還多。在編程難度方面，SPL做了大量封裝，提供了豐富的函數(shù)，內(nèi)置了上述優(yōu)化方案需要的基本算法和存儲(chǔ)機(jī)制。實(shí)際編寫的代碼很短，開發(fā)效率很高。上述取數(shù)的三段代碼只有這么幾行：后記

解決性能優(yōu)化難題，最重要的是設(shè)計(jì)出高性能的計(jì)算方案，有效降低計(jì)算復(fù)雜度，最終把速度提上去。因此，一方面要充分理解計(jì)算和數(shù)據(jù)的特征，另一方面也要熟知常見的高性能算法，才能因地制宜地設(shè)計(jì)出合理的優(yōu)化方案。本次工作中用到的基本高性能算法，都可以從下面這門課程中找到：點(diǎn)擊這里學(xué)習(xí)性能優(yōu)化課程（底部原文中可點(diǎn)擊鏈接），有興趣的同學(xué)可以參考。很遺憾的是，當(dāng)前業(yè)界主流大數(shù)據(jù)體系仍以關(guān)系數(shù)據(jù)庫為基礎(chǔ)，無論是傳統(tǒng)的MPP還是HADOOP體系以及新的一些技術(shù)，都在努力將編程接口向SQL靠攏。兼容SQL確實(shí)能讓用戶更容易上手，但受制于理論限制的SQL卻無法實(shí)現(xiàn)大多數(shù)高性能算法，眼睜睜地看著硬件資源被浪費(fèi)，還沒有辦法改進(jìn)。SQL不應(yīng)是大數(shù)據(jù)計(jì)算的未來。有了優(yōu)化方案后，還要用好的程序語言來高效地實(shí)現(xiàn)這個(gè)算法。雖然常見的高級(jí)語言能夠?qū)崿F(xiàn)大多數(shù)優(yōu)化算法，但代碼過于冗長，開發(fā)效率過低，會(huì)嚴(yán)重影響程序的可維護(hù)性。開源SPL是個(gè)很好的選擇，它有足夠的算法底層支持，代碼能做到很簡潔，還提供了友好的可視化調(diào)試機(jī)制，能有效提高開發(fā)效率，以及降低維護(hù)成本。
對于本例中的報(bào)表呈現(xiàn)，還需要有能支持流式呈現(xiàn)的報(bào)表工具，這方面潤乾報(bào)表有獨(dú)特的優(yōu)勢，不需要全部取出數(shù)據(jù)就可以開始呈現(xiàn)，也不依賴于數(shù)據(jù)庫分頁機(jī)制（這種方法可能造成數(shù)據(jù)不一致）就可以支持高速前后翻頁。這樣才能獲得業(yè)務(wù)用戶的良好體驗(yàn)。正在為 SQL 性能優(yōu)化頭疼的同學(xué)們，可以和我們一起探討：《慢得受不了的查詢跑批》