性能優化技巧 - 查找

【摘要】
平常生活中，咱們會遇到各類各樣的數據，小到公司通信錄，大到互聯網用戶行爲分析。在進行數據分析處理的過程當中，查詢是必不可少的環節，如何更加高效地進行數據查詢。點擊：性能優化技巧 - 查詢，來乾學院一探究竟！
SPL爲用戶提供了強大的索引機制以及針對不一樣場景中各對象的查詢函數，善加運用，能夠顯著提升查詢性能。

1 鍵值查找

1.1 序表

咱們先創建一個份「通話記錄」的模擬數據，經過這份數據，來比較一下不一樣查詢函數對序表查詢性能的影響。創建模擬數據的代碼以下：

代碼1.1.1

其中部分數據以下：

圖1.1.1

對序表進行查詢，一般咱們會想到使用A.select()函數。咱們來看一下使用該函數的效果：

代碼1.1.2

查詢耗時爲80毫秒。

對序表的鍵值進行查詢時，能夠利用A.find()函數進行查詢。示例代碼以下：

代碼1.1.3

查詢耗時爲1毫秒。

這是由於在集算器的序表中，能夠指定某個或某些字段做爲主鍵，基於主鍵的查找可使用專門的函數。好比代碼1.1.3中A5的find函數，不只能簡化書寫，更能有效地提升計算性能。

當鍵值較多時，咱們使用函數A.find@k ()進行批量鍵值查找。示例代碼以下：

代碼1.1.4

要注意的是，在使用A.find()函數時，需事先創建主鍵，不然會報「缺乏主鍵」的錯誤。

利用主鍵值查找的函數，能夠有效地提高計算性能，是因爲在序表中爲主鍵創建索引表。在代碼1.1.4中，未創建索引時，平均查詢時間在1400毫秒左右；創建索引後，查詢平均耗時不到1毫秒。

序表中的數據量越大，須要查找的次數越多，對效率的提高就越明顯。

當查詢條件對應多個鍵時，示例代碼以下：

代碼1.1.5

switch/join函數一樣須要根據主鍵值在序表中查找記錄，使用時會對維表自動創建索引。若在多線程fork函數以前沒有對相應維表創建索引，就會在每一個線程中都自動爲該維表創建一個索引，執行過程當中會消耗更多內存，這樣有可能會形成內存溢出，如圖1.1.1.2，要注意避免，較好的處理方式能夠參考圖 1.1.3。

圖 1.1.2 fork中的每一個線程都自動創建了索引致使內存溢出

圖 1.1.3 fork執行前，先對維表創建索引

1.2 集文件

對有序的集文件進行查找，可使用f.iselect()函數實現二分查找，該函數也支持批量查找，下面是個基於集文件使用f.iselect()批量查找的例子：

代碼1.2.1

代碼1.2.1，創建集文件voiceBill@z.btx。顯然，Subscriber是有序的。

代碼1.2.2

代碼1.2.2，由於f.iselect()是個二分查找函數，因此須要注意代碼中的A2做爲查詢序列，與集文件的編號同樣，都須要有序。還要注意，這裏的選項@b不是二分法的意思，而是讀取經過f.export()函數導出的集文件。該集文件導出時，注意須要使用選項@z，不然在使用f.iselect ()對集文件進行查詢時會報錯。

假設數據總量爲N，使用二分法進行查找的時間複雜度爲logN（以 2 爲底），當數據量越大，性能提高也就越明顯。

1.3 組表

組表也有相似序表的T.find()和T.find@k()函數，能夠高效地實現鍵值查找。適合於在大維表中找出少許記錄的場景。咱們來看這樣一個例子：

代碼1.3.1

代碼1.3.1，創建組表文件voiceBill.ctx，其中Subscriber是該組表的維。

代碼1.3.2

代碼1.3.2，對組表使用cs.select()函數進行查詢，耗時爲：13855毫秒。

代碼1.3.3

代碼1.3.3，對組表使用T.find()函數進行查詢，耗時爲：77毫秒。

對比可見：對於有維的組表，可使用相似序表的T.find()函數，進行單個或者批量鍵值的查詢，其查詢效率遠高於從篩選後的遊標中取數。

2 索引查找

組表上能夠創建三種索引，每種索引針對的狀況也不一樣，分別爲：

一、  hash索引，適合單值查找，好比枚舉類型；

二、  排序索引，適合區間查找，好比數字、日期、時間類型；

三、  全文索引，用於模糊查詢，好比字符串類型。

下面咱們來創建一個組表，使其數據類型覆蓋以上三種索引，以下：

代碼2.1

代碼2.1創建的組表，前十條記錄以下：

圖2.1

代碼2.2

代碼2.2，根據每列數據類型的特色，創建不一樣類型的索引。創建好的索引和組表文件如圖2.2：

圖2.2

集算器能自動識別條件找到合適的索引，等值和區間均可以，like(「A*」)式的也支持。咱們來看下效果：

等值查找

代碼2.3

代碼2.4

