用ES有一段時間了,可是項目用的都是很簡單的邏輯,抽時間系統的學習了一下,整理一下 Elasticsearch 都有什麼功能 。
html
如下資料參照官方文檔ES 7.2
www.elastic.co/guide/en/el…sql
Search_type 搜索類型api
Es詞條在各類分片中 每一個分片詞條分數不一致 因此有4種方式取TOPNbash
QUERY_AND_FEATCH :<br>
搜索時向全部分片發出查詢請求,各分片返回的時候把元素文檔和計算後的排名信息一塊兒返回 效率高 可是每個分片都取topn 再排序就會不許 <br>
QUERY_THEN_FETCH (默認方式)<br>
和上面的相比 取出來的是id和排序相關信息 排序完成後 再取數據 兩次請求<br>
DFS_QUERY_AND_FEATCH<br>
把全部分片數據都取出來 而後綜合排序 效率比上面的第 可是最準確
DFS_QUERY_THEN_FEATCH<br>
DFS的後續過程和QUERY_THEN_FETCH一致
複製代碼
Search_after 深度分頁app
假若有深度分頁的需求 那麼 from,size 這種分頁方式就會有很高的損耗 使用 search_after 須要指定主鍵 _id 和 輔助排序索引 指定排序規則 而且不能設置from 舉個一看就懂的官方例子運維
第一次查詢
GET twitter/_search
{
"size": 10,
"query": {
"match" : {
"title" : "elasticsearch"
}
},
"sort": [
{"date": "asc"},
{"tie_breaker_id": "asc"}
]
}
第二次 search_after 查詢 指定了上一次查詢 date和tie_breaker_id 的值
GET twitter/_search
{
"size": 10,
"query": {
"match" : {
"title" : "elasticsearch"
}
},
"search_after": [1463538857, "654323"],
"sort": [
{"date": "asc"},
{"tie_breaker_id": "asc"}
]
}
複製代碼
Track_total_hits 統計上限elasticsearch
若是你的數據量很大 若是要count某個索引 那麼須要徹底匹配後才能統計完數據 track_total_hits=999 能夠指定若是知足999條數據匹配 就能夠再也不往下匹配了
ide
_source 和 stored_fields post
stored_fields 是單個文檔 一條記錄可能有多個stored_fields 如 id,name等 若是查詢時指定stored_fields 那麼就會有N次IO
_source 就是id,name的整體文檔 而且是壓縮過的 若是查詢時指定_source 那麼只會有一次IO 可是若是遇到某個字段特別的大 就會浪費內存空間和解析的時間
性能
Post_filter
一般聚合agg 會在filter 以後 若是想聚合全量的數據可是又想查詢過濾filter 那麼須要post_filter 這時agg會在post_filter以前
Min_score 最小分數過濾
查詢的數據必須知足最小分數限制
Explain 查詢的時候展現詳情
查看細節 或者 調試的時候有用
Collapse 至關於 sql的 distinct
Nested 和 parent/child 內嵌索引和父子索引
爲了解決關聯查詢效率低的問題 引入了內嵌和父子索引
內嵌索引的一對多至關於一個總體 改任何一條記錄都須要改整個索引
父子索引是獨立的索引 可是查詢效率不如內嵌索引, 且索引必須在一個分片,且不能改變父子索引關係
Highlight 高亮
高亮就像百度查出來的帖子 裏面各類紅色的分詞
Boost 查詢權重加成
某個條件加入boost 那麼這個條件的score = score*boost 那麼他的分數就會更大
{
"_source": false,
"min_score": 4,
"explain": true,
"query": {
"term": {
"deliverId": {
"value": 57257826348037,
"boost": 10
}
}
}
}
複製代碼
Suggest 搜索建議
像谷歌那種 若是你查詢的單詞有誤 而後建議你 是否是要查找xxxx
Freeze Index 凍結索引
有些索引常常用不到 查詢頻率很是低 這時候可使用凍結索引 來節省內存
X-PACK 這是官方付費包
裏面有各類高級特性,也有一些是開源免費的
Cat Api 打各類日誌
Aggregations 各類統計
統計分爲三種類別 指標統計,分桶聚合,桶管道統計
blog.csdn.net/zyc88888/ar…
上面這個文章簡單介紹了三種統計相互配合的例子
1、Metrics Aggregations 指標統計
1.Avg Aggregation 計算出字段平均值
2.Weighted Avg Aggregation 加權平均值
3.Cardinality Aggregation 計算出字段的惟一值
4.Extended Stats Aggregation 綜合屬性,最大,最小,方差等等
5.Geo Bounds Aggregation 座標點方框範圍統計,返回左上,右下座標
6.Geo Centroid Aggregation 給一個範圍,統計中心點
7.Max Aggregation 最大值
8.Min Aggregation 最小值
9.Percentiles Aggregation 查出結果 按照類別劃分「百分位數」
好比能夠應用於一個網站的加載時長的指標,或者各類性能指標。
10.Percentile Ranks Aggregation 給一組類別 返回對應百分比
11.Scripted Metric Aggregation 寫腳本統計 至關於本身計數
12.Sum Aggregation 求和
13.Top Hits Aggregation 至關於group by 而後 topN
14.Value Count Aggregation 數量統計 一個類別有多少不一樣的值
15.Median Absolute Deviation Aggregation 絕對中位差 標準差的改進版 避免某一個離散點的影響力
2、Bucket Aggregations 分桶統計
1.Adjacency Matrix Aggregation 鄰接矩陣統計 例如共同好友這些功能
2.Date Histogram Aggregation 日期柱狀圖統計 按照日期間隔統計數量
3.Composite Aggregation 多條件聚合 至關於多條件的count group by
4.Range Aggregation 範圍分桶統計
5.Date Range Aggregation 按日期格式範圍分桶統計
6.Sampler Aggregation 採集器
貌似是說 若是一個低相關度的詞和一個高相關度的詞在一塊兒 那麼若是都去匹配 就會浪費資源 能夠設置匹配分數最佳的詞條 topN
7.Ip Range Aggregation Ip範圍統計
8.Nested /Reverse Nested Aggregation 內嵌統計
9.Parent Aggregation 父子統計
10.Terms/Significant Terms Aggregation 按key聚合統計
Significant Terms 相比Terms 會考慮佔比 好比100個文檔命中4個 和 1000個文檔命中8個 顯然前者更關鍵。
11.Significant Terms Aggregation 指定文本,按重要文本聚合統計
12.Geo Distance Aggregation 按地址距離統計
13.GeoHash grid Aggregation GeoHash網格統計
GeoHash是將地圖劃分紅塊並用字符串標識 能夠統計出有多少個區域塊,或者指定區域塊有多少數據匹配該塊
關於GeoHash的介紹和應用連接 blog.csdn.net/alitech2017…
3、Pipeline Aggregations 對桶進行流式統計
1.Avg Bucket Aggregation 對桶統計後的結果求平均
2.Derivative Aggregation 對桶求導
比較晦澀 舉個官方栗子 算月利潤增漲
Request:
POST /sales/_search
{
"size": 0,
"aggs" : {
"sales_per_month" : {
"date_histogram" : {//對日期月份分桶
"field" : "date",
"calendar_interval" : "month"
},
"aggs": {
"sales": {//取每個月的利潤總和
"sum": {
"field": "price"
}
},
"sales_deriv": {//對每個月利潤求導,sales 爲上面的求和統計名
"derivative": {
"buckets_path": "sales"
}
}
}
}
}
}
複製代碼
Response:
{
"took": 11,
"timed_out": false,
"_shards": ...,
"hits": ...,
"aggregations": {
"sales_per_month": {
"buckets": [
{
"key_as_string": "2015/01/01 00:00:00", //1月
"key": 1420070400000,
"doc_count": 3,//匹配文檔3個
"sales": {
"value": 550.0 //月總利潤550
}
},
{
"key_as_string": "2015/02/01 00:00:00",//2月
"key": 1422748800000,
"doc_count": 2,
"sales": {
"value": 60.0 //月總利潤60
},
"sales_deriv": {
"value": -490.0 // 月利潤求導 上一條沒有記錄 是由於求導須要兩條數據 因此第一條沒有數據
}
},
{
"key_as_string": "2015/03/01 00:00:00",
"key": 1425168000000,
"doc_count": 2,
"sales": {
"value": 375.0
},
"sales_deriv": {
"value": 315.0
}
}
]
}
}
}
複製代碼
3.Max/Min/Sum Bucket Aggregation 對桶求最大/最小值/求和
4.Percentiles Bucket Aggregation 對桶求百分位數
這個官方例子沒有Percentiles Aggregation 講的好 先看這個而後再對應分桶就是了
5.Moving Average[Function] Aggregation 滑動平均法分桶聚合
「滑動平均法」利用現有的數據,預測將來的走勢,消除個別離散點的影響。
下圖是滑動窗口數值10和100的區別圖。
6.Cumulative Sum Aggregation 對桶累加求和 適用於柱狀圖
7.Bucket Sort Aggregation 對桶排序
8.Bucket Selector Aggregation 對桶再次過濾
9.Bucket Script Aggregation 對桶進行腳本運算 比 Bucket Selector 更定製一些
Indices API
裏面有各類對索引的管理
例如:建立,刪除,獲取,擴容,壓縮,重構,別名,改變Mapping 等..
Cluster API
裏面有各類集羣的管理 感受像是運維的東西 先不看了。。。
Mapping
mapping 就至關於Sql的建表語句同樣
一個索引對應一個mapping 包含了各類信息
_index(db),_type(table),_id(index),_score(分數),field(各類字段)
下面的是mapping的字段類型 只列出不常規的類型 常規類型不舉例了
field datatypes
1.keyword
與text的區別是 keywork須要精確的查找 好比郵箱,姓名等,而text通常用來分詞查找的。
2.geo_point
用來存經緯度的 應用能夠參考上面的geohash統計
3.ip
這是用來避免字符串分詞的? 有對應的ip查找api
4.nested/join datatype
上面講過nested內嵌類型和父子文檔查詢 這個就是對應的內嵌/父子存儲類型
5.Percolator type
反向查詢類型 配合Percolator query
貌似是說 爲索引註冊一個查詢條件 而後用value 反向來判斷這個註冊的查詢條件 有沒有匹配 應用一些報警和監控,好比你註冊了一個監控條件 而後當有一條數據插入的時候 會判斷這條數據是否匹配你的監控??? 大概是這個意思 下面是一個相對 好一點的例子 不過感受仍是不太懂
www.elastic.co/cn/blog/per…
6.Rank feature/features datatype
高性能打分和_score相似,_score是一個文檔對應的分數 這個是一個單獨的存儲類型 配合Rank feature Query 使用 而且Query還支持多種變化分數的計算公式 比計算_score的fuction scroe query 要高效。
mapping paramters mapping的參數
1.analyzer
文本分詞器 這個之後詳細講吧
2.normalizer
和keyword配套 好比大小寫不匹配的時候 查不出來 這時候能夠指定按照小寫來查 3.boost
對打分的分數進行二次加成
4.doc_values
若是肯定某個字段 不進行 排序 聚合 和腳本操做 能夠禁用 節約磁盤空間提高索引速度
5.fieldData
fieldData 主要針對於 text 這種須要分詞的field 來進行存儲設置
fieldData.loading = eager 預加載,正常fieldData是落在磁盤的。 若是要檢索大量的字符串,就須要很是耗時。這時候就須要預加載了。 fieldData 裏面還有各類 匹配加載策略 能夠節省加載的內存 。 6.其餘
其餘的參數太過於扣細節了 感受很難有實際應用場景 大多都是和分詞匹配有關的 之後真遇到再說吧
Analysis 裏面有各類分詞器 可是都沒什麼卵用 由於咱們都用中文,因此得自定義了。 網上找的一些分詞 IK,jieba,Hanlp,THUAC 聽說ik經常使用。