緣起

已釋出至個人部落格

工作中遇到這樣一個問題，業務中有一個支援文字檢索的功能，原本在資料量小的時候，世界都很平靜，可是當資料條數從5W漲到了100W+的時候，世界變了，響應時間急劇增長。怎麼破？這時想到了文字檢索的神器elasticsearch。立馬拿來試用一下。

測試

1.到官網上下載了es的最新版本，地址在這裡，解壓後就可以直接用了。因為地址是https的，所以下載的時候需要新增上–no-check-certificate，如下所示

wget --no-check-certificate https://download.elastic.co/elasticsearch/elasticsearch/elasticsearch-1.7
 
.1.tar.gz

1. 解壓，直接執行報錯，查了下發現是對jdk版本有要求，升級沒商量
2. 然後直接開啟就好了，當然這是單機版的情況

下面貼出效能測試的結果：
100W的記錄，30個字元的name。無其他資料。好單薄的資料。查詢條件為隨機字元，構造長度為1-30的字元，每個長度字元查詢1000次。程式碼段如下：

function esTimesTest() {
    $b = microtime(true);
    $b1 = time();
    for ($i = 1; $i <= 100; ++$i) {
        for ($j = 1; $j <= 30; ++$j
 
) {
            $key = getRandString($j);
            $key = "*$key*";
            $url = "curl -XGET 'http://localhost:9200/ugc/1/_search?q=name:$key'";//真正run的時候，不是本機測試，請注意
            $time = microtime(true);
            $ret = shell_exec($url);
            $rets = json_decode($ret, true);
            $count
 
 = count($rets);
            $timelast = microtime(true) - $time;

            print_r($key . "\t" . $count . "\t" . $timelast . "\n");
        }
    }

    $l = time() - $b1;
    print_r("total time " . $l . PHP_EOL);
    $t = microtime(true) - $b;
    print_r("total microtime " . $t . PHP_EOL);
}

總耗時195s，3000次請求，平均耗時0.065s。真實測試的時候，是在位於同一個機房的兩臺機器上做的。而業務之前用的mongodb+regex的方式，介面請求耗時均在1s以上，具體資料就不給出了。
下面給出es查詢在不同字元長度下，平均耗時結果：

結論

從上面的資料不難看出，要使用合適的工具做合適的事情。es在文字檢索方面的應用已經很成熟了。其他高階特性還要在應用中繼續熟悉。