代碼2.3是沒有省略索引名稱的寫法，代碼2.4是省略索引名稱的寫法。二者時間消耗基本相同，都是100毫秒左右。

代碼2.5

代碼2.5使用普通遊標查詢一樣的記錄，查詢耗時則須要40秒左右。

區間查找

代碼2.6

代碼2.6對Subscriber使用排序索引，進行區間查找，查詢耗時是70毫秒左右。

代碼2.7

代碼2.7使用普通遊標查詢一樣條件的記錄，查詢耗時則須要40秒左右。

 模糊查找

代碼2.8

代碼2.8對Company使用全文索引，進行模糊查詢，查詢耗時是1500毫秒左右。

代碼2.9

代碼2.9使用普通遊標查詢一樣條件的記錄，查詢耗時則須要40秒左右。

當數據規模更大時，例如：

代碼2.10

代碼2.10，建造了10億條結構如圖2.3的組表文件employee.ctx。

圖2.3

代碼2.11

代碼2.11中，對大部分列創建了索引。組表與索引的各個文件如圖2.4。

圖2.4

多等值條件項&&時，能夠分別爲每一個字段創建索引。集算器可以快速在多個索引中用歸併算法計算交集。好比：

代碼2.12

代碼2.12，查詢條件均爲等值查詢，A3查出記錄數爲324條，耗時31883毫秒。

但區間條件時不能再用歸併計算交集，集算器將只對其中一個條件使用索引，另外一個條件使用遍歷計算，效果就會差，好比：

代碼2.13

代碼2.13，查詢條件均爲區間條件，A3查出記錄數爲389條，耗時70283毫秒。

3 索引緩存

組表索引提供了兩級緩存機制，能夠用index@2或者index@3預先把索引的索引讀入內存，若是須要重複屢次使用索引查找，則能夠有效提升性能。

選項@二、@3的意思分別是將索引的第2、三級緩存先加載進內存。通過索引緩存的預處理，第一遍查詢時間也能達到查詢數百次後才能達到的極限值。@2相比@3緩存的內容少，效果相對差一點，但內存佔用也更少。使用時須要程序員根據具體場景來權衡@2仍是@3。

代碼3.1

代碼3.1，基於代碼2.10建造的組表文件，不使用索引緩存，查詢耗時爲31883毫秒。

代碼3.2

代碼3.2使用第三級索引緩存，查詢耗時爲5225毫秒。

這裏使用的是列存組表，列存採用了數據分塊並壓縮的算法，對於遍歷運算來說，訪問數據量會變小，也就會具備更好的性能。但對於基於索引隨機取數的場景，因爲要有額外的解壓過程，並且每次取數都會針對整個分塊，運算複雜度會高不少。所以，從原理上分析，這時候的性能應當會比行存要差。將組錶轉爲行存後，查詢耗時僅爲1592毫秒。

索引緩存在並行時能夠複用，以下：

代碼3.3

代碼3.3，並行時，A5的每一個線程中均可以使用A二、A3中創建的第三級索引緩存，最終查詢耗時爲21376毫秒。

4 帶值索引

組表的行存和列存形式都支持索引，列存索引查找比行存性能差，返回結果集較少時差別不明顯，大量返回時會有明顯劣勢，在設計存儲方案時要權衡。

代碼4.1

