楔子

ES全名elasticsearch翻譯過來是彈性搜索；從名字直觀的了解，這個東西是解決搜搜的問題；

作為一個經(jīng)常寫SQL的人來說；搜索在我的映像中就是select * from table where，那為什么還要ES？

當數(shù)據(jù)變多時，原有方案開始變得糟糕

mysql對于一些較為固定，字段較少的查詢方式，可以通過簡單的增加索引來完成優(yōu)化，在大多數(shù)公司，即使你對索引優(yōu)化不熟悉，也有專門的dba來幫你完成一些簡單的優(yōu)化。甚至有些電商公司要求程序中不允許出現(xiàn)orm，必須用純sql來完成業(yè)務邏輯，這樣dba可以直接介入到代碼中來。

不過到字段太多的時候這招就不靈了，字段越多，查詢自然就越慢(比如單條記錄可能都超過了4k什么，甚至有些oracle的表里，一個字段就有幾兆信息，當然幾兆信息的這種這里也解決不了，嗯)。

mysql表在普通查詢過程中，比如select * from xxx limit 100w, 100;這種，小網(wǎng)站隨便寫sql，可能不會體會到翻頁的痛。但你在一個單表3000w的系統(tǒng)中寫了limit 10000000, 10。那數(shù)據(jù)庫服務器就哭了。因為實際上數(shù)據(jù)庫為了取出你想要的那幾條數(shù)據(jù)，需要把所有的數(shù)據(jù)也就是10000010條都取到內(nèi)存中，復雜一點的select再加上order by則可能會同時涉及到多次磁盤讀取和文件排序。慢上加慢。

除此之外，現(xiàn)在最流行的innodb之類的存儲引擎在計算count的時候非常的慢。當然了，網(wǎng)絡上會有人從亂七八糟的文章里看到換myisam應該就會更快的結論，但這其實是錯的。如果在select語句的where條件中也有表達式時，這兩種存儲引擎本質上都是一樣的，都會很慢很慢。

還有mysql的like，其實沒什么玄幻的，每次做like本質還是查詢內(nèi)容去和數(shù)據(jù)庫字段做字符串匹配。非常地慢。

現(xiàn)在一般的互聯(lián)網(wǎng)系統(tǒng)都是普遍的寫少讀多的系統(tǒng)，寫/讀搞不好會有1/5以上？但因為數(shù)據(jù)量龐大，為了讀取效率而去做拆表或者拆庫的話，有時候實在是有點得不償失。而且拆表拆庫對業(yè)務代碼來說也并不透明，還可能會對本來支持的功能造成額外的影響。只是為了查詢而去拆分的話，不是很合適。

ES是怎么解決這個問題的？

上面這些問題，es都可以解決。企業(yè)里對數(shù)據(jù)的查詢一般可以分為三種：列表查詢、詳情查詢和統(tǒng)計查詢?？疵忠部梢岳斫獾牟畈欢嗔?#xff0c;列表一般就是列表頁對應的查詢，詳情查詢一般就是具體id對應的詳情查詢，而統(tǒng)計查詢一般都是在看一些數(shù)值之類的報表，也就是一堆count值。

這三種查詢里，mysql做起來最困難的是1和3，即列表查詢和統(tǒng)計查詢。列表查詢這種場景也會對應各種各樣的查詢條件，例如字段等于/小于/大于/不等判斷，或者像字符串的嚴格匹配/前后綴模糊查詢，時間字段的范圍查詢，in查詢等等。這些查詢都可以翻譯為es中的bool查詢，舉一個簡單的例子：

{"from" : 0,"size" : 15,"query" : {"bool": {"must" : [{"range" : {"create_time" : {"from":"2016-08-11T00:00:00+0800","to":"2016-08-11T23:59:00+0800"}}},{"term" : {"user_id" : "37540"}},{"terms" : {"status" : [2,1,0]}}]}},"sort" : [{"create_time" : "desc"}],"highlight" : {} }

例如上面這個es中的bool查詢，就是從這種sql翻譯過來的：

select * from db/table where create_time between ('2016-08-11 00:00:00' and '2016-08-11 23:59:59')and user_id = 37540 and status in (2, 1, 0);

對應到業(yè)務里，常用的查詢其實大多數(shù)都是這些很簡單的條件并列，A && B && C && D。所以翻譯起來也比較簡單。

單表的count放在es里做也非常的快，為什么呢？因為es本身會把單個字段的一種值當作一個term，然后會記錄這個term出現(xiàn)的所有文檔和出現(xiàn)次數(shù)。舉個例子，我們公司的業(yè)務，你可能會去查詢某個業(yè)務線下的所有工單。那么查詢條件就類似于where business_type is 6這樣。可能只需要一毫秒就返回了結果。很費解是不是？其實es也只是去讀了一下這個business_type是6的term出現(xiàn)的文檔數(shù)。邏輯上是很簡單的。

ES是萬能的嘛？

這是不是說明es就是萬能的了？

對于搜索來說，ES不是萬能的

首先是翻頁的問題，es里有上億數(shù)據(jù)，翻到最后一頁的時候還是會比較慢，并且會影響到整個系統(tǒng)的load，然后系統(tǒng)響應變慢。因為其原理還是拿一堆數(shù)據(jù)來做merge。

從傳統(tǒng)的sql思維翻譯到es的dsl過程也稍微有點痛苦。因為es畢竟是從搜索引擎的角度去做這些事情，所以如果你當DB來用的話，其DSL設計就顯得很別扭。雖然有了上面的轉換規(guī)則，但實際上業(yè)務轉換起來并沒有這么方便，比如在通常的查詢里還可能會有where a = 1 or b = 2。顯然想轉成DSL就沒有這么方便了。

把ES作為存儲來用，是有短板的

es不是數(shù)據(jù)庫，所以如果你想要實現(xiàn)聯(lián)表查詢也會變得很麻煩。并且ES不是一個數(shù)據(jù)庫，所以沒有事務概念；所以一般用ES+MYSQL來解決搜索+存儲的功能

總結

以上是生活随笔為你收集整理的bool查询原理 es_谈谈ES在数据应用中的作用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。