Elasticsearch的默認配置,是綜合了數據可靠性、寫入速度、搜索實時性等因素。實際使用時,咱們須要根據公司要求,進行偏向性的優化。javascript
假設咱們的應用場景要求是,每秒300萬的寫入速度,每條500字節左右。
正對這種對於搜索性能要求不高,可是對寫入要求較高的場景,咱們須要儘量的選擇恰當寫優化策略。綜合來講,能夠考慮如下幾種方面來提高寫索引的性能:css
Elasticsearch提供了bulk API支持批量操做,當咱們有大量的寫任務時,可使用bulk來進行批量寫入。每次提交的數據量爲多少時,能達到最優的性能,主要受到文件大小、網絡狀況、數據類型、集羣狀態等因素影響。
通用的策略以下:java
bulk默認設置批量提交的數據量不能超過100M。數據條數通常是根據文檔的大小和服務器性能而定的,可是單次批處理的數據大小應從5MB~15MB逐漸增長,當性能沒有提高時,把這個數據量做爲最大值。node
咱們能夠跟着,感覺一下bulk接口,以下所示:linux
$ vi request
$ cat request
{ "index" : { "_index" : "chandler","_type": "test", "_id" : "1" } } { "name" : "錢丁君","age": "18" } $ curl -s -H "Content-Type: application/json" -XPOST localhost:9200/_bulk --data-binary @request; echo {"took":214,"errors":false,"items":[{"index":{"_index":"chandler","_type":"test","_id":"1","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":0,"_primary_term":1,"status":201}}]} $ curl -XGET localhost:9200/chandler/test/1?pretty { "_index" : "chandler", "_type" : "test", "_id" : "1", "_version" : 1, "found" : true, "_source" : { "name" : "錢丁君", "age" : "18" } }
bulk不支持get操做,由於沒什麼用處。web
Elasticsearch是一種密集使用磁盤的應用,在段合併的時候會頻繁操做磁盤,因此磁盤要求較高,當磁盤速度提高以後,集羣的總體性能會大幅度提升。
磁盤的選擇,提供如下幾點建議:數據庫
path.data:/path/to/data1,/path/to/data2。
Lucene以段的形式存儲數據。當有新的數據寫入索引時,Lucene就會自動建立一個新的段。隨着數據量的變化,段的數量會愈來愈多,消耗的多文件句柄數及CPU就越多,查詢效率就會降低。
因爲Lucene段合併的計算量龐大,會消耗大量的I/O,因此Elasticsearch默認採用較保守的策略,讓後臺按期進行段合併,以下所述:json
PUT /_cluster/settings
{
"persistent" : { "indices.store.throttle.max_bytes_per_sec" : "100mb" } }
Lucene在新增數據時,採用了延遲寫入的策略,默認狀況下索引的refresh_interval爲1秒。Lucene將待寫入的數據先寫到內存中,超過1秒(默認)時就會觸發一次refresh,而後refresh會把內存中的的數據刷新到操做系統的文件緩存系統中。若是咱們對搜索的實效性要求不高,能夠將refresh週期延長,例如30秒。這樣還能夠有效地減小段刷新次數,但這同時意味着須要消耗更多的Heap內存。以下所示:bootstrap
index.refresh_interval:30s
flush的主要目的是把文件緩存系統中的段持久化到硬盤,當Translog的數據量達到512MB或者30分鐘時,會觸發一次Flush。 index.translog.flush_threshold_size 參數的默認值是512MB,咱們進行修改。
增長參數值意味着文件緩存系統中可能須要存儲更多的數據,因此咱們須要爲操做系統的文件緩存系統留下足夠的空間。vim
Elasticsearch爲了保證集羣的可用性,提供了replicas(副本)支持,然而每一個副本也會執行分析、索引及可能的合併過程,因此replicas的數量會嚴重影響寫索引的效率。當寫索引時,須要把寫入的數據都同步到副本節點,副本節點越多,寫索引的效率就越慢。
若是咱們須要大批量進行寫入操做,能夠先禁止replica複製,設置index.number_of_replicas: 0 關閉副本。在寫入完成後,replica修改回正常的狀態。
在5.2.5節中介紹了集羣中的查詢流程,若是想要查詢從from開始的size條數據,須要每一個分片查詢打分排名在前面的from+size條數據。協同節點將收集到的n✖️(from+size)條數據聚合,再進行一次排序,而後從from+size開始返回size條數據。
當from、size或者n中有一個值很大的時候,須要參加排序的數量也會增加,這樣的查詢會消耗不少CPU資源,從而致使效率的下降。
爲了提高查詢效率,Elasticsearch提供了scroll和scroll-scan這兩種查詢模式。
scroll是爲檢索大量的結果而設計的。例如,咱們須要查詢1~100頁的數據,每頁100條數據。
若是使用search查詢:每次都須要在每一個分片上查詢得分最高的from+100條數據,而後協同節點把收集到的n✖️(from+100)條數據聚合起來再進行一次排序。每次返回from+1開始的100條數據,而且要重複執行100次。
若是使用scroll查詢:在各個分片上查詢10000條數據,協同節點聚合n✖️10000條數據進行合併、排序,並將排名前10000的結果快照起來。這樣作的好處是減小了查詢和排序的次數。
Scroll初始查詢的命令是:
$ vim scroll
$ cat scroll
{
"query": { "match": { "name": "錢丁君" } }, "size":20 } $ curl -s -H "Content-Type: application/json; charset=UTF-8" -XGET localhost:9200/chandler/test/_search?scroll=2m --data-binary @scroll; echo {"_scroll_id":"DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAAAGFlB6Y3QtNk9oUmdpc09Tb21rX2NXQXcAAAAAAAAABxZQemN0LTZPaFJnaXNPU29ta19jV0F3AAAAAAAAAAgWUHpjdC02T2hSZ2lzT1NvbWtfY1dBdwAAAAAAAAAJFlB6Y3QtNk9oUmdpc09Tb21rX2NXQXcAAAAAAAAAChZQemN0LTZPaFJnaXNPU29ta19jV0F3","took":14,"timed_out":false,"_shards":{"total":5,"successful":5,"skipped":0,"failed":0},"hits":{"total":1,"max_score":0.8630463,"hits":[{"_index":"chandler","_type":"test","_id":"1","_score":0.8630463,"_source":{ "name" : "錢丁君","age": "18" }}]}}
以上查詢語句的含義是,在chandler索引的test type裏查詢字段name包含「錢丁君」的數據。scroll=2m表示下次請求的時間不能超過2分鐘,size表示此次和後續的每次請求一次返回的數據條數。在此次查詢的結果中除了返回了查詢到的結果,還返回了一個scroll_id,能夠把它做爲下次請求的參數。
再次請求的命令,以下所示:
Scroll是先作一次初始化搜索把全部符合搜索條件的結果緩存起來生成一個快照,而後持續地、批量地從快照里拉取數據直到沒有數據剩下。而這時對索引數據的插入、刪除、更新都不會影響遍歷結果,所以scroll 並不適合用來作實時搜索。其思路和使用方式與scroll很是類似,可是scroll-scan關閉了scroll中最耗時的文本類似度計算和排序,使得性能更加高效。
爲了使用scroll-scan,須要執行一個初始化搜索請求,將search_type設置成scan,告訴Elasticsearch集羣不須要文本類似計算和排序,只是按照數據在索引中順序返回結果集:
$ vi scroll
$ cat scroll
{
"query": { "match": { "name": "錢丁君" } }, "size":20, "sort": [ "_doc" ] } $ curl -H "Content-Type: application/json; charset=UTF-8" -XGET 'localhost:9200/chandler/test/_search?scroll=2m&pretty=true' --data-binary @scroll { "_scroll_id" : "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAABWFlB6Y3QtNk9oUmdpc09Tb21rX2NXQXcAAAAAAAAAVxZQemN0LTZPaFJnaXNPU29ta19jV0F3AAAAAAAAAFgWUHpjdC02T2hSZ2lzT1NvbWtfY1dBdwAAAAAAAABZFlB6Y3QtNk9oUmdpc09Tb21rX2NXQXcAAAAAAAAAWhZQemN0LTZPaFJnaXNPU29ta19jV0F3", "took" : 3, "timed_out" : false, "_shards" : { "total" : 5, "successful" : 5, "skipped" : 0, "failed" : 0 }, "hits" : { "total" : 1, "max_score" : null, "hits" : [ { "_index" : "chandler", "_type" : "test", "_id" : "1", "_score" : null, "_source" : { "name" : "錢丁君", "age" : "18" }, "sort" : [ 0 ] } ] } }
注意:Elasticsearch 2.1.0版本以後移除了search_type=scan,使用"sort": [ "_doc"]進行代替。
scroll和scroll-scan有一些差異,以下所示:
ES中所謂的路由和IP網絡不一樣,是一個相似於Tag的東西。在建立文檔的時候,能夠經過字段爲文檔增長一個路由屬性的Tag。在多分片的Elasticsearch集羣中,對搜索的查詢大體分爲以下兩種。
(1)ES內在機制決定了擁有相同路由屬性的文檔,必定會被分配到同一個分片上,不管是主分片仍是副本。查詢時能夠根據routing信息,直接定位到目標分片,避免查詢全部的分片,再通過協調節點二次排序。若是5-24所示。
(2)若是在查詢條件中不包含routing,在查詢時就遍歷全部分片,整個查詢主要分爲Scatter、Sather兩個過程。
shard = hash(routing)%number_of_primary_shards
不過須要注意的是,根據城市id進行分片時,也會容易出現分片不均勻的狀況。例如,大型城市的數據過多,而小城市的數據太少,致使分片之間的數據量差別很大。這時就能夠進行必要的調整,好比把多個小城市的數據合併到一個分片上,把大城市的數據按區域進行拆分到不一樣分配。
在Scatter、Gather的過程當中,節點間的數據傳輸和打分(SearchType),能夠根據不一樣的場景選擇。以下所示
因爲在Lucene中段具備不變性,每次進行刪除操做後不會當即從硬盤中進行實際的刪除,而是產生一個.del文件記錄刪除動做。隨着刪除操做的增加,.del文件會越來也多。當咱們進行查詢操做的時候,被刪除的數據還會參與檢索中,而後根據.del文件進行過濾。.del文件越多,查詢過濾過程越長,進而影響查詢的效率。當機器空閒時,咱們能夠經過以下命令刪除文件,來提高查詢的效率:
$ curl -XPOST localhost:9200/chandler/_forcemerge?only_expunge_deletes=true {"_shards":{"total":10,"successful":5,"failed":0}}
按期對再也不更新的索引作optimize (ES2.0之後更改成force merge api)。這Optimze的實質是對segment file強制作合併,能夠節省大量的segment memory。
Elasticsearch默認安裝後設置的內存是1GB,對於任何一個現實業務來講,這個設置都過小了。若是是經過解壓安裝的Elasticsearch,則在Elasticsearch安裝文件中包含一個jvm.option文件,添加以下命令來設置Elasticsearch的堆大小:
-Xms10g -Xmx10g
Xms表示堆的初始大小,Xmx表示可分配的最大內存,都是10GB。確保Xmx和Xms的大小是相同的,其目的是爲了可以在java垃圾回收機制清理完堆區後不須要從新分隔計算堆區的大小而浪費資源,能夠減輕伸縮堆大小帶來的壓力。
也能夠經過設置環境變量的方式設置堆的大小。服務進程在啓動時候會讀取這個變量,並相應的設置堆的大小。好比:
export ES_HEAP_SIEZE=10g
也能夠經過命令行參數的形式,在程序啓動的時候把內存大小傳遞給Elasticsearch,以下所示:
./bin/elasticsearch -Xmx10g -Xms10g
這種設置方式是一次性的,在每次啓動Elasticsearch時都須要添加。
假設你有一個64G內存的機器,按照正常思惟思考,你可能會認爲把64G內存都給Elasticsearch比較好,但現實是這樣嗎, 越大越好?雖然內存對Elasticsearch來講是很是重要的,可是答案是否認的!由於Elasticsearch堆內存的分配須要知足如下兩個原則:
Java使用內存指針壓縮(Compressed Oops)技術來解決這個問題。它的指針再也不表示對象在內存中的精確位置,而是表示偏移量。這意味着32位的指針能夠引用4GB個Byte,而不是4GB個bit。也就是說,當堆內存爲32GB的物理內存時,也能夠用32位的指針表示。
不過,在越過那個神奇的邊界----32GB時,指針就會變爲普通對象的指針,每一個對象的指針都變長了,就會浪費更多的內存,下降了CPU的性能,還要讓GC應對更大的內存。事實上,當內存到達40~40GB時,有效的內存才至關於內存對象指針壓縮技術時的32GB內存。因此即使你有足夠的內存,也儘可能不要超過32G,好比咱們能夠設置爲31GB:
-Xms31g -Xmx31g
32GB是ES一個內存設置限制,那若是你的機器有很大的內存怎麼辦呢?如今的機器內存廣泛增加,甚至能夠看到有300-500GB內存的機器。這時咱們須要根據業務場景,進行恰當內存的分配。
swapping是性能的墳墓
在選擇Elasticsearch服務器時,要儘量地選擇與當前應用場景相匹配的服務器。若是服務器配置很低,則意味着須要更多的節點,節點數量的增長會致使集羣管理的成本大幅度提升。若是服務器配置很高,,而在單機上運行多個節點時,也會增長邏輯的複雜度。
在計算機中運行的程序均需在內存執行,若內存消耗殆盡將致使程序沒法進行。爲了解決這個問題,操做系統使用一種叫做虛擬內存的技術。當內存耗盡時,操做系統就會自動把內存中暫時不使用的數據交換到硬盤中,須要使用的時候再從硬盤交換到內存。
若是內存交換到磁盤上須要10毫秒,從磁盤交換到內存須要20浩渺,那麼多的操做時延累加起來,將致使幾何級增加。不難看出swapping對於性能是多麼可怕。因此爲了使Elasticsearch有更好等性能,強烈建議關閉swap。
關閉swap的方式以下。
(1)暫時禁用。若是咱們想要在linux服務器上暫時關閉,能夠執行以下命令,但在服務器重啓後失效:
sudo swapoff -a
(2)永久性關閉。咱們能夠修改/etc/sysctl.conf(不一樣等操做系統路徑有可能不一樣),增長以下參數:
vm.swappiness = 1 //0-100,則表示越傾向於使用虛擬內存。
注意:swappiness設置爲1比設置爲0要好,由於在一些內核版本,swappness=0會引起OOM(內存溢出)。
swappiness默認值爲60,當設置爲0時,在某些操做系統中有可能會觸發系統級的OOM-killer,例如在Linux內核的內存不足時,爲了防止系統的崩潰,會自動強制kill一個「bad」進程。
(3)在Elasticsearch中設置。若是上面的方法都不能作到,你須要打開配置文件中的mlockall開關,它的做用就是運行JVM鎖住內存,禁止OS交換出去。在elasticsearch.yml配置以下:
bootstrap.mlockall: true
因此,若是條件容許,則請儘量地使用SSD,它的讀寫性能將遠遠超出任何旋轉介質的硬盤(如機械硬盤、磁帶等)。基於SSD的Elasticsarch集羣節點對於查詢和索引性能都有提高。
另外不管是使用固態硬盤仍是使用機械硬盤,咱們都建議將磁盤的陣列模式設置爲RAID 0,以此來提高磁盤的寫性能。
Elastic search提供了Transport Client(傳輸客戶端)和Node Client(節點客戶端)的接入方式,這兩種方式各有利弊,分別對應不一樣的應用場景。
Transport Client做爲一個集羣和應用程序之間的通訊層,和集羣是安全解耦的。因爲與集羣解耦,因此在鏈接集羣和銷燬鏈接時更加高效,適合大量的客戶端鏈接。
Node Client把應用程序看成一個集羣中的Client節點(非Data和Master節點)。因爲它是集羣一個的內部節點,意味着它能夠感知整個集羣的狀態、全部節點的分佈狀況、分片的分佈情況等。
因爲Node Client是集羣的一部分,因此在接入和退出集羣時進行比較複雜操做,而且還會影響整個集羣的狀態,因此Node Client更適合少許客戶端,可以提供更好的執行效率。
Elasticsearch集羣中的數據節點負責對數據進行增、刪、改、查和聚合等操做,因此對CPU、內存和I/O的消耗很大。在搭建Elasticsearch集羣時,咱們應該對Elasticsearch集羣中的節點進行角色劃分和隔離。
候選主節點:
node.master=true node.data=false
數據節點:
node.master=false node.data=true
最後造成如圖5-26所示的邏輯劃分。
網絡異常可能會致使集羣中節點劃分出多個區域,區域發現沒有master節點的時候,會選舉出了本身區域內Maste節點r,致使一個集羣被分裂爲多個集羣,使集羣之間的數據沒法同步,咱們稱這種現象爲腦裂。爲了防止腦裂,咱們須要在Master節點的配置文件中添加以下參數:
discovery.zen.minimum_master_nodes=(master_eligible_nodes/2)+1 //默認值爲1
其中master_eligible_nodes爲Master集羣中的節點數。這樣作能夠避免腦裂的現象都出現,最大限度地提高集羣的高可用性。只要很多於discovery.zen.minimum_master_nodes個候選節點存活,選舉工做就能夠順利進行。
在Elasticsearch安裝目錄下的conf文件夾中包含了一個重要的配置文件:elasticsearch.yaml。
Elasticsearch的配置信息有不少種,大部分配置均可以經過elasticsearch.yaml和接口的方式進行。下面咱們列出一些比較重要的配置信息。
雖然如今有不少開源軟件對Elasticsearch的接口進行了封裝,使咱們能夠很方便、直觀地監控集羣的情況,可是在Elasticsearch 5之後,不少軟件開始收費。瞭解經常使用的接口有助於咱們在程序或者腳本中查看咱們的集羣狀況,如下接口適用於Elasticsearch 6.5.2版本。
PUT http://localhost:9200/indexname?pretty content-type →application/json; charset=UTF-8 { "settings":{ "number_of_shards" : 3, "number_of_replicas" : 1 } }
DELETE http://localhost:9200/indexname
DELETE http://localhost:9200/indexname1,indexname2 DELETE http://localhost:9200/indexname*
經過下面的接口能夠刪除集羣下的所有索引。
DELETE http://localhost:9200/_all DELETE http://localhost:9200/*
進行所有索引刪除是很危險的,咱們能夠經過在配置文件中添加下面的配置信息,來關閉使用_all和使用通配符刪除索引的接口,使用刪除索引職能經過索引的全稱進行。
action.destructive_requires_name: true
GET http://localhost:9200/indexname?pretty
POST http://localhost:9200/indexname/_close POST http://localhost:9200/indexname/_open
GET http://localhost:9200/indexname/typename/_mapping?pretty
當一個索引中有多個type時,得到mapping時要加上typename。
安裝ES和Kibana以後,進入Kibana操做頁面,而後進去的DevTools執行下面操做:
#添加一條document PUT /test_index/test_type/1 { "test_content":"test test" } #查詢 GET /test_index/test_type/1 #返回 { "_index" : "test_index", "_type" : "test_type", "_id" : "1", "_version" : 2, "found" : true, "_source" : { "test_content" : "test test" } }
put /index/type/id,說明以下:
search是咱們最經常使用的API,ES給我提供了豐富的查詢條件,好比模糊匹配match,字段判空exists,精準匹配term和terms,範圍匹配range
GET /_search
{
"query": { "bool": { "must": [ //must_not { "match": { "title": "Search" }}, { "match": { "content": "Elasticsearch" }}, {"exists":{"field":"字段名"}} //判斷字段是否爲空 ], "filter": [ { "term": { "status": "published" }}, { "terms": { "status": [0,1,2,3] }},//範圍 { "range": { "publish_date": { "gte": "2015-01-01" }}} //範圍gte:大於等於;gt:大於;lte:小於等於;lt:小於 ] } } }
查詢索引爲test_index,doc類型爲test_type的數據。
GET /test_index/test_type/_search
查詢索引爲test_index,doc類型爲test_type,docment字段num10爲4的數據
GET /test_index/test_type/_search?pretty=true { "query": { "bool": { "filter": [ { "term": { "num10": 4 }} ] } } }
更多查詢條件的組合,你們能夠自行測試。
PUT /my_index/_mapping/my_type
{
"properties": { "new_field_name": { "type": "string" //字段類型,string、long、boolean、ip } } }
如上是修改mapping結構,而後利用腳本script給字段賦值:
POST my_index/_update_by_query
{
"script": { "lang": "painless", "inline": "ctx._source.new_field_name= '02'" } }
以下給index爲test_index的數據綁定alias爲test_alias
POST /_aliases
{
"actions": [ { "add": { //add,remove "index": "test_index", "alias": "test_alias" } } ] }
驗證別名關聯,根據別名來進行數據查詢,以下:
GET /test_alias/test_type/3
_source元數據:就是說,咱們在建立一個document的時候,使用的那個放在request body中的json串(全部的field),默認狀況下,在get的時候,會原封不動的給咱們返回回來。
定製返回的結果,指定_source中,返回哪些field。
#語法: GET /test_index/test_type/1?_source=test_field2 #返回 { "_index" : "test_index", "_type" : "test_type", "_id" : "1", "_version" : 3, "found" : true, "_source" : { "test_field2" : "test field2" } } #也可返回多個field使用都好分割 GET /test_index/test_type/1?_source=test_field2,test_field1
組件elasticsearch.jar提供了豐富API,不過不利於咱們理解和學習,如今咱們本身來進行封裝。
組件API使用RestClient封裝document查詢接口:
/** * @param index * @param type * @param id * @param fields * 查詢返回字段,可空 * @return * @throws Exception * @Description: * @create date 2019年4月3日下午3:12:40 */ public String document(String index, String type, String id, List<String> fields) throws Exception { Map<String, String> paramsMap = new HashMap<>(); paramsMap.put("pretty", "true"); if (null != fields && fields.size() != 0) { String fieldValue = ""; for (String field : fields) { fieldValue += field + ","; } if (!"".equals(fieldValue)) { paramsMap.put("_source", fieldValue); } } return CommonUtils.toString(es.getRestClient() .performRequest("GET", "/" + index + "/" + type + "/" + id, paramsMap).getEntity().getContent()); }
工程使用,封裝:
public String searchDocument(String index, String type, String id, List<String> fields) { try { return doc.document(index, type, id, fields); } catch (Exception e) { log.error(e.getMessage()); ExceptionLogger.log(e); throw new RuntimeException("ES查詢失敗"); } }
測試用例,代碼以下:
/** * ES交互驗證-查詢、更新等等操做 * * @version * @author 錢丁君-chandler 2019年4月3日上午10:27:28 * @since 1.8 */ @RunWith(SpringRunner.class) @SpringBootTest(classes = Bootstrap.class, webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) public class ESManagerTest { @Autowired private ESBasicManager esBasicManager; @Test public void query() { String result = esBasicManager.searchDocument(ESTagMetadata.INDEX_ALIAS, ESTagMetadata.DOC_TYPE, "188787665220752824", ImmutableList.of("signup_time", "tag_days_no_visit_after_1_order")); System.out.println("----------->" + result); } }
控臺輸出:
----------->{
"_index" : "crm_tag_idx_20181218_708672", "_type" : "crm_tag_type", "_id" : "188787665220752824", "_version" : 1, "found" : true, "_source" : { "signup_time" : "2017-12-24", "tag_days_no_visit_after_1_order" : "339" } }
我只是拋磚引玉,你們能夠自行進行各類操做的封裝,無論對於理解ES的使用,仍是對代碼質量提高都有不少幫助。
最後謝謝你們觀賞
《Elasticsearch詳解》
若是須要給我修改意見的發送郵箱:erghjmncq6643981@163.com資料參考:《可伸縮服務架構》轉發博客,請註明,謝謝。