代碼4.1創建組表文件id_600m.ctx，結構爲(#id,data) ，包含6億條記錄，其中：

A1：包含 26 個英文字母和 10 個阿拉伯數字的字符串。

A二、A3：創建結構爲 (id,data) 的組表文件，使用列式存儲方式。

A4：循環 6000 次，循環體B四、B5，每次生成 10 萬條對應結構的記錄，並追加到組表文件。

執行後，生成組表文件：id_600m.ctx

代碼4.2

代碼4.2爲組表id列創建索引。

執行後，生成組表的索引文件：id_600m.ctx__id_idx。

列存組表生成時 create() 函數加上 @r 選項，便可變爲生成行存組表，其他代碼無異，這裏再也不舉例，當返回數據量較大時：

代碼4.3

代碼4.3中，列存查詢耗時和行存查詢耗時，也就是A5和A9的值分別爲205270和82800毫秒。

組表支持一種帶值索引，即把查找字段也寫入索引，這樣能夠再也不訪問原組表即返回結果。但存儲空間會佔用較多。

基於代碼4.1的列存組表文件id_600m.ctx。

代碼4.4

代碼4.4爲組表id列創建索引，在對組表創建索引時，當 index 函數有數據列名參數，如本例 A2 中的 data，就會在建索引時把數據列 data 複製進索引。當有多個數據列時，能夠寫爲：index(id_idx;id;data1,data2,…)。

由於在索引中作了冗餘，索引文件也天然會較大，本文中測試的列存組表和索引冗餘後的文件大小爲：

當數據複製進索引後，實際上讀取時再也不訪問原數據文件了。

從 6 億條數據總量中取 1 萬條批量隨機鍵值，完整的測試結果對比：

5 批量鍵值

組表索引可以識別出contain式條件，支持批量等值查找。

代碼5.1

代碼5.1創建組表文件id_600m.ctx，結構爲(#id,data) ，包含6億條記錄，其中：

A1：包含 26 個英文字母和 10 個阿拉伯數字的字符串。

A二、A3：創建結構爲 (id,data) 的組表文件，@r 選項表示使用行式存儲方式。

A4：循環 6000 次，循環體B四、B5，每次生成 10 萬條對應結構的記錄，並追加到組表文件。

執行後，生成組表文件：id_600m.ctx。

代碼5.2

代碼5.2爲組表id列創建索引。

執行後，生成組表的索引文件：id_600m.ctx__id_idx

代碼5.3

代碼5.3，在組表的 icursor()這個函數中，使用索引 id_idx，以條件 A2.contain(id) 來過濾組表。集算器會自動識別出 A2.contain(id) 這個條件可使用索引，並會自動將 A2 的內容排序後從前向後查找。

進階使用

使用排序索引多線程查找時，按鍵值排序分組後扔給多個線程去查詢，避免兩個線程中有交叉內容。同時，還能夠設計成多個組表，把鍵值能平均分配到多個組表上並行查找。

所謂多線程並行，就是把數據分紅 N 份，用 N 個線程查詢。但若是隻是隨意地將數據分紅 N 份，極可能沒法真正地提升性能。由於將要查詢的鍵值集是未知的，因此理論上也沒法確保但願查找的數據可以均勻分佈在每一份組表文件中。比較好的處理方式是先觀察鍵值集的特徵，從而儘量地進行數據的均勻拆分。

若是鍵值數據有比較明顯的業務特徵，咱們能夠考慮按照實際業務場景使用日期、部門之類的字段來處理文件拆分。如：將屬於部門 A 的 1000 條記錄均分在 10 個文件中，每一個文件就有 100 條記錄。在利用多線程查詢屬於部門 A 的記錄時，每一個線程就會從各自對應的文件中取數相應的這 100 條記錄了。

下面咱們來看個實際的例子，已有數據文件multi_source.txt的結構以下：

其中 type 和 id 兩個字段做爲聯合主鍵肯定一條記錄，其中部分數據以下：

代碼5.4

代碼5.4詳解：

A1：type 的枚舉值組成的序列。在實際狀況中，枚舉列表可能來自文件或者數據庫數據源。。

A2：給枚舉值序列中每一個 type 一個 tid。爲後續的數字化主鍵合併作準備。

A3~A6：從 multi_source.txt 文件中獲取數據，並按照 A2 中的對應關係，把 type 列的枚舉串變成數字，而後將 type 和 id 進行合併後，生成新的主鍵 nid。

A7：使用循環函數，建立名爲「鍵值名 _ 鍵值取 N 的餘數 _T.ctx」的組表文件，其結構同爲 (#nid,data)。

A8：用循環函數將遊標數據分別追加到 N 個原組表上。好比當 N=1 時，拼出的 eval 函數參數爲：channel(A4).select(nid%4==0).attach(A7(1).append(~.cursor()))。意思是對遊標 A4 建立管道，將管道中記錄按鍵值 nid 取 4 的餘數，將餘數值等於 0 的記錄過濾出來。attach 是對當前管道的附加運算，表示取和當前餘數值對應的原組表，將當前管道中篩選過濾出的記錄，以遊標記錄的方式追加到 A7(1)，即第 1 個組表。

A9：循環遊標 A6，每次獲取 50 萬條記錄，直至 A6 遊標中的數據取完。

執行後，產出 4（這時例子取 N=4）個獨立的組表文件：

代碼5.5

代碼5.5，建立索引過程詳解：

A1：列出知足 nid*T.ctx 的文件名（這裏 * 爲通配符），這裏 @p 選項表明須要返回帶有完整路徑信息的文件名。使用 fork 執行多線程時，須要注意環境中的並行限制數是否設置合理。這裏用了 4 個線程，設計器中對應的設置以下：

B1：每一個線程爲各個組表創建對應的索引文件，最終結果以下：

代碼5.6

代碼5.6，查詢過程詳解：

A1：從 keys.txt 獲取查詢鍵值序列，由於只有一列結果，使用 @i 選項，將結果返回成序列：

A2：把 A1 的序列按 4 的餘數進行等值分組：

A三、B3~B5：用 fork 函數，按等值分組後的鍵值對各個組表分別並行查詢。這裏的 fork 後面分別寫了兩個參數，第一個是循環函數 N.(~-1)，第二個是 A2。在接下來的 B三、B4 中分別使用 A3(2) 和 A3(1) 來獲取 fork 後面這兩個對應順序的參數，B4：對組表文件進行根據 B3 中的鍵值集進行數據篩選，B5：返回遊標。因爲 A3 中是多個線程返回的遊標序列，因此 A6 中須要使用 conjx 對多個遊標進行縱向鏈接。

A6~A7：將多個線程返回的遊標進行縱向鏈接後，導出遊標記錄至文本文件，前幾行內容以下。