├── .gitignore └── master_es_no2 ├── 00_dsl_operation.md ├── 01_text_search.md ├── 02_suggester.md ├── 03_improve_query.md ├── 04_distinct.md ├── 05_highlight.md ├── 06_doc_value.md ├── 07_es_case_sensitive ├── 20180308060649363.png ├── README.md ├── es_accumulate ├── 201804_report.md ├── 201805_report.md ├── 201806_report.md ├── 201807_report.md ├── 201808_report.md ├── 201809_report.md ├── 201810_report.md ├── 201811_report.md ├── 201812_report.md ├── 201901_report.md ├── 201902_report.md ├── 201903_report.md ├── 201904_report.md ├── 201905_report.md ├── 201906_report.md ├── 201907_report.md ├── 201908_report.md ├── 201909_report.md ├── 201910_report.md ├── 201911_report.md ├── 201912_report.md ├── 202001_report.md ├── 202002_report.md ├── 202003_report.md ├── 202004_report.md ├── 202005_report.md ├── 202008_report.md ├── 202009_report.md ├── 202010_report.md ├── 202011_report.md ├── 202012_report.md └── jvm.png ├── es_dsl_study ├── 1.ingest_dsl.md ├── 10.split.md ├── 11.aggs_by_composite buckets.md ├── 12.terms_lookup.md ├── 13.update.md ├── 14.join.md ├── 15.multi-match.md ├── 16.aggs.md ├── 2.aggs_having.md ├── 3.aggs_pipeline_bucketscript.md ├── 4.script_field.md ├── 5.fielddata_dsl.md ├── 6.scripting.md ├── 7.analysis.md ├── 8.ngram.md └── 9.template.md └── es_howtodo └── how_to_do_elasticsearch.md /.gitignore/master_es_no2: -------------------------------------------------------------------------------- 1 | 2 | PUT scoring 3 | { 4 | "settings":{ 5 | "number_of_shards":1, 6 | "number_of_replicas":0 7 | } 8 | } 9 | 10 | POST scoring/doc/1 11 | { 12 | "name":"first document" 13 | } 14 | 15 | POST scoring/_search 16 | { 17 | "query":{ 18 | "match":{"name":"document"} 19 | } 20 | } 21 | 22 | POST scoring/_search 23 | { 24 | "explain": true, 25 | "query":{ 26 | "match":{"name":"document"} 27 | } 28 | } 29 | 30 | POST scoring/doc/2 31 | { 32 | "name":"second example document" 33 | } 34 | 35 | PUT clients 36 | POST clients/client/1 37 | { 38 | "id":1, 39 | "name":"Joe" 40 | } 41 | POST clients/client/2 42 | { 43 | "id":2, 44 | "name":"Jane" 45 | } 46 | POST clients/client/3 47 | { 48 | "id":3, 49 | "name":"Jack" 50 | } 51 | 52 | POST clients/client/4 53 | { 54 | "id":4, 55 | "name":"Rob" 56 | } 57 | 58 | POST clients/_search 59 | { 60 | "query":{ 61 | "prefix":{ 62 | "name":"j" 63 | } 64 | } 65 | } 66 | 67 | PUT library 68 | POST library/_mapping/book 69 | { 70 | "book":{ 71 | "properties":{ 72 | "review":{ 73 | "type":"nested", 74 | "properties":{ 75 | "nickname":{"type":"text", 76 | "fields":{ 77 | "keyword":{ 78 | "type":"keyword" 79 | } 80 | }}, 81 | "text":{"type":"text", 82 | "fields":{ 83 | "keyword":{ 84 | "type":"keyword" 85 | } 86 | } 87 | }, 88 | "stars":{"type":"integer" 89 | } 90 | } 91 | } 92 | } 93 | } 94 | } 95 | 96 | POST library/book/_bulk 97 | { "index": {"_index": "library", "_type": "book", "_id": "1"}} 98 | { "title": "All Quiet on the Western Front","otitle": "Im Westen nichts Neues","author": "Erich Maria Remarque","year": 1929,"characters": ["Paul Bumer", "Albert Kropp", "Haie Westhus", "Fredrich Mller", "Stanislaus Katczinsky", "Tjaden"],"tags": ["novel"],"copies": 1, "available": true, "section" : 3} 99 | { "index": {"_index": "library", "_type": "book", "_id": "2"}} 100 | { "title": "Catch-22","author": "Joseph Heller","year": 1961,"characters": ["John Yossarian", "Captain Aardvark", "Chaplain Tappman", "Colonel Cathcart", "Doctor Daneeka"],"tags": ["novel"],"copies": 6, "available" : false, "section" : 1} 101 | { "index": {"_index": "library", "_type": "book", "_id": "3"}} 102 | { "title": "The Complete Sherlock Holmes","author": "Arthur Conan Doyle","year": 1936,"characters": ["Sherlock Holmes","Dr. Watson", "G. Lestrade"],"tags": [],"copies": 0, "available" : false, "section" : 12} 103 | { "index": {"_index": "library", "_type": "book", "_id": "4"}} 104 | { "title": "Crime and Punishment","otitle": "pec ssss","author": "Fyodor Dostoevsky","year": 1886,"characters": ["Raskolnikov", "Sofia Semyonovna Marmeladova"],"tags": [],"copies": 0, "available" : true} 105 | 106 | 107 | POST library/book/5 108 | { 109 | "title":"The Sorows of Young Werther", 110 | "author":"Johann Wolfgang won Goethe", 111 | "avaliable":true, 112 | "characters":["Werther","Lotte","Albert","Fraulein von B"], 113 | "copies":1, 114 | "otitle":"Die Leiden des jungen Werthers", 115 | "section":4, 116 | "tags":["novel", "classics"], 117 | "year":1774, 118 | "review":[ 119 | { 120 | "nickname":"Anna", 121 | "text":"could be good, but not my style", 122 | "stars":15 123 | }] 124 | } 125 | 126 | POST library/book/6 127 | { 128 | "title":"The Peasants", 129 | "author":"Wdyslaw Reymojnt", 130 | "avaliable":true, 131 | "characters":["Boryna", "Jankiel","Jagna Paczesiona"], 132 | "copies":4, 133 | "otitle":"chopi", 134 | "section":4, 135 | "tags":["novel", "polish","classics"], 136 | "year":1904, 137 | "review":[ 138 | { 139 | "nickname":"anonymous", 140 | "text":"awsome book", 141 | "stars":3 142 | }, 143 | { 144 | "nickname":"Jane", 145 | "text":"Great book, but too long", 146 | "stars":4 147 | }, 148 | { 149 | "nickname":"Rick", 150 | "text":"Why bother, when you can find it on the internet", 151 | "stars":32 152 | }] 153 | } 154 | 155 | GET library/_search 156 | { 157 | "query":{ 158 | "match_all": {} 159 | } 160 | } 161 | 162 | POST library/_search 163 | { 164 | "query":{ 165 | "range":{ 166 | "copies": { 167 | "gte": 1, 168 | "lte": 3 169 | } 170 | } 171 | } 172 | } 173 | 174 | POST library/_search 175 | { 176 | "query":{ 177 | "terms": { 178 | "tags": ["novel", "polish", "classics", "criminal", "new"] 179 | } 180 | } 181 | } 182 | 183 | GET library/_search 184 | { 185 | "query":{ 186 | "bool":{ 187 | "must":[ 188 | { 189 | "range":{ 190 | "copies":{"gte" : 1} 191 | } 192 | }], 193 | "should": [ 194 | {"range":{ 195 | "year":{ 196 | "gt":1950 197 | } 198 | }} 199 | ] 200 | } 201 | } 202 | } 203 | 204 | GET library/_search 205 | { 206 | "_source":{ 207 | "includes": [ "_id","_score"] 208 | }, 209 | "query":{ 210 | "dis_max": { 211 | "tie_breaker": 0.0, 212 | "boost": 1.0, 213 | "queries": [ 214 | {"match":{"title":"crime punishment"}}, 215 | {"match":{"characters":"raskolnikov"}}] 216 | } 217 | } 218 | } 219 | 220 | GET library/_search 221 | { 222 | "explain": true, 223 | "_source":{ 224 | "includes": [ "_id","_score"] 225 | }, 226 | "query": 227 | {"match":{"title":"crime punishment"}} 228 | } 229 | 230 | GET library/_mapping 231 | GET library/_search 232 | { 233 | "_source": { 234 | "includes": "tags" 235 | }, 236 | "query":{ 237 | "term":{ 238 | "tags.keyword":"novel" 239 | } 240 | } 241 | } 242 | 243 | GET library/_search 244 | { 245 | "query": { 246 | "common":{ 247 | "title":{ 248 | "query":"the western front", 249 | "cutoff_frequency":0.1, 250 | "low_freq_operator":"and" 251 | } 252 | } 253 | } 254 | } 255 | 256 | GET library/_search 257 | { 258 | "query": { 259 | "bool":{ 260 | "must": [ 261 | {"term":{"title":"western"}}, 262 | {"term":{"title":"front"}} 263 | ], 264 | "should": [ 265 | {"term":{"title":"the"}} 266 | ] 267 | } 268 | } 269 | } 270 | 271 | GET library/_search 272 | { 273 | "query": { 274 | "match_all": {} 275 | } 276 | } 277 | 278 | GET library/_search 279 | { 280 | "query": { 281 | "query_string": { 282 | "query": "+title:Sorows + title:Young +author:\"won Goethe\" - copies:{5 TO *]" 283 | } 284 | } 285 | } 286 | 287 | GET library/_search 288 | { 289 | "query": { 290 | "query_string": { 291 | "default_field":"title", 292 | "query": "Sorows +Young\"" 293 | } 294 | } 295 | } 296 | 297 | GET library/_search 298 | { 299 | "query": { 300 | "simple_query_string": { 301 | "fields":["title"], 302 | "query": "Sorows +Young\"" 303 | } 304 | } 305 | } 306 | 307 | GET library/_search 308 | { 309 | "query": { 310 | "prefix": { 311 | "title": { 312 | "value": "wes" 313 | } 314 | } 315 | } 316 | } 317 | 318 | GET library/_search 319 | { 320 | "query": { 321 | "regexp": { 322 | "characters": "wat..n" 323 | } 324 | } 325 | } 326 | 327 | GET library/_search 328 | { 329 | "query": { 330 | "fuzzy": { 331 | "title": { 332 | "value": "crimea", 333 | "fuzziness":3, 334 | "max_expansions":50 335 | } 336 | } 337 | } 338 | } 339 | 340 | GET library/_search 341 | { 342 | "query":{ 343 | "function_score": { 344 | "query": {"match_all": {}}, 345 | "score_mode": "multiply", 346 | "functions": [ 347 | {"gauss":{ 348 | "year": { 349 | "origin":2014, 350 | "scale": 2014, 351 | "offset": 0, 352 | "decay": 0.5 353 | } 354 | }} 355 | ] 356 | } 357 | } 358 | } 359 | 360 | GET library/_search 361 | { 362 | "query": { 363 | "boosting": { 364 | "positive": { 365 | "match_all": {} 366 | }, 367 | "negative_boost":{ 368 | "term":{ 369 | "available":false 370 | } 371 | } 372 | } 373 | } 374 | } 375 | 376 | GET library/_search 377 | { 378 | "query": { 379 | "boosting" : { 380 | "positive" : { 381 | "match_all": {} 382 | }, 383 | "negative" : { 384 | "term":{ 385 | "available":false 386 | } 387 | }, 388 | "negative_boost" : 0.2 389 | } 390 | } 391 | } 392 | 393 | GET library/_search 394 | { 395 | "query": { 396 | "match_phrase": { 397 | "otitle": "leiden des jungen" 398 | } 399 | } 400 | } 401 | 402 | GET library/_search 403 | { 404 | "query": { 405 | "span_near":{ 406 | "clauses":[ 407 | {"span_near": { 408 | "clauses": [ 409 | {"span_term":{ 410 | "otitle": "die" 411 | }}, 412 | {"span_near": { 413 | "clauses": [ 414 | {"span_term": { 415 | "otitle": "des" 416 | } 417 | }, 418 | { 419 | "span_term": { 420 | "otitle": "jungen" 421 | } 422 | } 423 | ], 424 | "slop":0, 425 | "in_order": true 426 | } 427 | } 428 | ], 429 | "slop": 2, 430 | "in_order": false 431 | } 432 | }, 433 | { 434 | "span_term": { 435 | "otitle": "werthers" 436 | } 437 | } 438 | ], 439 | "slop": 0, 440 | "in_order": true 441 | } 442 | } 443 | } 444 | 445 | GET library/_mapping 446 | POST library/_search 447 | { 448 | "query":{ 449 | "match_all":{} 450 | } 451 | } 452 | 453 | GET library/_search 454 | { 455 | "query": { 456 | "nested": { 457 | "path": "review", 458 | "query": { 459 | "range": { 460 | "review.stars": { 461 | "gte": 3 462 | } 463 | } 464 | } 465 | } 466 | } 467 | } 468 | 469 | 470 | GET library/_search 471 | { 472 | "query": { 473 | "nested": { 474 | "path": "review", 475 | "score_mode": "max", 476 | "query": { 477 | "function_score": { 478 | "query":{"match_all": {}}, 479 | "score_mode":"max", 480 | "boost_mode":"replace", 481 | "field_value_factor":{ 482 | "field":"review.stars", 483 | "factor":1, 484 | "modifier":"none" 485 | } 486 | } 487 | } 488 | } 489 | } 490 | } 491 | -------------------------------------------------------------------------------- /02_suggester.md: -------------------------------------------------------------------------------- 1 | # 1、term_suggester 2 | ``` 3 | POST library/_search 4 | { 5 | "suggest":{ 6 | "first_suggestion":{ 7 | "text":"wordl", 8 | "term":{ 9 | "field":"title" 10 | } 11 | } 12 | } 13 | } 14 | 15 | POST library/_search 16 | { 17 | "suggest": { 18 | "text" : "wordl fyodro cremi", 19 | "my-suggest-1" : { 20 | "term" : { 21 | "field" : "title" 22 | } 23 | }, 24 | "my-suggest-2" : { 25 | "term" : { 26 | "field" : "otitle" 27 | } 28 | }, 29 | "my-suggest-3" : { 30 | "term" : { 31 | "field" : "author" 32 | } 33 | } 34 | } 35 | } 36 | ``` 37 | 38 | # 2、phrase_suggester 39 | ``` 40 | POST library/_search 41 | { 42 | "suggest": { 43 | "my-suggestion": { 44 | "text": "The orows of Yung Werther", 45 | "phrase": { 46 | "field": "title.keyword", 47 | "highlight": { 48 | "pre_tag": "", 49 | "post_tag": "" 50 | } 51 | } 52 | } 53 | } 54 | } 55 | ``` 56 | 57 | # 3、completion suggester 参见Elasitcsearch社区大神讲解 58 | 参考：https://elasticsearch.cn/article/142 59 | 60 | 在ES7.2下实战： 61 | 62 | ``` 63 | PUT /blogs 64 | { 65 | "mappings": { 66 | "properties": { 67 | "body": { 68 | "type": "text" 69 | } 70 | } 71 | } 72 | } 73 | 74 | POST _bulk/?refresh=true 75 | { "index" : { "_index" : "blogs" } } 76 | { "body": "Lucene is cool"} 77 | { "index" : { "_index" : "blogs" } } 78 | { "body": "Elasticsearch builds on top of lucene"} 79 | { "index" : { "_index" : "blogs" } } 80 | { "body": "Elasticsearch rocks"} 81 | { "index" : { "_index" : "blogs" } } 82 | { "body": "Elastic is the company behind ELK stack"} 83 | { "index" : { "_index" : "blogs" } } 84 | { "body": "elk rocks"} 85 | { "index" : { "_index" : "blogs" } } 86 | { "body": "elasticsearch is rock solid"} 87 | 88 | POST _analyze 89 | { 90 | "text": [ 91 | "Lucene is cool", 92 | "Elasticsearch builds on top of lucene", 93 | "Elasticsearch rocks", 94 | "Elastic is the company behind ELK stack", 95 | "elk rocks", 96 | "elasticsearch is rock solid" 97 | ] 98 | } 99 | 100 | POST /blogs/_search 101 | { 102 | "suggest": { 103 | "my-suggestion": { 104 | "text": "lucne rock", 105 | "term": { 106 | "suggest_mode": "missing", 107 | "field": "body" 108 | } 109 | } 110 | } 111 | } 112 | 113 | POST /blogs/_search 114 | { 115 | "suggest": { 116 | "my-suggestion": { 117 | "text": "lucne rock", 118 | "term": { 119 | "suggest_mode": "always", 120 | "field": "body" 121 | } 122 | } 123 | } 124 | } 125 | 126 | POST /blogs/_search 127 | { 128 | "suggest": { 129 | "my-suggestion": { 130 | "text": "lucne and elasticsear rock", 131 | "phrase": { 132 | "field": "body", 133 | "highlight": { 134 | "pre_tag": "", 135 | "post_tag": "" 136 | } 137 | } 138 | } 139 | } 140 | } 141 | 142 | PUT /blogs_completion/ 143 | { 144 | "mappings": { 145 | "properties": { 146 | "body": { 147 | "type": "completion" 148 | } 149 | } 150 | } 151 | } 152 | 153 | POST _bulk/?refresh=true 154 | { "index" : { "_index" : "blogs_completion"} } 155 | { "body": "Lucene is cool"} 156 | { "index" : { "_index" : "blogs_completion"} } 157 | { "body": "Elasticsearch builds on top of lucene"} 158 | { "index" : { "_index" : "blogs_completion" } } 159 | { "body": "Elasticsearch rocks"} 160 | { "index" : { "_index" : "blogs_completion" } } 161 | { "body": "Elastic is the company behind ELK stack"} 162 | { "index" : { "_index" : "blogs_completion" } } 163 | { "body": "the elk stack rocks"} 164 | { "index" : { "_index" : "blogs_completion"} } 165 | { "body": "elasticsearch is rock solid"} 166 | 167 | POST blogs_completion/_search?pretty 168 | { "size": 0, 169 | "suggest": { 170 | "blog-suggest": { 171 | "prefix": "elastic i", 172 | "completion": { 173 | "field": "body" 174 | } 175 | } 176 | } 177 | } 178 | 179 | PUT /blogs_completion_02/ 180 | { 181 | "mappings": { 182 | "properties": { 183 | "body": { 184 | "type": "completion", 185 | "analyzer": "english" 186 | } 187 | } 188 | } 189 | } 190 | 191 | POST blogs_completion_02/_search?pretty 192 | { "size": 0, 193 | "suggest": { 194 | "blog-suggest": { 195 | "prefix": "elastic", 196 | "completion": { 197 | "field": "body" 198 | } 199 | } 200 | } 201 | } 202 | 203 | POST _analyze 204 | { 205 | "analyzer":"english", 206 | "text": "elasticsearch is rock solid" 207 | } 208 | ``` 209 | -------------------------------------------------------------------------------- /03_improve_query.md: -------------------------------------------------------------------------------- 1 | # 1、基础查询 2 | ``` 3 | GET library/_search 4 | { 5 | "_source":{ 6 | "includes":["title"] 7 | }, 8 | "query": { 9 | "match": { 10 | "title":{ 11 | "query": "Crime Punishment", 12 | "operator": "and" 13 | } 14 | } 15 | } 16 | } 17 | ``` 18 | # 2、多字段检索 19 | ``` 20 | GET library/_search 21 | { 22 | "_source":{ 23 | "includes":["title"] 24 | }, 25 | "query": { 26 | "multi_match": { 27 | "query": "Crime Punishment", 28 | "fields": [ 29 | "title^100", 30 | "text^10" 31 | ] 32 | } 33 | } 34 | } 35 | ``` 36 | 37 | # 3、短语检索 38 | ``` 39 | GET library/_search 40 | { 41 | "_source": { 42 | "includes": [ 43 | "title" 44 | ] 45 | }, 46 | "query": { 47 | "bool": { 48 | "must": [ 49 | { 50 | "multi_match": { 51 | "query": "Crime Punishment", 52 | "fields": [ 53 | "title^100", 54 | "text^10" 55 | ] 56 | } 57 | } 58 | ], 59 | "should": [ 60 | { 61 | "match_phrase": { 62 | "title": "crime punishment" 63 | } 64 | }, 65 | { 66 | "match_phrase": { 67 | "author": "crime punishment" 68 | } 69 | } 70 | ] 71 | } 72 | } 73 | } 74 | ``` 75 | 76 | # 4、引入slop设置单词间的最大间隔， 77 | 最大间隔之内的单词可以被认为与查询中的短语匹配。 78 | ``` 79 | GET library/_search 80 | { 81 | "_source": { 82 | "includes": [ 83 | "title" 84 | ] 85 | }, 86 | "query": { 87 | "bool": { 88 | "must": [ 89 | { 90 | "multi_match": { 91 | "query": "Crime Punishment", 92 | "fields": [ 93 | "title^100", 94 | "text^10" 95 | ] 96 | } 97 | } 98 | ], 99 | "should": [ 100 | { 101 | "match_phrase": { 102 | "title": { 103 | "query": "crime punishment", 104 | "slop": 1 105 | } 106 | } 107 | }, 108 | { 109 | "match_phrase": { 110 | "author": { 111 | "query": "crime punishment", 112 | "slop": 1 113 | } 114 | } 115 | } 116 | ] 117 | } 118 | } 119 | } 120 | ``` 121 | 122 | # 5、过滤到垃圾信息——must_not来帮忙 123 | ``` 124 | GET library/_search 125 | { 126 | "_source": { 127 | "includes": [ 128 | "title" 129 | ] 130 | }, 131 | "query": { 132 | "bool": { 133 | "must": [ 134 | { 135 | "multi_match": { 136 | "query": "Crime Punishment", 137 | "fields": [ 138 | "title^100", 139 | "text^10" 140 | ] 141 | } 142 | } 143 | ], 144 | "should": [ 145 | { 146 | "match_phrase": { 147 | "title": { 148 | "query": "crime punishment", 149 | "slop": 1 150 | } 151 | } 152 | }, 153 | { 154 | "match_phrase": { 155 | "author": { 156 | "query": "crime punishment", 157 | "slop": 1 158 | } 159 | } 160 | } 161 | ], 162 | "filter": { 163 | "bool": { 164 | "must_not": [ 165 | { 166 | "term": { 167 | "redirect": "true" 168 | } 169 | }, 170 | { 171 | "term": { 172 | "special": "true" 173 | } 174 | } 175 | ] 176 | } 177 | } 178 | } 179 | } 180 | } 181 | 182 | ``` 183 | # 6、引入boost提升权重 184 | ``` 185 | { 186 | "_source": { 187 | "includes": [ 188 | "title" 189 | ] 190 | }, 191 | "query": { 192 | "function_score": { 193 | "boost": 100, 194 | "query": { 195 | "match_phrase": { 196 | "title": { 197 | "query": "Crime Punishment", 198 | "slop": 1 199 | } 200 | } 201 | } 202 | } 203 | } 204 | } 205 | ``` 206 | 207 | # 7、可纠正拼写错误——借助：minimum_should_match 208 | ``` 209 | GET library/_search 210 | { 211 | "query": { 212 | "query_string": { 213 | "query": "Crime Punishment", 214 | "default_field": "title", 215 | "minimum_should_match": "80%" 216 | } 217 | } 218 | } 219 | ``` 220 | -------------------------------------------------------------------------------- /04_distinct.md: -------------------------------------------------------------------------------- 1 | # 1、新建库表 2 | ``` 3 | PUT books 4 | { 5 | "mappings": { 6 | "_doc": { 7 | "properties": { 8 | "title": { 9 | "type": "text", 10 | "fields": { 11 | "keyword": { 12 | "type": "keyword" 13 | } 14 | } 15 | } 16 | } 17 | } 18 | } 19 | } 20 | ``` 21 | # 2、导入数据 22 | ``` 23 | PUT books/_doc/2 24 | { 25 | "title":"Hadoop权 指南(第4版)+数据算法" 26 | } 27 | 28 | PUT books/_doc/3 29 | { 30 | "title":"Spark与Hadoop大数据分析" 31 | } 32 | 33 | PUT books/_doc/4 34 | { 35 | "title":"Hadoop + Spark 大数据巨量分析与机器" 36 | } 37 | 38 | PUT books/_doc/5 39 | { 40 | "title":"Hadoop大数据开发基础 " 41 | } 42 | 43 | PUT books/_doc/1 44 | { 45 | "title":"hadoop高级数据分析" 46 | } 47 | 48 | PUT books/_doc/6 49 | { 50 | "title":"hadoop高级数据分析" 51 | } 52 | ``` 53 | 54 | # 3、全量检索 55 | ``` 56 | GET books/_search 57 | { 58 | "query": { 59 | "match_all": {} 60 | }, 61 | "sort":{ 62 | "_doc":"desc" 63 | } 64 | } 65 | ``` 66 | 67 | # 4、折叠检索（类似去重效果） 68 | ``` 69 | GET books/_search 70 | { 71 | "query": { 72 | "match_all":{} 73 | }, 74 | "collapse": { 75 | "field": "title.keyword" 76 | } 77 | } 78 | ``` 79 | 80 | # 5、统计去重后的计数 81 | ``` 82 | GET books/_search 83 | { 84 | "size":0, 85 | "aggs" : { 86 | "books_count" : { 87 | "cardinality" : { 88 | "field" : "title.keyword" 89 | } 90 | } 91 | } 92 | } 93 | ``` 94 | 95 | # 6、全量检索结果 96 | ``` 97 | GET books/_count 98 | { 99 | "query":{ 100 | "match_all":{} 101 | } 102 | } 103 | ``` 104 | 105 | # 7、去重后的检索结果（比collapse重叠复杂） 106 | ``` 107 | GET books/_search 108 | { 109 | "query": { 110 | "match_all": {} 111 | }, 112 | "aggs": { 113 | "type": { 114 | "terms": { 115 | "field": "title.keyword", 116 | "size": 10 117 | }, 118 | "aggs": { 119 | "title_top": { 120 | "top_hits": { 121 | "_source": { 122 | "includes": ["title"] 123 | }, 124 | "sort": [ 125 | { 126 | "title.keyword": { 127 | "order": "desc" 128 | } 129 | } 130 | ], 131 | "size":1 132 | } 133 | } 134 | } 135 | } 136 | }, 137 | "size": 0 138 | } 139 | ``` 140 | 141 | # 7、报错提示 142 | ``` 143 | { 144 | "error": { 145 | "root_cause": [ 146 | { 147 | "type": "search_context_exception", 148 | "reason": "unknown type for collapse field `title`, only keywords and numbers are accepted" 149 | } 150 | ], 151 | "type": "search_phase_execution_exception", 152 | "reason": "all shards failed", 153 | "phase": "query", 154 | "grouped": true, 155 | "failed_shards": [ 156 | { 157 | "shard": 0, 158 | "index": "books", 159 | "node": "ikKuXkFvRc-qFCqG99smGg", 160 | "reason": { 161 | "type": "search_context_exception", 162 | "reason": "unknown type for collapse field `title`, only keywords and numbers are accepted" 163 | } 164 | } 165 | ] 166 | }, 167 | "status": 500 168 | } 169 | ``` 170 | -------------------------------------------------------------------------------- /05_highlight.md: -------------------------------------------------------------------------------- 1 | 2 | # 高亮处理 3 | 4 | # 1、定义索引 5 | 6 | 7 | ``` 8 | PUT books 9 | { 10 | "mappings": { 11 | "_doc": { 12 | "properties": { 13 | "title": { 14 | "type": "text", 15 | "fields": { 16 | "keyword": { 17 | "type": "keyword" 18 | } 19 | } 20 | } 21 | } 22 | } 23 | } 24 | } 25 | ``` 26 | 27 | # 2、插入数据 28 | 29 | ``` 30 | PUT books/_doc/2 31 | { 32 | "title":"Hadoop权 指南(第4版)+数据算法" 33 | } 34 | 35 | PUT books/_doc/3 36 | { 37 | "title":"Spark与Hadoop大数据分析" 38 | } 39 | 40 | PUT books/_doc/4 41 | { 42 | "title":"Hadoop + Spark 大数据巨量分析与机器" 43 | } 44 | 45 | PUT books/_doc/5 46 | { 47 | "title":"Hadoop大数据开发基础 " 48 | } 49 | 50 | PUT books/_doc/1 51 | { 52 | "title":"hadoop高级数据分析" 53 | } 54 | 55 | 56 | 57 | PUT books/_doc/6 58 | { 59 | "title":"hadoop高级数据分析" 60 | } 61 | 62 | PUT books/_doc/111 63 | { 64 | "title":"高级软卧是旅客列车席别中的一种，每个包厢拥有两名旅客（有部分包厢为单人间或四人间），一般来说高级软卧的型号都是19系列(如19A、19K、19T)，也有少数为18系列和24系列。包厢的另外一侧是一个沙发。配置相应的设施，干净舒适。高级软卧是我国列车席别第二高级的，票价也是第二贵的，多被编组于动卧列车（卧铺动车组）和国际列车。新型卧铺动车组的软卧采用纵向卧铺等结构。附：我国列车最高级的席位是高速动车组的商务座。目前高级软卧最普遍的出现在动卧列车上，车型为CRH1E型高级软卧车厢也出现在普通列车内，车型为RW19（RW为软卧的拼音，RW19系列为包厢车，高级软卧）RW19T、RW19K、RW25G（有三种涂装：RW19T通常为白色与藏蓝色相间涂装，挂在特快’直达列车上；RW25G为红色涂装，通常挂在快速列车上，RW19K为蓝色涂装（与25K相同）通常挂在特快旅客列车上，进藏列车为绿色涂装）、RW19A、RW19。多见于国际列车上。RW19K产品用途及特点RW19K高级软卧车是南车四方机车车辆股份有限公司为适应京沪RW19K型RW19K型(6张) 线高档旅客列车的要求，按《京沪线高档客车技术条件》设计制造的新型高档客车。该车中部两端各设1个四人软卧包间，中间设有6个带独立卫生间的二人包间（定员20人）。车辆走行部采用SW-160型转向架，F8型电空制动装置。采用车顶单元式空调机组，包间内采用隐藏式送风，设有旅客操纵的风量调节开关。包间内每个铺位设有1台.4液晶显示器，乘客可用耳机收听和收视列车播放的音、视频节目。此外，各包间与乘务员室之间设有专线电话，车上公共区域播放背景音乐并设有旅客信息显示系统。该型客车使用寿命30年，厂修期7.5年，在15年内车体钢结构无须挖补或截换。设计图纸编号为SFK218。该型客车具有安全、快速、平稳、豪华、舒适等特点" 65 | } 66 | ``` 67 | 68 | # 3、高亮显示 69 | 70 | ``` 71 | GET books/_search 72 | { 73 | "query":{ 74 | "match": { 75 | "title": "高级" 76 | } 77 | }, 78 | 79 | "highlight": { 80 | "pre_tags": [ 81 | "" 82 | ], 83 | "post_tags": [ 84 | "" 85 | ], 86 | "fields": { 87 | "title": { 88 | "number_of_fragments": 0, 89 | "fragment_size": 10 90 | } 91 | } 92 | } 93 | } 94 | ``` 95 | 96 | # 4、返回结果 97 | 98 | 主要制约参数： 99 | 100 | 1、如果 "number_of_fragments": 0, 101 | 全字段高亮返回。 102 | 103 | 如果不要分片段返回，设置为0即可。 104 | 105 | 2、如果 "number_of_fragments": 非零, 106 | 返回的分片段数目 107 | 108 | 3、 109 | "fragment_size": 100 110 | 每个高亮分段的字节数。 111 | 112 | 113 | 114 | 115 | 116 | 117 | -------------------------------------------------------------------------------- /06_doc_value.md: -------------------------------------------------------------------------------- 1 | # Elasticsearch index_time 解读 2 | 3 | ## 1、fielddata官网原文 4 | https://www.elastic.co/guide/en/elasticsearch/reference/current/fielddata.html 5 | 6 | Most fields are indexed by default, which makes them searchable. Sorting, aggregations, and accessing field values in scripts, however, requires a different access pattern from search. 7 | 8 | Search needs to answer the question "Which documents contain this term?", while sorting and aggregations need to answer a different question: "What is the value of this field for thisdocument?". 9 | 10 | Most fields can use index-time, on-disk doc_values for this data access pattern, but text fields do not support doc_values. 11 | Instead, text fields use a query-time in-memory data structure called fielddata. This data structure is built on demand the first time that a field is used for aggregations, sorting, or in a script. It is built by reading the entire inverted index for each segment from disk, inverting the term ↔︎ document relationship, and storing the result in memory, in the JVM heap. 12 | 13 | 正确的翻译参考： 14 | 15 | 索引时字段层权重提升（Index-Time Field-Level Boosting） 16 | 17 | 字段是可以被搜索的名值对，不同的事件可能拥有不同的字段。Splunk支持索引时（index time）和搜索时（search time）的字段抽取（fields extraction） 18 | 19 | 所以：index time 翻译为： 索引时。 20 | 21 | ## 2、doc_value 引申解读 22 | 参考：https://www.elastic.co/guide/en/elasticsearch/reference/6.2/modules-fielddata.html 23 | 24 | The field data cache is used mainly when sorting on or computing aggregations on a field. It loads all the field values to memory in order to provide fast document based access to those values. The field data cache can be expensive to build for a field, so its recommended to have enough memory to allocate it, and to keep it loaded. 25 | 26 | The amount of memory used for the field data cache can be controlled using indices.fielddata.cache.size. Note: reloading the field data which does not fit into your cache will be expensive and perform poorly. 27 | 28 | indices.fielddata.cache.size 29 | The max size of the field data cache, eg 30% of node heap space, or an absolute value, eg 12GB. Defaults to unbounded. Also see Field data circuit breakeredit. 30 | 31 | These are static settings which must be configured on every data node in the cluster. 32 | 33 | 引申解读2： 34 | https://www.elastic.co/guide/en/elasticsearch/reference/6.2/doc-values.html 35 | 36 | Most fields are indexed by default, which makes them searchable. The inverted index allows queries to look up the search term in unique sorted list of terms, and from that immediately have access to the list of documents that contain the term. 37 | 38 | Sorting, aggregations, and access to field values in scripts requires a different data access pattern. Instead of looking up the term and finding documents, we need to be able to look up the document and find the terms that it has in a field. 39 | 40 | Doc values are the on-disk data structure, built at document index time, which makes this data access pattern possible. They store the same values as the _source but in a column-oriented fashion that is way more efficient for sorting and aggregations. Doc values are supported on almost all field types, with the notable exception of analyzed string fields. 41 | 42 | 43 | All fields which support doc values have them enabled by default. If you are sure that you don’t need to sort or aggregate on a field, or access the field value from a script, you can disable doc values in order to save disk space: 44 | ``` 45 | PUT my_index 46 | { 47 | "mappings": { 48 | "_doc": { 49 | "properties": { 50 | "status_code": { 51 | "type": "keyword" 52 | }, 53 | "session_id": { 54 | "type": "keyword", 55 | "doc_values": false 56 | } 57 | } 58 | } 59 | } 60 | } 61 | ``` 62 | The status_code field has doc_values enabled by default. 63 | The session_id has doc_values disabled, but can still be queried. 64 | 65 | ## 小结： 66 | 1、doc_values是存储在磁盘的数据结构，在文档建立索引的时候创建。 67 | 68 | 2、对比：field_data缓存主要用于在字段上进行排序或计算聚合。 它将所有字段值加载到内存中，以便为这些值提供基于文档的快速访问。 69 | -------------------------------------------------------------------------------- /07_es_case_sensitive: -------------------------------------------------------------------------------- 1 | # ES区分大小写 2 | 3 | ## 1、创建索引 4 | 5 | 6 | ``` 7 | DELETE indexx 8 | PUT indexx 9 | { 10 | "settings": { 11 | "analysis": { 12 | "normalizer": { 13 | "my_normalizer": { 14 | "type": "custom", 15 | "filter": ["lowercase", "asciifolding"] 16 | } 17 | } 18 | } 19 | }, 20 | "mappings": { 21 | "type": { 22 | "properties": { 23 | "foo": { 24 | "type": "keyword", 25 | "normalizer": "my_normalizer" 26 | } 27 | } 28 | } 29 | } 30 | } 31 | ``` 32 | 33 | ## 2、插入数据 34 | ``` 35 | POST indexx/type/1 36 | { 37 | "foo":"Meet" 38 | } 39 | 40 | POST indexx/type/2 41 | { 42 | "foo":"meet" 43 | } 44 | 45 | POST indexx/type/3 46 | { 47 | "foo":"MEET" 48 | } 49 | ``` 50 | 51 | ## 3、检索验证 52 | ``` 53 | POST indexx/type/_search 54 | { 55 | "query":{ 56 | "wildcard":{ 57 | "foo":"*mee*" 58 | } 59 | } 60 | } 61 | ``` 62 | 63 | ## 4、聚合验证 64 | ``` 65 | POST indexx/_search 66 | { 67 | "size":0, 68 | "aggs": { 69 | "foo_aggs": { 70 | "terms": { 71 | "field": "foo" 72 | } 73 | } 74 | } 75 | } 76 | ``` 77 | -------------------------------------------------------------------------------- /20180308060649363.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mingyitianxia/deep_elasticsearch/3ca24364e3f3a784b5ebe030bd3fb63cc83f0d2d/20180308060649363.png -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # deep_elasticsearch 2 | deep_elasticsearch for learning! 3 | 4 | # 1、deep_elasticsearch 内容 5 | - 博客、公众号的补充，更多实战DSL； 6 | - 更多ELK Stack、搜索引擎经典书籍中的实战DSL及其他源码； 7 | - Elasticsearch中文社区及其他论坛搜集的核心干货，以月为单位总结，已连续更新大于18个月+。 8 | 9 | 10 | 11 | # 2、更多ELK Stack实战干货 12 | 13 | 【1】微信公众号：铭毅天下 14 | 15 | 【2】博客: https://elastic.blog.csdn.net/ 16 | 17 | 【3】加入死磕Elasticsearch知识星球（中国通过Elastic认证工程师人数最多的圈子），和硅谷、BAT一线大佬更短时间更快习得更多干货！http://t.cn/RmwM3N9 18 | 19 | -------------------------------------------------------------------------------- /es_accumulate/201809_report.md: -------------------------------------------------------------------------------- 1 | # 0、Logstash最佳实践——电子书 2 | Logstash 最佳实践——https://doc.yonyoucloud.com/doc/logstash-best-practice-cn/index.html 3 | 4 | # 1、索引中有一类型为string的字段str，有值6、30、50，使用range查询大于5就只查出6这一个值。哪位大神有解决办法？ 5 | 6 | https://elasticsearch.cn/question/5181 7 | 8 | 【回复】如果是字符，看的是字符的，第一个字符和第一个字符比较，第一个字符排完再排第二个字符。 9 | 30和50的第一个字符是3和5，都不比5大。 10 | 不足位就补0。5=>05。 11 | 最后 Mapping 里面改字段类型和重建才是王道。 12 | 13 | # 2、path.data 配置了多个路径后 es的存储和获取机制是什么 14 | 15 | path.data 是可以配置多个路径(用逗号隔开)，以下的问题的前提是配置的路径分别对应到一块磁盘。 16 | 1、如果配置多个路径，es存储索引的时候 是一个磁盘满了 再去存另外一个吗？ 17 | 2、如果一个索引跨了两个磁盘，搜索的时候，es需要去两块磁盘上分别做搜索，然后结果做merge吗？ 这样效率是不是还没有一块磁盘来的好？ 18 | 19 | 【回复】：1、1.以shard为单位存储在单个磁盘上，多个shard会分散，不是等满了再用 20 | 2.查询的时候是shard并行检索的，所以磁盘分开的话，io会分散到各个磁盘上，效率肯定要高一些，查询结果的merge都是在内存 21 | 【源码解读回复】最近也遇到第一个问题。查找网上所有资料均未给出合适的答案，无奈只好硬着头皮去看源码。 22 | 好在终于把这个原理理清楚了，来跟大家一起分享一下。 23 | 24 | ## ES多盘shard分配原理 25 | 26 | https://elasticsearch.cn/question/753 27 | 28 | 假设现在单机环境中有两块磁盘，es的配置文件elasticsearch.yml中的path.data：/index/data,/data2/index/data 29 | 30 | 配置了两块盘，对应了两个路径。那么我现在要创建hrecord1索引的2个主shard分配原理如下： 31 | 32 | 首先会创建shard1（我估计ES会优先创建shard编号大的shard，但是影响不大），创建shard1的时候会找出两个路径对应的磁盘空间大的那个盘， 33 | 然后将shard1放到那个路径下。 34 | 35 | 创建shard0的时候，会将/index和/data2磁盘的剩余可用空间相加，然后将这个总和乘以百分之五 36 | 将前面创建shard1的磁盘空间减去这个百分之五的值，然后再将这个差值与/data2磁盘剩余空间进行比较，找出磁盘空间大的，然后把shard0放到那个大的磁盘空间上。 37 | 38 | 说白了，*这个百分之五的空间是ES为那个创建的shard1设置的预留空间*吧。 39 | 有错误的地方也欢迎大家指出，一起交流哈！ 40 | 41 | # 3、elasticsearch suggest 使用中文如何实现? 42 | 43 | https://elasticsearch.cn/question/786 44 | 45 | 现需要实现一个拼写检查错误后给出提示建议的功能，也就是did you mean，看百度，还有豆瓣的搜索上都带有此项， 46 | 比如输入拼音liudehua，会问你你是否要找的是刘德华，另外输入天伤人间，提示您是否要找的是天上人间， 47 | 诸如此类，想请问使用es如何实现这种功能，官网说使用suggester，但是我感觉对中文没有任何提示效果， 48 | 哪位高手能够贴点代码或者给出点思路，感谢了 49 | 50 | 【回复】：suggest 里面配上中文的 analyzer 也可以，另外自己通过构建查询来返回提示结果也是一种做法 51 | 52 | # 4、logstash 导入 elasticsearch，elasticsearch-head集群概览会显示Unassigned 53 | 【最通俗的回复】这个是正常的，一个节点没有办法产生多余的一份副本，相同的鸡蛋是不会分配在同一个篮子里的。 54 | 【wood】ES的主副分片不能分配到同一个结点上，否则就失去了高可用的意义。 你只有一个结点，所以replica设置了也没用， 改为0吧. 55 | 56 | # 5、doc_values禁用索引大小不减反增 57 | 58 | https://elasticsearch.cn/question/5096 59 | 60 | 【回复1】你看的索引变大是怎么看的？如果是看磁盘里面文件夹的大小，那么6.3版本的话要考虑 translog 的大小 61 | 【回复2】doc_values禁用后，理论上是会减少索引大小的，可以关注下shard里文件后缀为.dvd的占比是否变少了。 62 | 最好像二楼说的，写同样的数据对比，写入停止后，可以force_merge成一个shard对比下 63 | 64 | # 6、elasticsearch多次查询得分不一致 65 | 66 | 67 | 集群有两个节点，有一个索引存储在一个完整的分片上，另一个节点上存储的是备份分片，发现多次请求相同的参数返回的同一个文档得分不一致， 68 | 网上说索引在多个分片上的时候会有计算得分不同的情况，我的索引都在一个分片上，难道主备分片的得分计算也不太一样吗？ 69 | 70 | 【回复1】：参与最后统分的不是全集，而是每个 shard 取的 topN，这就可能造成一定偶然性。有惊喜 71 | 【回复2】：可以借助perference参数解决 72 | 73 | # 7、elasticsearch内部会对dsl进行优化吗？ 74 | 75 | https://elasticsearch.cn/question/4717 76 | 77 | ES底层会做优化，并且某些Query会被rewrite。 比方terms实际上内部被重写成了bool should(term)，所以查询结果完全一样， 78 | 同时执行性能上没有几乎没有差别。 79 | 只要在Query内部加一个"profile": true参数，就能看到Query被解析和执行的过程。 80 | 81 | # 8、hive的外表和es数据相连，能不能和内表进行联合查询？ 82 | hive内表t1 83 | hive外表t2，这是映射es的某个type 84 | 为什么在hive里面把这两个表进行联合查询总是报错: 85 | Caused by: java.lang.ClassNotFoundException: org.elasticsearch.hadoop.hive.EsHiveInputFormat 86 | 87 | 有没有大佬帮忙解答一下，困了好久了！！！！ 88 | 89 | 【回复】不是提示找不到EsHiveInputFormat这个类了麽。您是在hive客户端运行的还是在代码中加载驱动执行sql的？检查下hive的lib目录是否有相关hadoop-es依赖，代码工程中pom文件是否依赖了hadoop-es 90 | 91 | # 9、【多表同步】Elasticsearch jdbc同步数据 92 | 93 | 我用的是jdbc同步mysql数据，应有多张表（25）都要导入到es中，请问该怎么弄，单张表的会了，多张表的还请教一下啊 94 | 95 | 【回复】es-jdbc多张表的话，没法在一个进程中进行多表导入，这个算是它的设计缺陷： 96 | https://github.com/jprante/ela ... s/746 97 | 98 | 如果有这方面的需求的话，大概只能想想别的办法了，比如在sql里做union什么的 99 | 有精力的话可以用binlog来做数据流，参见我以前的回答，嗯。 100 | 101 | # 10、es聚合数据丢失 102 | 103 | https://elasticsearch.cn/question/5225 104 | 105 | es使用时间直方图聚合的时候，求count时数据缺少，sum_other_doc_count是100多，然后调大聚合的返回size就可以了， 106 | 想问一下这个问题的最终解决方法是啥，不可能每次都得预判这个size吧。 107 | 108 | 【回复】在没有得到 size 是多少的情况下，保守一点比较好，不要一下子设置很大的 size。 109 | 110 | 时间直方图聚合的功能没使用过， 不过，看起来说的应该是ES普通的聚合查询因为是先分布式查询每个shard的top size个值后， 111 | 在协调节点再重新汇总选择top size个结果集返回。这个过程导致， 当size值小于term的基数时，结果是近似的。 112 | 6.2后好像出了一个 Composite aggregation获取所有term的可能（没有具体用过）。 113 | 114 | # 11、elasticsearch 重启后数据平衡问题 115 | 116 | https://elasticsearch.cn/question/5376 117 | 118 | 【wood大叔】： 119 | 问题在于集群的shard数量过多了。 在集群出现结点脱离，重新加入的时候，master需要重新对unassinged的shard做allocation的路由计算， 120 | 这个过程需要便利所有unassigned的shard，并发请求到所有结点，询问是否有关于此shard的信息，还需要更新集群的状态数据， 121 | 并且下发给所有结点。 当shard太多的时候，这个过程会很慢，并且可能会阻塞读取结点状态信息的请求， 122 | 以至于xpack都无法获取到监控数据。 123 | 124 | 如果你可以访问集群9200端口的话，在结点脱离期间，用GET /_cat/pending_tasks应该会看到非常多的任务等待处理。 125 | master在做集群状态数据更新的时候，是单线程的，如果有很多状态更新，会非常非常慢。 126 | 127 | 你这个集群只有几百GB的数据，但是却有3万多shard的时候，说明有太多的小shard存在。 128 | 这个会导致集群状态数据很多，遇到故障恢复会非常慢，需要考虑合理划分索引和shard数量，避免过多小shard存在。 129 | 130 | 个人经验，*一个集群的shard总数超过1万个的时候，故障后的状态恢复就比较慢了。* 131 | 132 | # 12、range字符串查询性能问题 133 | https://elasticsearch.cn/question/5353 134 | 135 | 目前单位在查询的时候发现性能下降了好多， 136 | 137 | ``` 138 | {"query": 139 | {"bool": 140 | {"must": 141 | [{"bool": 142 | {"should": 143 | [{"range": 144 | {"mo_time":{"from":"20180919000000","to":"20180920003000"}}}]}}, 145 | {"bool": 146 | {"should": 147 | [{"range": 148 | {"msg_flag":{"gte":"00","lte":"ff"}}}]}}]}}, 149 | "_source":["mo_time","msg_idx"]} 150 | ``` 151 | 152 | 上面加粗的msg_flah行就是导致性能下降的查询条件， 153 | 不知道各位在字符串range的时候有什么调优的办法？不胜感激！~ 154 | 155 | 【wood大叔】 156 | 字符串做 range查询需要先找出满足查询条件的字符串，然后变成所有这些字符串的terms查询。 157 | 当满足条件的字符串很多的时候，需要合并的倒排列表会非常多，慢是显而易见的。 158 | 159 | 看起来你这些字符串实质是代表的16进制数值？ 如果是的话，你可以这么优化： 160 | 在数据写入之前，在应用端将该字段内容转换为对应的整形数值，然后在mapping里定义为数值类型， 161 | 如short,integer或者long， range查询速度会有很大提升。 162 | 163 | 164 | 165 | 这个优化的前提是ES版本必须是5.0以上的，最好是5.4+。 166 | 167 | # 13、es6.4版本相较于es5.4版本查询性能上的优化有什么改变吗？ 168 | 169 | https://elasticsearch.cn/question/5329 170 | 171 | 大的方面，6相较于5版本查询性能上并没有能察觉的改变， 但是如果你的索引存在字段稀疏的问题，存储效率会提升，相对的因为cache利用效率更高， 172 | 集群整体查询吞吐量也可以得到提升。 173 | 174 | 另外6引入了index sorting的特性，对于经常查询和排序的字段，做索引阶段的预先排序，可以通过牺牲一点写入的吞吐量，换来查询阶段速度的较大提升。 175 | 主要是因为排序过的索引字段，压缩率更高，可能占用的磁盘空间更小，读取速度更快； 176 | 对于排过序的字段做搜索和排序，收集文档阶段可以避免访问所有文档，提早结束查询(Early Termination of Search Request)， 177 | 搜索响应速度可以得到很大提升。 178 | 179 | # 14、两个字段-组合聚合脚本请教 180 | ``` 181 | 182 | 查询语句如下 183 | { 184 | "size": 0, 185 | "query": { 186 | "range": { 187 | "datatime": { 188 | "gte": "now-7d", 189 | "lte": "now" 190 | } 191 | } 192 | }, 193 | "aggs": { 194 | "group_by": { 195 | "terms": { 196 | "script": { 197 | "lang": "painless", 198 | "source":"doc['datatype.keyword'].value + ' ' doc['uname.keyword'].value" 199 | }, 200 | "size": 50 201 | } 202 | } 203 | } 204 | } 205 | ``` 206 | 207 | 208 | 【回复】多字段的terms聚合，也可以利用composite aggregation来实现——不过5.X版本还没有这个聚合 209 | 210 | https://elasticsearch.cn/question/5293 211 | 212 | 【回复1】这个报错主要是防止短时间过多的script compile消耗过多资源，影响集群性能。 不过你范例里给的script应该只需要compile一次，抛这个错误应该是有其他script引起过多的compile吧。 213 | 214 | 通过参数调整提高compile的上限需要谨慎，如果是存在太多的动态script， 频繁的compile可能带来太多压力。 215 | 216 | 最好搞清楚为啥短时间会有这么多的script需要compile，是否有script的参数是生成查询的时候动态传入的？ 217 | 218 | 如果是有参数动态传入，需要将动态部分放到params里去，保证script本身不会随着查询不同而变化，这样只会第一次执行的时候compile一次缓存起来。 219 | 220 | 【回复2】 221 | 看你的意思貌似是希望实现多字段 term 聚合，推荐两种方法： 222 | 1. 同时对多个字段进行 term 聚合，然后编写程序将各个字段的聚合结果进行合并； 223 | 2. 使用 copy_to 属性，将多个字段合并到一个字段，然后针对这个字段进行 term 聚合。 224 | 225 | # 15、match 查询设置 operator为and时，minumum_should_match 是否就没用了？ 226 | 227 | 【回复】理解正确，operator为OR的时候，minumum_should_match才起作用。 228 | 229 | # 16、logstash与kafka topic可以使用变量吗？ 230 | 231 | https://elasticsearch.cn/question/5231 232 | 233 | 【回复】如果是一次消费多个 topic，完全可以写数组啊 234 | https://www.elastic.co/guide/en/logstash/current/plugins-inputs-kafka.html#plugins-inputs-kafka-topics 235 | 236 | 铭毅天下公众号整理 237 | 打造Elasticsearch基础、进阶、实战第一公众号！ 238 | 2018-10-06 239 | -------------------------------------------------------------------------------- /es_accumulate/201811_report.md: -------------------------------------------------------------------------------- 1 | # 1、聚合如何优化？ 2 | 3 | https://elasticsearch.cn/question/6323 4 | 5 | 【回复】 6 | 7 | Agg1 推荐添加上 "collect_mode" : "breadth_first" 表示广度优先 8 | Agg2 添加上 "min_doc_count": 10 限制最小文档个数，这样就可以去掉 orderCount 这个聚合了 9 | 10 | 11 | 这个聚合最大的问题是agg2的size设置得很大，估计keyword5字段的基数非常高，却期望返回所有聚合结果。 12 | 如果该字段基数真的有上亿，加上第一层聚合还有24的size，组合产生的buckets数量可能在数亿 至数十亿的量级，计算产生的内存压力也非常大，速度很难快起来。 13 | 14 | 采用@rochy 的建议，aggs2添加"min_doc_count":10这个设置，应该会大大减少buckets的数量。 15 | 要注意的是，如果count>10的buckets数量依然很大， 聚合的速度还是快不起来。 返回海量buckets的内存开销无法避免， 16 | 并且因为消耗内存过多，容易给结点带来很大的GC压力，甚至OOM。 如果单次聚合取回结果困难，可以考虑将聚合分成多个批次分别取回。 17 | 18 | # 2、【性能】单次查询时间几十ms,并发数提高的情况下，查询速度如何提升 19 | 集群状态：3个EsMaster安装在三台机器节点上。 20 | 另外两台机器：分片安装了5个EsNode，每个实例内存均为25G，机器内存256G 21 | ES 6.1.3版本 22 | 23 | 目前将数据存储在HBASE，将rowkey信息存储在ES中 24 | 25 | 查询单个索引，4亿条数据，30shard，单次查询时间在几十ms内 26 | 27 | 并发3000时速度能稳定在1s内 28 | 29 | 并发6000时查询速度2-3S，查询的过程中堆内存使用率正常 30 | 31 | 对于这种高并发的查询场景有没有优化的空间和思路，还有如何判断查询是否已经到达瓶颈状态、、 32 | 33 | 【回复】 34 | 35 | 如果是追求极致的搜索响应速度和搜索并发量， 不应该做单机上的多实例部署，单个ES实例足够利用所有的硬件资源了。 36 | 37 | 你只有两台机器用作数据结点，所以初步有以下建议: 38 | 1. 每台机器只安装一个ES node 39 | 2. 适当`减少索引的分片数量`，4亿数据，30个shard有些多了，搜索合并阶段的负载可能过重，减少到10个shard甚至4个shard，对比测试一下。 40 | 41 | 判断是否达到瓶颈，首先要监控search线程池的活动状况，queue是否一直很高，reject是否很高。 42 | 然后配合jvm gc情况，系统基础指标，cpu , io使用情况，判断瓶颈在那里。 43 | 44 | # 3、es6.x如何获取所有的聚合结果 45 | 46 | 47 | es2.x版本中，在聚合查询时，通过设置setSize(0)就可以获取所有的聚合结果， 48 | 但是在6.x版本好像去掉了这个功能，请问大神我现在需要通过聚合来获取所有的聚合结果，如何实现呢？ 49 | 50 | ES 2.X 设置为 0 等效于设置为 Integer.MAX_VALUE； 51 | 你想获取全部就设置 size 为 Integer.MAX_VALUE 即可 52 | 53 | 性能问题，铭毅不建议这么操作。 54 | 55 | # 4、elasticsearch 指定缺省的分析器 56 | 57 | https://elasticsearch.cn/question/6310 58 | 59 | 60 | ``` 61 | { 62 | "settings": { 63 | "analysis": { 64 | "analyzer": { 65 | "default": { 66 | "type": "ik_max_word", 67 | "tokenizer": "ik_max_word" 68 | } 69 | } 70 | } 71 | } 72 | } 73 | ``` 74 | 75 | # 5、 elasticsearch去除相似度较高的数据 76 | 77 | https://elasticsearch.cn/question/6305 78 | 79 | 假设有这样一组数据 80 | title:1-6月份房地产市场运行情况 81 | title:1-7月份房地产市场运行情况 82 | title:1-10月份房地产市场运行情况 83 | 标题非常类似的数据,只显示一条 84 | 85 | 【方案】 86 | 冗余文档去重，在入索引库前做，不然在召回后的去重不仅难以控制召回集里冗余文档的数量，重排前的去冗余都会非常耗时。 87 | 业务层面必然会碰到的问题，我的经验是文档入库前```spark算文档的simhash```，建立一个冗余库， 88 | 业务文档索引库只存在一篇“原创”文档，通过UI端提供相似文档按钮召回冗余库里的相似文档即可。 89 | 90 | 思路2： 91 | 92 | 去除相似度高的应该在数据录入的时候进行处理 93 | 你现在的需求就造成无法定义相似度高， 94 | 此外相似度高的显示那一条数据呢？ 95 | 96 | 你这个最好是使用 ES 查询，然后自己程序里面进行判断 97 | 相似度你可以使用 编辑距离、余弦距离等方式来进行判定。 98 | 99 | # 6、logstash采集ftp服务器上的文件 100 | https://elasticsearch.cn/question/6316 101 | 102 | 貌似没有对应的插件 103 | 104 | 有一个技巧你可以了解一下 105 | ``` 106 | exec { 107 | codec => plain { } 108 | command => "curl ftp://server/logs.log" 109 | interval => 3000} 110 | } 111 | ``` 112 | 113 | # 7、ES排序问题 114 | 115 | 数据中某一字段score,若score是大于0的数据按照这个字段排序，等于0的数据之间用ES自带的匹配度进行排序 116 | 117 | 使用 function_score_query 118 | 119 | ``` 120 | GET /_search 121 | { 122 | "query": { 123 | "function_score": { 124 | "query": { 125 | "match": { "message": "elasticsearch" } 126 | }, 127 | "script_score" : { 128 | "script" : { 129 | "source": "if(doc['score'].value > 0){return doc['score'].value;} else{return _score;}" 130 | } 131 | }, 132 | "boost_mode": "replace" 133 | } 134 | } 135 | } 136 | ``` 137 | 138 | # 8、es节点停止只能杀进程吗？ 139 | 140 | supervisior推荐阅读：https://mp.weixin.qq.com/s?__biz=MzI2NDY1MTA3OQ==&mid=2247484103&idx=1&sn=69a24c212798f41c583f64b12ab55edc&chksm=eaa82aefdddfa3f986866f1696120dde39f98685f64e187e910dd91c2e449d2ed962d0c90f33&scene=4&subscene=126&ascene=0&devicetype=android-27&version=26070338&nettype=WIFI&abtest_cookie=BQABAAoACwANABMAFAAFACOXHgBZmR4AhZkeAIqZHgCNmR4AAAA%3D&lang=zh_CN&pass_ticket=HFYJsqSrzWQ%2BkdHN9CzpwKYmQ0EJEUi83vMHq%2BM66bk8BzHzEdfrLgTI3fvwI2Gm&wx_header=1 141 | 好处，可以可视化监控 自动重启 邮件预警 142 | 143 | # 9、ES 如何提高检索效率 144 | 145 | 场景： 模糊查询 单数字或字母时效率非常低，接口已经明显的出现响应过慢的情况。 146 | 请大神指教如何提高效率 147 | 148 | 该问题已经解释过方案，按照方法进行实施即可 149 | 150 | 使用ngram分词器，设置 min 和 max 都为1， 151 | 这样例如：123a，就会被分词为 1/2/3/a， 152 | 你搜索的时候使用 matchPhraseQuery 搜索即可 153 | 154 | # 10、reindex时能不能只索引一个type下的数据 155 | 156 | 可以的，reindex 支持在索引重建的时候指定查询语句 157 | 158 | ``` 159 | POST _reindex 160 | { 161 | "source": { 162 | "index": ["twitter", "blog"], 163 | "type": ["_doc", "post"] 164 | }, 165 | "dest": { 166 | "index": "all_together", 167 | "type": "_doc" 168 | } 169 | ``` 170 | 171 | # 11、关于ES中Lucene Merge 线程问题； 172 | 173 | https://elasticsearch.cn/question/6465 174 | 175 | Merge 是非常耗费 CPU 的操作； 176 | 而且如果不是 SSD 的话，推荐将 index.merge.scheduler.max_thread_count 设置为 1； 177 | 否则 ES 会启动 Math.min(3, Runtime.getRuntime().availableProcessors() / 2) 个线程进行 Merge 操作； 178 | 这样大部分机械硬盘的磁盘 IO 都很难承受，就可能出现阻塞。 179 | 180 | 下面是 translog 和 merge 的设定，你可以参考一下： 181 | ``` 182 | "index": { 183 | "refresh_interval": "5s", 184 | "number_of_shards": "3", 185 | "max_result_window": 10000, 186 | "translog": { 187 | "flush_threshold_size": "500mb", 188 | "sync_interval": "30s", 189 | "durability": "async" 190 | }, 191 | "merge": { 192 | "scheduler": { 193 | "max_merge_count": "100", 194 | "max_thread_count": "1" 195 | } 196 | }, 197 | } 198 | ``` 199 | 200 | # 12、elasticsearch能不能和其他分词器搭配判断词性 201 | 202 | 判断词性不需要借助 ES，直接使用分词工具即可，例如 HanLP，jcseg 等 203 | -------------------------------------------------------------------------------- /es_accumulate/201812_report.md: -------------------------------------------------------------------------------- 1 | # 1、kibana分析nginx日志，还在纠结用filebeat还是logstash 2 | https://elasticsearch.cn/question/6479 3 | 4 | 服务器部署在阿里云，ES用的是5.3版本，里面index存了一些信息，然后用django写了个web让用户可以搜索ES里面的数据。 5 | 6 | 现在想收集nginx的log到kibana进行可视化，主要是想看一下每次访问的ＩＰ地址，对用户的location做一个可视化。 7 | 8 | 之前看一些ｂｌｏｇ文章，上面说如果用logstash来分析日志，然后在转存到ＥＳ，会有delay，而且web端也在不停的访问ES， 9 | 10 | 所以怕服务器CPU过载严重，毕竟用的是最普通的服务器。后来看了官方的ＢEATS视频，里面用的filebeat是６.X版的，然后配置的部分没有详细的讲， 11 | 12 | 所以看的不是特别的明白，想在就向问一下，对于我这种需求，到底用那个比较好呢？而且又不会给服务器带来太大的压力？谢谢了。 13 | 14 | 【回复】 15 | 收集端还是用filebeat比较好，不做日志解析，只要求将日志运出来即可，资源消耗非常低。 16 | 17 | 如果手里硬件资源不多，可以不用logstash，filebeat直接发到ES集群的ingest node，在ingest node上配置一个grok pipeline负责解析日志就可以了。 18 | 19 | 查一下官方的文档，重点是理解filebeat的elasticsearch output怎么配置， ES一端的ingest node怎么配置。 20 | 21 | # 2、elasticsearch 可以指定不参与搜索的字段么 22 | 23 | 就是索引映射很复杂，但有些字段是敏感信息，不想被搜索出来，elasticsearch可以控制搜索时不搜索这些字段么 24 | 25 | 如果你不想该字段被搜索，可以在mapping里面设置index为false。这样es不会在该字段上建立索引，在该字段上搜索就会报错。 26 | ``` 27 | PUT myindex/ 28 | { 29 | "mappings": { 30 | "mytype":{ 31 | "properties": { 32 | "name":{ 33 | "type": "text", 34 | "index": false 35 | }, 36 | "title":{ 37 | "type": "text" 38 | } 39 | } 40 | } 41 | 42 | } 43 | } 44 | ``` 45 | 46 | # 3、ES图片搜索？ 47 | 48 | https://elasticsearch.cn/question/6474 49 | 50 | 可以借助局部敏感 LSH 或者 pHash 来实现 51 | 52 | https://stackoverflow.com/questions/32785803/similar-image-search-by-phash-distance-in-elasticsearch 53 | 54 | Github 也有一个开源项目使用了多种 Hash 算法借助 ES 来实现图片搜索： 55 | 56 | https://github.com/usc-isi-i2/elasticsearch-image-features 57 | 58 | https://github.com/lior-k/fast-elasticsearch-vector-scoring 59 | 60 | # 4、关于segment.memory的大小？应该如何配置或者限制？ 61 | 62 | https://elasticsearch.cn/question/6500 63 | 64 | segment 的大小，和 indexing buffer 有关，有三种方式会生成 segment， 65 | 66 | 一种是 indexing buffer 写满了会生成 segment 文件，默认是堆内存的10%，是节点共享的， 67 | 68 | 一种是 index buffer 有文档，但是还没满，但是 refresh 时间到了，这个时候就会把 buffer 里面的生成 segment 文件， 69 | 70 | 还有最后一种就是es 自动的会将小的 segment 文件定期合并产生新的 segment 文件。 71 | 72 | 你此处的2g 大小和 indexbuffer 最直接相关，你可以调整 index buffer 大小来改变。 73 | https://www.elastic.co/guide/en/elasticsearch/reference/6.5/indexing-buffer.html 74 | 75 | # 5、es父子文档 76 | 77 | 查询子文档时候，往往用到has_parent，但是这样会有一个问题，就是查出来都子文档肯定有匹配都父文档， 78 | 而实际应用时，可能出现没有对应都父文档，在页面显示的就是不显示对应的信息，es提供这种方式吗 79 | 80 | 加上一个 innter_hits 条件就会返回对应的父子文档了。 81 | ``` 82 | GET parent/_search 83 | { 84 | "query": { 85 | "has_child": { 86 | "type": "child", 87 | "query": { 88 | "match": { 89 | "field": "value" 90 | } 91 | }, 92 | "inner_hits" : {} 93 | } 94 | } 95 | } 96 | ``` 97 | 98 | # 6、ES检索优化问题 99 | 查询的索引是car_*, 但是我们的索引是按照天建的, 也就是car_2018_01_01~car_2018_12_05, 100 | 101 | 因为要保留1年的数据, 那么一个最简单的查询(最近一小时), 如果我指定car_*索引组, 那么es会不会从 102 | 103 | car_2018_01_01~car_2018_12_05的索引全部过一遍, 并且每个index下有6个shard, 这样查询效果就很不理想 104 | 105 | 【回复】 106 | 要看ES版本的，早期版本即使放了时间这个filter，查询开销依旧很高。 107 | 比较新的版本（具体哪个版本开始记不清，也许是5.x以后）， 对于时间字段，会在索引里记录该字段的上下边界， 108 | 如果查询的时间范围和他的上下边界没有重叠，就将查询改写为match_non，从而跳过后面的查询过程，速度大大提高。 109 | 但开销最小的查询方式，还是根据查询时间范围，直接根据索引名称定位出要查询的索引，可以减少很多无谓的磁盘IO。 110 | 111 | # 7、ES数据快照到HDFS 112 | 113 | 1、ES官网提供快照方式和es-hadoop，不知道哪位用过，实现备份用哪种方式比较快速，我自己测试了快照方式，效率不是很快，大概1G/分钟、 114 | 115 | 2、快照方式，配置了压缩，但是存入hdfs的数据无压缩（比原来还稍微大一下），不知道有没有更好的方式进行压缩存储 116 | 117 | 【回复】 118 | ES 做快照和使用 es-Hadoop 倒数据是完全的两种不同的方式，使用 ES-Hadoopp 后期导入的成本可能也不小。 119 | 120 | 如果要恢复快，当然是做快照和还原的方式最快，速度完全取决于网络和磁盘的速度。 121 | 122 | 如果为了节省磁盘，快照的时候，可以选择6.5最新支持的 ```source_only 模式```，导出的快照要小很多，不过恢复的时候要进行重建，速度慢。 123 | 124 | # 8、关于滚动模式，关注terms耗时的化是不是就不需要缩小分片了 125 | 126 | 按天索引，使用一段时间后发现terms耗时过长，怀疑是因为分片大小波动较大导致的， 127 | 所以考虑使用滚动模式控制分片大小。这样是不是只要根据最优的文档数创建分片，然后做迁移就好了？ 128 | 缩小分片会不会对查询优化基本无用？ 129 | 130 | 【回复】 131 | 能测出分片的最佳大小用 Rollover 最合适了，数据不写了，可以 force merge 一下，可以提升查询性能。 132 | 133 | 如果分片还能缩小那你的前提就不存在了。 134 | 135 | # 9、ES 6.4 Xpack 安全模式下，Transprot连接客户端，SSL加密认证必须双向认证？ 136 | 137 | 不能关闭server对client的认证吗，和http一样单向认证？ 138 | 139 | 【回复】 140 | 141 | 必须启用，不然不安全的。没有 SSL 加密，你就算设置了密码，也是在裸奔。 142 | 143 | # 10、es update字段时，如何将数值再除以2 ？ 144 | 145 | 在es里面 update字段时如何把数值再除以2 ？ 146 | 就 像sql 语句 update user set age= age / 2 where id=02 这样的，在es里面如何实现 ？ 147 | 148 | 149 | 这是我更新时的指令： 150 | ``` 151 | GET user/doc/02/_update 152 | { 153 | "doc" : { 154 | "age" : "38" 155 | }, 156 | "doc_as_upsert" : true 157 | } 158 | ``` 159 | 【回复】 160 | 161 | age 不改成数字类型，效率比较低。不过也可以写，如下： 162 | ``` 163 | PUT user/doc/02 164 | { 165 | "age" : "38" 166 | } 167 | 168 | POST user/doc/02/_update 169 | { 170 | "script" : { 171 | "source": """ 172 | ctx._source.age = (Float.parseFloat(ctx._source.age)/params.count).toString(); 173 | """, 174 | "lang": "painless", 175 | "params" : { 176 | "count" : 2 177 | } 178 | } 179 | } 180 | 181 | GET user/doc/02 182 | 183 | ``` 184 | 185 | # 11、【重要】Shard大小官方推荐值为20-40GB, 具体原理呢？ 186 | 187 | https://elasticsearch.cn/question/6544 188 | 189 | As titled, Shard大小超过40GB后，读写速度迅速下降，具体是什么原因导致呢？ 190 | 191 | Lucene 底层没有这个大小的限制，20-40GB 的这个区间范围本身就比较大，经验值有时候就是拍脑袋，不一定都好使。 192 | 193 | Elasticsearch 对数据的隔离和迁移是以分片为单位进行的，分片太大，会加大迁移成本。 194 | 195 | 一个分片就是一个 Lucene 的库，一个 Lucene 目录里面包含很多 Segment， 196 | 每个 Segment 有文档数的上限，Segment 内部的文档 ID 目前使用的是 Java 的整型，也就是 2 的 31 次方， 197 | 所以能够表示的总的文档数为Integer.MAX_VALUE - 128 = 2^31 - 128 = 2147483647 - 1 = 2,147,483,519，也就是21.4亿条。 198 | 199 | 同样，如果你不 force merge 成一个 Segment，单个 shard 的文档数能超过这个数。 200 | 单个 Lucene 越大，索引会越大，查询的操作成本自然要越高，IO 压力越大，自然会影响查询体验。 201 | 具体一个分片多少数据合适，还是需要结合实际的业务数据和实际的查询来进行测试以进行评估。 202 | 203 | # 12、随机函数用完需要删除seed的字符串嘛？怎么删除？ 204 | 205 | ScoreFunctionBuilders.randomFunction().seed("1") 206 | 使用大量不同得seed之后我需要删除seed值嘛？有些seed过期之后就再也不会用了，怕浪费内存 207 | 208 | 【回复】： 209 | 不需要删除 210 | 设置 seed 其实就是设置 RandomScoreFunctionBuilder 中一个属性， 211 | 当你这个 builder 被回收的时候，自然 seed 也就被回收了，不会耗费内存 212 | 213 | # 13、目前beats工具只有官网列出来的8种吗？ 214 | 215 | https://www.elastic.co/guide/en/beats/libbeat/6.5/community-beats.html 216 | 217 | 除了官方的，请看这个页面，非常多，几十个了： 218 | 219 | # 14、如何选择在ES之前处理写入的中间件？ 220 | 221 | 场景：ES是用来存业务数据，把ES作为数据存储的平台，提供查询服务 222 | 数据写入方式包括，应用调用HTTP接口写入，通过Hive的外表导入到ES 223 | 224 | 问题：上述两种方式由于都存在请求流程不可控的情况，希望能在ES前面加一层MQ，比如kafka，来缓解写入的压力 225 | 根据这个需求，就需要选择一款可以将 ES和kafka结合起来，并且还能处理现有的 hive等场景的数据写入，要选择什么样的中间件产品能满足上述需求呢？ 226 | 227 | 还请有经验的大神指教。 228 | 229 | 【参考思路】我们目前的做法是： 230 | 1. 做个平台给各个有读写需求的部门自己设置自己的mapping，比如字段类型、是否按天、月、年建索引… 231 | 2. 开一个（如果有特殊需求可能是好几个）Kafka的topic 232 | 3. 约定好交互格式，（比如，用 index|type|_id|timestamp|randomkey 作为kfk的key），然后（用docker技术）动态增减consumer做数据的导入 233 | 234 | 由于公司技术栈主要是Java，所以几个组件，包括数据预处理的插件都是Java实现的，也可以选择包括golang、python、ruby…等各种不同的实现。不知道能不能解决你的问题？ 235 | 236 | # 15、ES的父子查询中如何使用scripts的来过滤数据 237 | 238 | 【转换思路】不一定需要脚本来过滤，对子文档的过滤可以使用 inner hits 239 | 可以参考官方文档：https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-inner-hits.html 240 | 241 | # 16、什么我们集群大量写入的时候，load负载及其不均匀呀？ 242 | 243 | 你去调用下 hot_threads 看它在干嘛？此时 cpu 利用率看起来是不高的，那是不是这个节点的磁盘 IO 性能有问题？ 244 | 245 | # 17、elasticsearch 宕机1台 会有20分钟不可访问 246 | 247 | 248 | 向各位请教一下，我们有9台物理机，27个节点的es服务器，总数据量大于10来个T，每天数据大概1个T，当有1台物理机宕机的情况下， 249 | 集群是黄色，但是会有20来分钟，运行非常慢，请求会超时。 我理解，当时集群会做两个动作，1个是副本的恢复，1个是数据的重平衡， 250 | 有什么办法解决这个问题吗？能不能调整他降低他恢复的速度？不要1台宕机就影响一段时间数据无法查询和写入 251 | 252 | 253 | 【回复1】 254 | 255 | 如集群正常工作的情况下，cpu/磁盘io已经接近饱和了，那么数据恢复的确可能影响到读写的吞吐量，这个时候只能是控制recovery的速率（集群有个设置indices.recovery.max_bytes_per_sec) 或者按照Rockybean的方法，延缓recovery触发的时机，等待故障节点恢复重新加入集群以后，从本地恢复大部分数据，尽量减小recovery带来的影响。 如果这些都不解决问题，就只能是扩容硬件了。 256 | 257 | 不过你有10台物理机，数据总量只有10TB左右，一台机器跑一个ES实例性能会更好。 258 | 259 | 多实例部署，如果heap划分又很大，通常会造成heap空间过剩而系统缓存不够的尴尬情况，性能相反会大幅降低。一般来说跑多实例的目的是为了在一个节点上存储尽量多的数据，响应的代价是牺牲一些读写性能。 260 | 261 | 最后一点就是要注意控制集群的index/shard的数量，如果shard数量非常多（上万），出现节点故障的情况下，master节点可能会不堪重负。 262 | 263 | 如果你没有单独设立master，而是混入了data node，那么也是有可能对读写产生较大的影响。 264 | 265 | 【回复2】 266 | 你现在1台物理机有3个节点，所以实际是一次3个 es 节点挂了，那么实际需要重新分配1TB 左右的数据，这个过程是会影响集群性能的。 267 | 有一个解决方法是延迟集群再分配分片的时间，在这个时间到来之前将停掉的节点启动起来，可以节省大量分片重分配的时间。 268 | https://www.elastic.co/guide/en/elasticsearch/reference/current/delayed-allocation.html 269 | 270 | PUT _all/_settings 271 | { 272 | "settings": { 273 | "index.unassigned.node_left.delayed_timeout": "5m" 274 | } 275 | } 276 | 这个值你可以设的大一些，比如一天 1d，这样有充分的时间来恢复节点 277 | 278 | 279 | # 18、bulk提交后无响应 280 | 281 | 【回复】 ```bulk推荐的大小为 5-10M```，你这个文件确实太大了； 282 | 处理速度还与你的 mapping 映射有直接关系； 283 | 如果某个字段内容特别多，又被索引，那么将会耗费大量时间在分词上； 284 | 285 | 对于 bulk 操作，你可以通过查看 task 相关的 API，来查看任务状态 286 | -------------------------------------------------------------------------------- /es_accumulate/201901_report.md: -------------------------------------------------------------------------------- 1 | # 1、kibana根据历史数据预测未来数据 2 | 3 | Elastic 的机器学习功能刚好就能做 4 | 5 | https://www.elastic.co/products/stack/machine-learning 6 | 7 | # 2、es查询问题。 8 | 9 | 另外你要注意一下 Lucene 的语法规则： 10 | 11 | https://lucene.apache.org/core/2_9_4/queryparsersyntax.html 12 | 13 | a+(D|d) 这里 a 是可选，括号内的必要的。如果要 a 是必要条件，加号要放前面。如果是两个关键字直接是任意满足的关系，一般是用||。另外注意括号的全角和半角。 14 | 15 | 如：+a +(c||d) 16 | 17 | # 3、【重要】关于elasticsearch中filter的粒度的疑问 18 | 19 | 推荐阅读：https://elasticsearch.cn/question/6667 20 | 21 | filter是单个缓存的，不过对于term 类型的filter是否缓存要看版本。 22 | 因为term filter开销很小，所以从5.1.1之后不再做缓存。 23 | 24 | filter上下文中的查询是独立被cache的，所以按照你给的例子，应该是三个。 25 | ```相关的资料```在这里: https://www.elastic.co/guide/cn/elasticsearch/guide/current/filter-caching.html#_%E7%8B%AC%E7%AB%8B%E7%9A%84%E8%BF%87%E6%BB%A4%E5%99%A8%E7%BC%93%E5%AD%98 26 | 27 | 只不过从5.1.1版本以后开始，term query不会被cache了。 28 | 其他类型的query，比方说range query，各种geo的query依然会被cache起来。 这点只有在5.1.1的release notes有提及。 29 | 30 | # 4、ES2.3版本，delete一个索引，master日志并没有记录相关delete操作？ 31 | 32 | 【原因】 33 | ``` 34 | PUT _cluster/settings 35 | { 36 | "persistent": { 37 | "logger.cluster.service": "DEBUG" 38 | } 39 | } 40 | ``` 41 | 打开cluster.service的debug，能看到创建、删除索引的日志 42 | 43 | 低版本地址：https://www.elastic.co/guide/en/elasticsearch/guide/current/logging.html 44 | 45 | 高版本地址;https://www.elastic.co/guide/en/elasticsearch/reference/6.6/logging.html 46 | 47 | # 5、【重要】es gc overhead 报错 48 | 49 | 通过scroll方式查询时，特别注意要设置游标有效时间不能太久， 50 | 例如scroll=30min，过期时间越长对应数据保存在ES内存中就越久，ES内存越大。 51 | 52 | srcoll查询完后要及时调用```clearScroll(scrollId)```来清理对应游标数据。 53 | 54 | https://elasticsearch.cn/question/6578 55 | 56 | # 6、es5.5版本,当文档字段是1100多个的时候,报异常 57 | 58 | Limit of total fields [1000] in index [nfvoemspm] has been exceeded 59 | 60 | 修改settings 61 | ``` 62 | { 63 | "index.mapping.total_fields.limit": 2000 64 | } 65 | ``` 66 | 67 | 话说真的需要这么多字段放在一起吗，能不能从设计上优化一下。 68 | 69 | # 7、Elasticsearch技术栈选型推荐 70 | 71 | https://elasticsearch.cn/question/6676 72 | 73 | 方案1：SpringBoot+Thymeleaf+RestHighLevelClient 74 | 75 | 方案2：SpringBoot 76 | 简单的语句用String.format复杂语句用Freemarker 77 | 然后用RestHighLevelClient甚至直接自己包装一个HttpClient 78 | 结合ES自己的template使用 79 | 80 | git封装参考：https://github.com/godlockin/searchHandler 81 | 82 | # 8、【警惕】数据丢失啦 83 | 84 | https://elasticsearch.cn/question/6650 85 | 86 | 问题：今天发现ES 服务器上所有机器的所有数据都消失了。 没有进行过任何操作。 87 | 求教有什么原因可以导致这种结果.不管是正常的非正常的，能给个指教就是好事。 88 | 89 | 运维同学抓破头也没找到问题出在哪 90 | 91 | 【根因】：运维人员通过head插件把相关index删除了，而且是愤世嫉俗一般的全部删掉。 现在我更关心如何做安全策略 92 | 93 | 推荐阅读：https://blog.csdn.net/laoyang360/article/details/86347480 你的Elasticsearch在裸奔吗？ 94 | 95 | 【注意事项】 96 | 1.是否暴露了公网访问 97 | 2.是否有团队/公司里其他人知道地址 98 | 3.检查一下数据导入的脚本有没有重启、oom、做过滤… 99 | 4.差不差钱，不差钱的买个xpack做安全策略，差钱就内网隔离部署+黑白名单，亡羊补牢犹未晚矣 100 | 5.rerun一下数据导入脚本进行数据修复 101 | 6.找到原因了之后不管多妖或者多蠢，都记得回来这里发个帖子，详细的聊聊整个issue的前因后果 102 | 7、先看一下数据路径里面的数据是否正常； 103 | 8、看一下是否开启了通配符数据删除； 104 | 9、看一下 ES 日志，从中找是否集群启停过之类的操作 105 | 10、确认下磁盘是不是满了，导致的异常或者磁盘路径的问题 106 | 107 | 108 | # 9、有关es forceMerge问题 109 | 110 | https://elasticsearch.cn/question/6563 111 | 112 | 通过Kibana观察到 每次强制给某个索引合并段时 都会发现该索引的所占空间会跟随段合并暴涨一倍； 113 | 114 | 现在问题是这样的；磁盘空间所剩的空间 不足以撑起某个要合并段的索引的体积的两倍大小 115 | 那么这个索引是不是就不能合并了 如果仍执行强制合并段 会发生什么？ 116 | 117 | 回复：es的合并，是将要合并的segment读取出来，再写入到新的segment，然后删除老的segment，所以，消耗大量的资源和磁盘空间。 118 | 你这样的情况，建议加大磁盘，或者限制索引合并的线程数量，减小每次合并的segment数量。 119 | 120 | # 10、beats如何通过配置删除host字段 121 | 122 | 123 | 最近在做日志采集，发现filebeat和winlogbeat采集日志的时候，会有host这个字段，但是是个object字段，es里日志索引host是text类型，想在agent里直接通过参数把host字段，可以做到么？看了下配置，好像没有找到 124 | 125 | 你可以通过添加 processors 实现字段过滤的功能，例如 126 | ``` 127 | processors: 128 | - drop_fields: 129 | when: 130 | condition 131 | fields: ["field1", "field2", ...] 132 | ``` 133 | 具体请参考： 134 | https://www.elastic.co/guide/en/beats/filebeat/current/defining-processors.html 135 | 136 | # 11、有没有 ngram 和 wildcard 折中方案？ 137 | 138 | https://elasticsearch.cn/question/6733 139 | 140 | 想支持英文的部分搜索，比如 good，搜索oo也可以匹配出来。这就需要 ngram，但是 ngram 使得 index 占用空间10X+增大，有点无法接受。wildcard 搜索效率又实在太低。有什么折中方案么？ 141 | 142 | 你可以试试前缀搜索 143 | good 你分词为 good/ood/od/ 144 | 这样使用前缀搜索就可以实现你需要的效果； 145 | 同时设置一下 mapping，可进一步加快搜索速度 146 | 147 | ``` 148 | "index_prefixes": { 149 | "min_chars": 1, 150 | "max_chars": 10 151 | } 152 | ``` 153 | 154 | # 12、 logstash吞吐量太低了怎么优化呢？ 155 | https://elasticsearch.cn/question/6739 156 | 157 | Logstash 性能调优主要参数 158 | ``` 159 | pipeline.workers： 160 | ``` 161 | 设置启动多少个线程执行 fliter 和 output； 162 | 当 input 的内容出现堆积而 CPU 使用率还比较充足时，可以考虑增加该参数的大小； 163 | ``` 164 | pipeline.batch.size： 165 | ``` 166 | 设置单个工作线程在执行过滤器和输出之前收集的最大事件数，较大的批量大小通常更高效，但会增加内存开销。输出插件会将每个批处理作为一个输出单元。； 167 | 168 | 例如，ES 输出会为收到的每个批次发出批量请求；调整 pipeline.batch.size 可调整发送到 ES 的批量请求（Bulk）的大小； 169 | ``` 170 | pipeline.batch.delay： 171 | ``` 172 | 设置 Logstash 管道的延迟时间， 管道批处理延迟是 Logstash 在当前管道工作线程中接收事件后等待新消息的最长时间（以毫秒为单位）； 173 | 174 | 简单来说，当 pipeline.batch.size 不满足时，会等待 pipeline.batch.delay 设置的时间，超时后便开始执行 filter 和 output 操作。 175 | 176 | 请根据具体情况，调整 batch.size 或者 works 的数量 177 | 178 | https://elasticsearch.cn/question/6739 179 | 180 | # 13、请教一个多索引字段比对查询写法的问题 181 | 182 | 183 | 想要实现的功能例子如下： 184 | 185 | 有2个索引： company person 186 | 里面都包含goods和price字段 187 | 需要查询出来company和persion中当goods字段的值一样时price字段的值不一样的数据，目前没有头绪，请问该怎样写呢。 188 | 189 | 对 goods 字段进行 termsAgg，然后设置其子聚合为对 _index 的 termsAgg 子聚合，并设置 min_doc_count 为 2； 190 | 最后设置 _index 的子聚合为 topHits，这样就可以找到你需要的数据。 191 | 192 | ``` 193 | { 194 | "size": 0, 195 | "query": { 196 | "match_all": { 197 | "boost": 1.0 198 | } 199 | }, 200 | "aggregations": { 201 | "goods": { 202 | "terms": { 203 | "field": "goods", 204 | "size": 10000, 205 | "min_doc_count": 1, 206 | "shard_min_doc_count": 0, 207 | "show_term_doc_count_error": false, 208 | "order": [{ 209 | "_count": "desc" 210 | }, { 211 | "_key": "asc" 212 | }], 213 | "collect_mode": "breadth_first" 214 | }, 215 | "aggregations": { 216 | "index": { 217 | "terms": { 218 | "field": "_index", 219 | "size": 10, 220 | "min_doc_count": 2, 221 | "shard_min_doc_count": 0, 222 | "show_term_doc_count_error": false, 223 | "order": [{ 224 | "_count": "desc" 225 | }, { 226 | "_key": "asc" 227 | }] 228 | }, 229 | "aggregations": { 230 | "top": { 231 | "top_hits": { 232 | "from": 0, 233 | "size": 100, 234 | "version": false, 235 | "explain": false 236 | } 237 | } 238 | } 239 | } 240 | } 241 | } 242 | } 243 | } 244 | ``` 245 | 246 | # 14、search_after的SearchAfterBuilder使用范例： 247 | 248 | 首先要理解 search_after 这个功能； 249 | 例如你现在需要安装 id 和 time 进行排序； 250 | 你获取了第一页的结果后，现在需要获取第二页内容 251 | 你需要使用第一页最后一条的 id 和 time，作为 search_after 的参数chuan传递到查询请求中。 252 | 253 | 下面是样例： 254 | ``` 255 | SearchAfterBuilder searchAfterBuilder = new SearchAfterBuilder(); 256 | searchAfterBuilder.setSortValues(new Object[]{"上一页的ID", "上一页的时间"}); 257 | ``` 258 | 259 | # 15、ES数据恢复，从red恢复到yellow速度很快，从yellow到green恢复很慢 260 | 261 | https://elasticsearch.cn/question/6714 262 | 263 | red恢复的时候是从本地加载之前的索引文件，没有从别的地方同步，所以比较快。 264 | yellow恢复成GREEN的时候，很大部分都可能是从主shard同步数据，在6.x之前，通常都会很慢。 265 | 6.x之后由于translog机制的变更可能会变快，但这里还要考虑集群在恢复的时候可能会自己做reblance，同样涉及到shard跨节点的搬迁 266 | 267 | # 16、ElasticSearch java api，想要实现一次请求查询多个类型的同时，每个类型只取固定数量的数据 268 | 269 | 最近在做系统的搜索功能，在一个索引下建了一些不同的类型。 270 | 页面上的全局搜索功能是要求展示所有类型的数据。 271 | 272 | 一开始想的是按找类型发起请求，每个类型一次，只取几条数据。 273 | 但是发现查全部类型的时候，虽然单个类型的数据查询已经解析工作只需要几十毫秒，但全部执行完就需要一秒左右了。 274 | 所以想要实现只请求一次，查询所有类型的数据，并且每个类型只取固定数量的数据。 275 | 请问java api能实现这样的功能吗？ 276 | 277 | 【实现】 278 | 279 | 换一种思路，这么实现一下，能满足你的要求。 280 | ``` 281 | POST weibo_index/weibo_type,weibo_cm_type/_search 282 | { 283 | "size": 0, 284 | "query": { 285 | "bool": { 286 | "must": { 287 | "match": { 288 | "cont": "北京" 289 | } 290 | } 291 | } 292 | }, 293 | "aggs": { 294 | "type_aggs": { 295 | "terms": { 296 | "field": "_type", 297 | "size": 2 298 | }, 299 | "aggs": { 300 | "top_hits_aggs": { 301 | "top_hits": { 302 | "size": 5, 303 | "_source": [ 304 | "pt", 305 | "url" 306 | ] 307 | } 308 | } 309 | } 310 | } 311 | } 312 | } 313 | ``` 314 | 315 | # 17、请问copy_to字段 和 mutil_fields哪种性能好一些呢？ 316 | 317 | https://elasticsearch.cn/question/6698 318 | 319 | 因为我们公司业务的原因，我们需要copy_to字段后，然后做全文检索，那么我想问一下大家，copy_to字段和直接mutil_field哪种性能更好一些呢？ 320 | 321 | 【参考1】如果只是简单的全文搜索推荐使用 copy_to，性能更佳； 322 | 使用 mutil_field 的优点在于每个字段可用设置不同的权重，这样更有助于优化搜索结果排名； 323 | 此外 copy_to 会比 mutil_field 占用更多一些的存储 324 | 325 | 【参考2】 326 | 如果是全文检索，建议使用copy_to，使用更少的字段，性能会更好一些。如果只是对某个字段单独去做，就基本上没有什么差别。 327 | 328 | # 18、ES重启后head插件显示粉红色 329 | 330 | 粉红色是分片relocating阶段正常的颜色变化，稍安勿躁，一会就好了。 331 | 332 | 粉红色表示分片在重新分配 333 | 如果只是临时重启机器，推荐配置分配延迟分配策略： 334 | ``` 335 | PUT _all/_settings 336 | { 337 | "settings": { 338 | "index.unassigned.node_left.delayed_timeout": "5m" 339 | } 340 | } 341 | ``` 342 | 343 | 【引申可能原因】： 344 | 好像硬盘出问题了吧。把副本调整下，再调整回来，让他重新分配下。1G应该是秒级恢复的。 345 | 346 | # 19、【很有代表性问题】ES匹配度的打分问题 347 | 使用ES默认的打分规则（TF-IDF），搜索“葡萄糖”时，搜索结果中“纯净葡萄糖(食用葡萄糖)”比全匹配的“葡萄糖”的得分还要高。因为在前者中“葡萄糖”出现过两次。 348 | 但是我更想要全匹配的或匹配度更高的，而不关心出现的次数。对我来说，相比“纯净葡萄糖(食用葡萄糖)”，我希望“葡萄糖液”得分更好。 349 | 因为“葡萄糖液”中关键字占了3/4，即使前者出现两次“葡萄糖”。 350 | 我该怎么修改？是修改TF-IDF配置，或者修改打分算法，还是自定义打分规则？ 351 | 352 | 【回复】 353 | 354 | ES 支持关闭词频统计，设置 mapping 即可 355 | 356 | ``` 357 | PUT /my_index 358 | { 359 | "mappings": { 360 | "doc": { 361 | "properties": { 362 | "text": { 363 | "type": "string", 364 | "index_options": "docs" 365 | } 366 | } 367 | } 368 | } 369 | } 370 | ``` 371 | 将参数 index_options 设置为 docs 可以禁用词频统计及词频位置，这个映射的字段不会计算词的出现次数，对于短语或近似查询也不可用。要求精确查询的 not_analyzed 字符串字段会默认使用该设置。 372 | 373 | 推荐阅读：https://blog.csdn.net/paditang/article/details/79098830 374 | 375 | # 20、单索引大数据量，如何优化？ 376 | 377 | 【问题】单索引当前已经存储1.5亿多文档，3节点5分片1副本，每个分片20G多。有定期删除老数据，但是预计在删除老数据前，可能最大存储文档达到24亿多。 378 | 当前想到的解决方案： 379 | 1、根据预估的最大24亿最大文档，对当前资源进行扩容。 380 | 但是根据之前的数据计算，应该如何合理分配分片？如何计算需要扩容几个节点满足要求？ 381 | 2、使用rollover根据条件，索引太大后，写入数据切换至新索引，但是查询数据还是对全部索引进行查询。 382 | 这样可能是多索引，每个索引5分片1副本。 383 | 384 | 现在疑惑是哪种方案更合理？个人倾向于方案2，比较扩容也是需要成本。 385 | 但是方案2后续索引增加，分片增加后，每次查询是设置查询别名指向所有索引，这样查询性能是不是也会持续下降？ 386 | 387 | 【回复】 388 | 这个推荐先在搜索压力小的时段对索引进行一次 ForceMerge，这样会之前已经删除的文档进行真正删除操作； 389 | 此外，如果搜索压力大的化，可以多增加一个副本，这样副本也可以分担搜索的压力； 390 | 391 | 如果希望多个索引分担压力，可以使用别名，```别名```可以指定多个索引的某一个索引是可以写入数据的； 392 | 搜索的时候是全部索引一起搜索. 393 | 394 | 【铭毅回复】： 395 | 针对方案2：结合template+rollover+别名+curator可以解决问题，不存在性能问题。 396 | 相反，针对最新数据的索引，反而通过制定日期索引，会缩减检索样本空间，反而效率更高。 397 | 398 | 【进一步推进阅读】 399 | 6.6 版本索引生命管理 400 | https://elasticsearch.cn/article/6358 401 | 402 | # 21、推荐阅读新文章 403 | 404 | 自研基于StanfordNLP的ES分词插件 405 | https://elasticsearch.cn/article/6341 406 | 407 | 408 | 409 | -------------------------------------------------------------------------------- /es_accumulate/201902_report.md: -------------------------------------------------------------------------------- 1 | # 0、【Kibana】Kibana CCR功能连接失败的处理方法 2 | 【描述】 3 | 4 | ES的cross cluster功能 很简单就可以配置成功，kibana也支持通过 集群名：索引名 的方式直接调用，但是发现一个很难受的问题，就是当有一个集群连接不上时，整个面板就会提示连接失败，其他连接成功的数据也不显示了。大家有什么解决方案吗？当集群连接不上就跳过之类的设置。 5 | 6 | 【解答】 7 | 6.1版本后，会有一个skip_unavailable的参数，对症你的问题。 8 | 9 | 10 | # 1、【Kibana】kibana图表能做自定义标注吗？ 11 | 可以的，用 TSVB，支持标注。 12 | 详细实现推荐：https://elasticsearch.cn/article/701 13 | 14 | # 2、es能否9200端口监听在127.0.0.1 9300端口监听到0.0.0.0这样配置？ 15 | 16 | 描述：现在我想9200 API接口端口人监听在回环地址127.0.0.1上 然后前面再加一个nginx 用来作访问日志审计 用户限制等功能， 17 | 而tcp节点数据端口9300就监听在0.0.0.0所有可用的IP地址上。ES是6.5.4版本 有没有办法通过更改elasticsearch.yml配置来实现？ 18 | 19 | 【回复】 20 | HTTP 的是 `http.bind_host` 21 | http.bind_host——The host address to bind the HTTP service to. 22 | Defaults to http.host (if set) or network.bind_host. 23 | 24 | https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-http.html 25 | 26 | TCP 的是 `transport.bind_host` 27 | transport.bind_host——The host address to bind the transport service to. 28 | Defaults to transport.host (if set) or network.bind_host. 29 | 30 | https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-transport.html 31 | 32 | TCP 是集群内互联的，同样要做好加密措施，要绑也是绑定内网地址，不要4个0。 33 | 34 | # 3、给ES 9200 端口配置域名无效 35 | 36 | 描述： 37 | 大家有给ES 的9200 配置过域名吗 38 | 39 | 配置后发现在浏览器直接访问域名可以像之前一样看到ES 的信息 40 | 41 | 但是如果在程序中或者 postman 中使用域名/索引/_search 的时候发现并获取不到相应的数据 42 | 43 | 【解答】 44 | 45 | 先试试这个——配置域名很简单，前面加一个 nginx 做一下反向代理就可以了： 46 | ``` 47 | location ^~ /data/ 48 | { 49 | proxy_pass http://192.168.187.xxx:9200/; 50 | } 51 | ``` 52 | 关键点在用最后面的/符号。 53 | 54 | # 4、增加专用的协调节点,查询没有变快 55 | 56 | 【解答】 57 | 58 | 1、依靠协调节点去提高查询速度，大部分情况下收益不会有预期的大，协调节点是为了更合理的分配资源， 59 | 参与merge时资源的消耗，查询速度主要还是看索引本身和查询语句是否有可以优化的空间。 60 | 61 | 2、增加协调节点不一定能使得查询速度明显提升， 62 | 最重要的要看你查询的数据量和查询语句的优化 63 | 64 | 【补充知识点-官网】 65 | 66 | 协调节点用途——诸如搜索请求或批量索引请求之类的请求可能涉及保存在不同数据节点上的数据。 67 | 例如，搜索请求在两个阶段中执行，这两个阶段由接收客户端请求的节点 - 协调节点协调。 68 | 1）在分发阶段，协调节点将请求转发到保存数据的数据节点。 每个数据节点在本地执行请求并将其结果返回给协调节点。 69 | 2）在收集阶段，协调节点将每个数据节点的结果减少为单个全局结果集。 70 | 71 | ```（经常被问到的问题）每个节点都隐式地是一个协调节点```。 72 | 这意味着将所有三个node.master，node.data和node.ingest设置为false的节点仅用作协调节点，无法禁用该节点。 73 | 结果，这样的节点需要具有足够的存储器和CPU以便处理收集阶段。 74 | 75 | # 5、Elasticsearch开源和商业化版本区别？ 76 | 77 | https://www.elastic.co/subscriptions 78 | 79 | # 6、【反向查询】ES是否可以实现反向查找，类似敏感词的功能 80 | 81 | 请问：ES是否可以实现反向查找，类似敏感词的功能，需求是：一篇文章里，需要查找 文章中是否有数据 在索引中存在（完全匹配） 82 | 83 | 【实现举例】： 84 | percolate查询可用于匹配存储在索引中的查询。 percolate查询本身包含将用作查询以与存储的查询匹配的文档。 85 | 86 | https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-percolate-query.html 87 | 88 | # 7、查询时使用terms来替换多个term可以提高效率吗? 89 | 90 | 根据 lucene 官方的解释： 91 | 当 term 的个数少的时候，termsQuery 等效为多个 termQuery 使用 boolQuery 使用 or 操作符连接起来； 92 | 当 term 的个数多的时候，termsQuery 查询创建一个位集的方式进行查询，效率会比普通的 bool 方式好一些 93 | 94 | https://lucene.apache.org/core/6_4_2/queries/org/apache/lucene/queries/TermsQuery.html 95 | 96 | # 8、【多次提问类似问题】elasticsearch 批量删除 导致使用磁盘容量上升 97 | 98 | 注意： 99 | 100 | 1、es的删除是标记模式，删除不会是立马删除，会给数据打个删除状态，在索引和段合并的过程中，es会整合资源， 101 | 将标记删除的数据真正的删除掉。所以你看到是一个缓慢的磁盘下降过程 102 | 103 | 2、es的合并，是将要合并的segment读取出来，再写入到新的segment，然后删除老的segment，所以，消耗大量的资源和磁盘空间。 104 | 105 | # 9、logstash 字符串转换 106 | 107 | https://elasticsearch.cn/question/4469 108 | 配置见文件附件部分 109 | 110 | # 10、超大ES集群如何控制主分片均匀分配 111 | 112 | 这里按照你的描述可能涉及主分片的分配策略的修改。 113 | 5.X版本之后的主分片的选举实现：依据allocation id 从 inSyncAllocationIds 列表中选择主分片。 114 | 115 | 推荐看一下官方文档： 116 | 117 | https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-allocation.html 118 | 119 | https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html 120 | 121 | 并且还有一个维度，建议关注一下：，触发分片分配的时机：不只是创建索引的阶段，还包含: 122 | 1) index 索引增删； 123 | 2）节点增删； 124 | 3）reroute操作； 125 | 4）副本数量改变； 126 | 5）集群重启。 127 | 128 | # 10、elasticsearch不能删除已有index中的字段吧？ 129 | 130 | 删除Mapping的字段，而非字段值，字段值可以通过script删除。 131 | 字段验证如下： 132 | 133 | 1、增加字段 可以 已验证 134 | 2、删除字段 不可以 135 | 4、修改字段 不可以 136 | 3、修改字段类型 不可以 137 | 138 | 不过ES有其他方案可以替换，借助reindex，数据量大会有性能问题。 139 | 140 | 注意：ES 6.X版本新特性，字段支持别名字段，能很好的解决此类问题。 141 | https://www.elastic.co/guide/en/elasticsearch/reference/master/alias.html 142 | 143 | # 11、MySQL中表无唯一递增字段，也无唯一递增时间字段，该怎么使用logstash实现MySQL实时增量导数据到es中？ 144 | 145 | 我的ELK版本是6.5.3 146 | 147 | 【回复】 148 | 149 | ogstash增量有两种方式：1、基于时间递增；2、基于递增字段比如：id。 150 | 两者都没有，就不大好办。 151 | 如果非要使用logstash，建议修改一下表结构。 152 | 153 | 其他的同步方式：比如——kafka-connector，也需要基于时间或者自增id的，才能实现增量。 154 | 155 | 推荐binlog方案：https://blog.csdn.net/laoyang360/article/details/87897886 156 | 157 | # 12、想请教您一个高亮搜索，同时展示关联字段的问题 158 | 159 | inner_hits API能满足要求，详见链接： 160 | https://elasticsearch.cn/question/6887 161 | 162 | ``` 163 | # 2 inner_hits能满足你的要求 164 | POST my_index/_search 165 | { 166 | "query": { 167 | "nested": { 168 | "path": "data", 169 | "query": { 170 | "match": { 171 | "data.comment": "commercial" 172 | } 173 | }, 174 | "inner_hits": {} 175 | } 176 | }, 177 | "highlight": { 178 | "fields": { 179 | "data.comment": { 180 | "number_of_fragments": 0 181 | } 182 | }, 183 | "pre_tags": [ 184 | "" 185 | ], 186 | "post_tags": [ 187 | "" 188 | ] 189 | } 190 | } 191 | ``` 192 | 193 | 194 | # 13、【推荐阅读】Elasticsearch 6.6 Index Lifecycle Management 195 | 196 | 再也不用管理那些crontab了！ 197 | https://elasticsearch.cn/article/6358 198 | 199 | # 14、【推荐】logstash在Elasticsearch中创建的默认索引模板问题 200 | 201 | https://cloud.tencent.com/developer/article/1359811 202 | -------------------------------------------------------------------------------- /es_accumulate/201903_report.md: -------------------------------------------------------------------------------- 1 | # 1、Elasticsearch 2 | ## 1.1 如何清理Elasticsearch特定时间段数据？ 3 | 1) Elasticsearch 6.6+新推出了一个 ILM 的功能，Index Lifecycle Management 的功能，在Kibana 界面里面就可以直接配置索引的保留时间和过期策略。 4 | 上一次错题本也提及：https://elasticsearch.cn/article/6358 5 | 2) es5.0提供了 Rollover 特性 6 | 7 | https://elasticsearch.cn/question/1094 8 | 9 | ## 1.2 能否在一个查询中 查询两个条件 在对两个结果进行除法计算? 10 | -------------------------------------------------------------------------------- 11 | 请教各位一个问题，我们有一个场景，想通过1个查询语句，计算两个查询结果的除法， 12 | 比如，我有一个查询条件，用 idc: "BJ" 能统计出有100条数据符合要求 ， 13 | 第二个条件 idc: "SH"，能统计出有200个数据，我现在想要取到 100 / 200 这个值 50% 这个数据， 14 | 请问能有办法实现吗？ 15 | 16 | ``` 17 | #参考 es6.6版本 18 | 19 | 20 | PUT test01_index/_doc/5 21 | { 22 | "x_value":15, 23 | "y_value":3 24 | } 25 | 26 | 27 | POST test01_index/_doc/_search 28 | { 29 | "script_fields": { 30 | "my_divide_field": { 31 | "script": { 32 | "lang": "expression", 33 | "source": "doc['y_value'].value != 0 ? doc['x_value'].value / doc['y_value'].value : 0" 34 | } 35 | } 36 | } 37 | } 38 | 39 | ``` 40 | ## 1.3 ngram分词器会占很多内存吗? 41 | -------------------------------------------------------------------------------- 42 | ngram分词分的很细,会不会导致较多的内存占用?当数据量较大时,是否有瓶颈?? 43 | 44 | 【回复】ngram分词分的很细会产生较多的 term ，因此会比普通使用词典分词的占用更多的存储和内容； 45 | 数据量大的时候，可通过分索引和多分片来分散压力。 46 | 47 | ## 1.4 自定义id带来的问题 48 | -------------------------------------------------------------------------------- 49 | 问题描述：我们目前业务使用了自定义id，md5(uid+someid), 目的是为了再次更新方便。但是这样有两个问题，1: 这种随机的自定义id，压缩比很低，空间占用高。2: 指定id bulk index 的时候，es 会先判断 id 是否存在，然后再插入。这样随着数据量的增加，性能持续下降。 不知道大家有什么好办法，对应这种需要持续更新的数据。 数据量还挺大的。 50 | 51 | 官网建议：如果使用了自动生成id，每次导入数据的时候都要进行id的检查。这里是有性能消耗的。但是使用随机生成id,就不需要这一步。 52 | 官网地址：http://t.cn/Ei47gY0 53 | 讨论建议： 54 | 1. id的生成策略尽量是对压缩友好的，避免过于随机，比如按序生成 55 | 2. 想到一点减小id是否存在的判断成本，是否考虑使用`路由`，相当于指定了插入doc所在的shard，减少判断是否存在的数据量 56 | 57 | ## 1.5 关于 ik 新词更新 58 | -------------------------------------------------------------------------------- 59 | 想做新词发现，更新词库，但是搞不清es对于这种更新词库后，老数据怎么处理为好 60 | 61 | 建议：不影响搜索的话，重建索引，reindex ,然后别名切换过去。 62 | 原因：ES数据写入的过程即是索引化的过程，这个阶段会按照设定的分词进行数据索引化。所以，必须reindex重建索引或者重新导入数据才能生效。 63 | 64 | ## 1 .6 es有没可能同时写多个索引？ 65 | -------------------------------------------------------------------------------- 66 | 有旧有数据的同步问题的困扰，需要类似数据双写的操作，貌似直接设置同一个别名然后insert会报错 67 | 68 | alias 只能声明一个索引为写活跃状态，无法多个同时写入,否则会报错。 69 | 或者用reindex 开始的时候你写两份就行啊，修改一份。 70 | 71 | ## 1.7 bulk写入数据时，READ非常高 72 | 无论是index或者是update，只要指定了doc id，lucene都需要进行get操作，当你索引数据量很大时，会有频繁且大量segment中的数据加载到内存，这是`read io高`的一个大原因， 73 | 另外通常merge 只要线程数限小，不会有非常高的read io，我之前也碰到过这个问题，自己探索了下 74 | 经核实：确实是因为指定id引起的。 75 | https://elasticsearch.cn/question/6526 76 | 77 | ## 1.8 增加索引个数能有效的提高写入效率吗？ 78 | -------------------------------------------------------------------------------- 79 | 如题， 80 | 现在ES集群是一个索引在写，后台15台物理机，48c，188G，是多线程同步写一个索引，看监控能到40W，再加并发也提高不了，但是机器的负载和线程池资源都还OK，我看线程池是index级别的设定，能通过增加写入索引个数来增加写入性能吧，还是说要扩容呢？ 81 | 82 | 写入及索引性能核心参考：https://www.elastic.co/guide/en/elasticsearch/reference/master/tune-for-indexing-speed.html 83 | 网上所有的书籍、文档基本都离不开链接给出的东西 84 | 85 | ## 1.9 Elasticsearch6.5.3全聚合出现与MySQL聚合结果不一致的问题 86 | -------------------------------------------------------------------------------- 87 | MySQL中的聚合语句： 88 | ``` 89 | select sum(adv_price) from report_2019_01 where report_time>=1546272000 and report_time<1546358400; 90 | ``` 91 | MySQL聚合结果是：11612.840 92 | 93 | 将上面时间的数据全部导入es中，并聚合： 94 | ``` 95 | "aggregations": { 96 | "revenue": { 97 | "sum": { 98 | "field": "adv_price" 99 | } 100 | } 101 | } 102 | } 103 | ``` 104 | Elasticsearch聚合结果是：9064 105 | 106 | 原因：浮点精度问题，类似相关问题都是浮点精度问题思路排查的。 107 | 108 | ## 1.10 如何对同一个字段进行不同的分词 109 | multi-fields 可以实现，也就是说一个字段可以设置多个子字段. 110 | 推荐视频：https://elasticsearch.cn/article/13274 111 | 112 | ## 1.11 es禁止*删除索引 113 | 1、永久修改——通过setting修改 114 | ``` 115 | PUT /_cluster/settings 116 | { 117 | "persistent": { 118 | "action.destructive_requires_name": "true" 119 | } 120 | } 121 | ``` 122 | 2、通过配置文件修改 123 | 建议通过1修改 124 | ## 1.12 怎样限定es查询返回数据最低分，低于XX分数的不要 125 | min_score参数 126 | ``` 127 | SearchResponse response = client.prepareSearch(INDEX_NAME) 128 | .setTypes(TYPE_NAME) 129 | .setQuery(queryBuilder) 130 | .setMinScore(minScore) 131 | .execute() 132 | .actionGet(); 133 | .setMinScore(minScore) 134 | ``` 135 | 136 | ## 1.13 想问下多个terms查询为何不起作用，有没有什么解决办法 137 | https://elasticsearch.cn/question/7342 138 | 问题原因：大小写问题 139 | 默认的standard analyzer包含lowcase token filter， 会把大写转换为小写，，如果一定要使用大写查询的话，可以自定义 140 | 141 | ## 1.14 关于translog和线程池拒绝 142 | 比如提交bulk，请求写入了translog，但是由于服务器压力大，线程池拒绝了这个请求，那translog还有用吗？ 143 | 回复：写translog是在写内存之后才会发生，如果出现拒绝是连内存还没写入就拒绝了，远没有到写translog, 144 | 可以看看这篇文章：https://zhuanlan.zhihu.com/p/34669354 145 | 146 | ## 1.15 es search为啥不用bloom filter？ 147 | 首先你需要了解布隆过滤器的用途，一般是用于字符串或者数字等，检测是否存在的场景，例如：爬虫的 URL 去重； 148 | 149 | ES 的查询，大部分场景是看某个文本是否存在与某篇文档中；或者日期、数字等是否在某个范围； 150 | 所以应用的方向不同，因此 ES 使用了倒排索引、KD数等其他数据结构实现了搜索 151 | 152 | ## 1.16 将文档存储在es外面，同时使es搜索结果只返回文档基本信息，这样做能否提高性能？ 153 | 问题描述： 154 | -------------------------------------------------------------------------------- 155 | 就是说，如果文档比较大，es把它作为搜索结果整个返回的时候，可能对es性能造成压力。 156 | 所以一个自然的想法就是，index时把文档整个存进es，同时把文档另存一份在其他专用的静态存储空间中，query时使es只返回文档基本信息，如id、timestamp等，再通过id来找到静态存储空间中的相应文档。 157 | 这样子能否对es性能有较大提升，实际应用中这样的使用模式多不多呢？ 158 | 159 | wood大叔回复：如果文档都非常大，静态存储方案廉价，能按照id，timestamp快速fetch回数据，那么这种方案未尝不可。 但是复杂性方面比全部放ES要高一些，应用层面多了一个依赖，也享受不到某些原生的ES特性，比如reindex。再就是静态存储通常也要是分布式的，维护也有成本。所以你还是要评估一下用`静态存储的话能省多少硬件`，如果省得不多，还不如将文档全部放ES里简单直接。 160 | 161 | bsll:理论上是可以的，用过es+hbase, es+couchbase的案例，不过楼上说的很对，得根据你的实际情况来。 162 | 163 | ## 1.17 sql中的 is null 和 is not null 在Elasticsearch的应用 164 | 建议源头出发，定义NULL. 165 | ``` 166 | PUT my_index 167 | { 168 | "mappings": { 169 | "_doc": { 170 | "properties": { 171 | "status_code": { 172 | "type": "keyword", 173 | "null_value": "NULL" 174 | } 175 | } 176 | } 177 | } 178 | } 179 | ``` 180 | ## 1.18 elasticsearch 删除不用的索引 怎么真正释放磁盘空间？ 181 | 比如 我创建了 course1 course2 course3 这些都是测试创建的索引 但是我用curl -XDELETE http://192.168.1.113:9200/course1 这样的命令将course1 2 3 分别删除 但是在 elasticsearch data 目录下文件并未释放磁盘空间 怎么操作才能删除之前不用的索引并释放磁盘空间呢 谢谢！！ 182 | 183 | 解决方案：https://elastic.blog.csdn.net/article/details/80038930 184 | 185 | # 2 Logstash 186 | ## 2.1 logstash 批量接收数据 187 | -------------------------------------------------------------------------------- 188 | 在logstash 中有没有办法使用 avro 接收数据，或者有没有其他方案能够接收flume 的avro sink 发来的数据 189 | 190 | 实现： 191 | ``` 192 | input { 193 | kafka { 194 | codec => avro { 195 | schema_uri => "/tmp/schema.avsc" 196 | } 197 | } 198 | } 199 | filter { 200 | ... 201 | } 202 | output { 203 | ... 204 | } 205 | ``` 206 | 207 | https://www.elastic.co/guide/en/logstash/current/plugins-codecs-avro.html 208 | 209 | ## 2.2 logstash中添加fielter grok之后怎么过滤多余的字段 210 | 保留message字段 211 | 参考如下： 212 | ``` 213 | filter { 214 | grok { 215 | remove_field => [ "foo_%{somefield}", "my_extraneous_field" ] 216 | } 217 | } 218 | ``` 219 | 220 | ## 2.3 logstash和es的template 221 | 问题描述： 222 | -------------------------------------------------------------------------------- 223 | logstash和es都指定了索引的模板, 那logstash采集数据到es时,以哪个模板为准呢 224 | 225 | 回复：两个模板会merge， 如果两个模板有相同的配置项，以模板order大的为准，不同的配置项则都会生效；建议设置一个单独的模板就行了，多个模板可能有问题。 226 | 建议：实际场景验证一下。 227 | 228 | ## 2.4 logstash数据监听 229 | 问题描述： 230 | -------------------------------------------------------------------------------- 231 | redis中的数据通过logstash直接入库到elasticsearch，项目使用的语言是java,目前的情况是，需要在elasticsearch中一有新数据，就要做一些其他的操作，不知道有没有什么方案，类似监听elasticsearch数据是否更新、增加的机制来实现 232 | 233 | 解决方案：elasticsearch alert有类似功能，可以看一下。 234 | 235 | # 3、Kibana 236 | ## 3.1 Kibana中有几个Dashboard，可否对每个Dashboard分配权限，使其能够开放给指定人群浏览？ 237 | space的出现的目的就是相同公司不同部门实现不同权限的。可以参考。 238 | 239 | ## 3.2 kibana dev tools中文输入有问题 240 | 这是kibana低版本的bug，高版本已经修复。kibana6.6已经不存在。 241 | 242 | 243 | -------------------------------------------------------------------------------- /es_accumulate/201904_report.md: -------------------------------------------------------------------------------- 1 | # 0、gc问题 2 | 最近elasticsearch日志总发现这种gc日志 才疏学浅es小白 慌得一比 3 | 求问各位大佬这样是有什么异常吗 https://elasticsearch.cn/question/7563 4 | 5 | 【wood大叔回复】 6 | 这种GC耗时长的日志出现，一般是集群GC压力比较大，耗时比较长。 原因则很多，需要结合其他集群的监控数据来分析，比方CPU占用率， Young GC/Old GC频率，heap占用百分比，查询耗时等等。如果heap占用率并不高，但是GC耗时高，通常是因为heap配置得比较大啊，遇到比较繁重的查询在执行的时候Young GC耗时比较长， 你可以先尝试将集群的GC从默认的CMS更改为`G1`，通常可以大幅降低GC的时延。 7 | 8 | 9 | # 1、同一条数据中的不同字段间是否可以创建父子关系？如果可以应该如何创建？ 10 | 我看大多数资料都是在写数据的时候注明指向的父子关系，我理解这种为对于不同数据写入同一索引采用的措施。 11 | 12 | 但是能不能对于 同一条数据中的不同字段，实现不同字段间的父子关系？ 比如数据中的部分字段内容都是出现率很高的重复内容，想实现将出现率较高的部分存在父关系内，变化频率高的保留在子关系中。达到一对多的映射关系！ 但是mapping中只看到了设置join datatype ，没有看到字段中有指定父子关系的配置，有哪位可以帮忙分析下，感谢 13 | 14 | 【回复】不可以。是针对不同document的。推荐查看：https://elastic.blog.csdn.net/article/details/79774481 15 | 你的使用可以借助nested实现。 16 | 17 | # 2、elastalert安装问题 18 | 通过git clone https://github.com/Yelp/elastalert.git 拉到了zip包，然后解压执行python setup.py install，但是总是安装不成功，提示ssl问题 19 | 20 | 【回复】手动通 pip install cffi==1.11.5 ，我之前遇到过 21 | 后面提示的python依赖模块缺失，都按照这个方式安装 22 | 23 | # 3、RestHighLevelClient采用rest方式，内部是长连接还是短连接？ 24 | 25 | transportClient方式我知道是长连接方式；RestHighLevelClient采用rest方式，是http请求链接，内部实现是长连接还是短连接？ 26 | 27 | 【回复】RestHighLevelClient一样是长连接，内部封装了CloseableHttpAsyncClient实例，每次请求都共享一个连接实例 28 | 29 | # 4、扩容后node加入不到集群中 30 | 【回复】检查一下 unicast 配置的节点是否正确，错误上面很明显提示没有连接上 master 节点。 31 | 32 | # 5、Elasticsearch 查询问题 33 | 34 | Elasticsearch查询的时候，报这个错误，网上没有找到原因，麻烦给看下： 35 | ``` 36 | {"error":{"root_cause":[],"type":"search_phase_execution_exception","reason":"","phase":"fetch","grouped":true,"failed_shards":[],"caused_by":{"type":"too_many_buckets_exception","reason":"Trying to create too many buckets. Must be less than or equal to: [1000] but was [1001]. This limit can be set by changing the [search.max_buckets] cluster level setting.","max_buckets":1000}},"status":503} 37 | ``` 38 | 39 | 设置：这是6.x版本才有的特性，目的：限制大批量聚合操作，规避性能风险。 40 | 解决方案：setting里设置：search.max_buckets 41 | 官网地址：https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-bucket.html 42 | 相关讨论：https://discuss.elastic.co/t/why-es-doesnt-stop-my-aggregation-but-just-crashes/148170 43 | github讨论：https://github.com/elastic/elasticsearch/pull/27581 44 | 45 | # 6、索引分片不能同步到新节点 46 | 47 | 原单个节点中的索引，映射类型为严格，索引中有字段是指定了ik分词器的。新部署了一台es，还没有装ik分词器插件就连入了集群中，索引分片在自动同步中报错。然后加入新节点此索引也不会自动同步了，求教大神，是不是索引同步失败导致es设置了该索引不再自动同步 48 | 49 | 【回复】用这个命令看看：GET _cluster/allocation/explain?pretty 50 | 51 | shard自动分配有一个最大重试次数，默认是5次。 52 | index.allocation.max_retries参数指定了最大重试次数。 53 | 54 | 使用 reroute 可重新路由。 55 | 56 | # 7、【多表关联】ES不同索引，不同字段之间如何进行联合查询，谢谢 57 | 比如我有两个索引A和B，A索引下面有个a.userid，B索引下面有个user_id，那么我该怎么查询当A.a.userid=B.user_id的值呢？就是类似于mysql的联表查询操作，但是索引名称和字段名称各不相同的那种。如果是先全文索引，然后操作数组的话，又担心查出来的数据太多，操作数组也不方便。 58 | 59 | 欢迎各位大佬的指导，提前拜谢 60 | 61 | 【回复】转变思维方式非常重要。ES和大多数的nosql相似，想要处理mysql这种关联关系还是有些强人所难了。 62 | 这里提供一篇博客贡大家观看思考，需要改变自己的思维方式了：（干货 | Elasticsearch多表关联设计指南） 63 | https://blog.csdn.net/laoyang360/article/details/88784748 64 | 65 | # 8、es的分片突然大批量重新分配？ 66 | 67 | es集群里面时不时的发生大量shard重新分配，节点状态由green变为red。查看节点的日志，发现master的日志里，有节点ping超时，将该节点提出了集群，而看该节点的日志，又显示ping master超时，发生master left事件，过了几毫秒又重新detect_master。其实节点都没有离开，用_cat/nodes，都可以看到，这是什么原因呢？ 68 | 69 | 之前讨论过类似问题。 70 | 【回复】 71 | 设置分片延迟分配策略： 72 | ``` 73 | PUT _all/_settings 74 | { 75 | "settings": { 76 | "index.unassigned.node_left.delayed_timeout": "5m" 77 | } 78 | } 79 | ``` 80 | # 9、 es5.5版本,请问搭建3台机器的机群,那么在logstash当中怎么写es的地址? 81 | 搭建了一个es的机群,3台,请问怎么对外提供服务呢?我在logstash的数据写入es的时候,怎么写es的地址, 82 | 之前是一台的时候,写入的是192.168.10.20:9200,这是一台的时候,现在有3台了,怎么写,怎么负载均衡? 83 | 84 | 【确认】 85 | 多个ip:port以逗号分隔；可以用nginx实现负载均衡 86 | ``` 87 | output { 88 | stdout { codec => rubydebug } 89 | elasticsearch { 90 | hosts => ["10.12.25.110:9200","10.12.25.112:9200","10.12.25.97:9200"] 91 | index => "hello" 92 | } 93 | } 94 | ``` 95 | 96 | # 10、 用logstash-jdbc怎么从mysql导入到elasticsearch指定的字段中去 97 | 98 | mysql的表一共有40个字段,elasticsearch的索引有90个字段,如何让mysql的字段导入到指定的elasticsearch字段里去 99 | 100 | 【回复】 101 | 方式1：使用logstash filter 或者用es的ingest pipeline，都可以实现 102 | 方式2：借助sql的别名也可以了实现 103 | 104 | # 11、 logstash.outputs.elasticsearch 提示pressure too high, rest bulk request circuit break 105 | 106 | 我们最近查询日志经常提示 107 | B2F413D2-B116-4867-81A3-86FCC0060C01.png 108 | 而且查询的数据有重复的，部分数据丢失，一部分数据原数据文件里面有但是es上没有。而且看logstash上记录的日志也是一直在报错 109 | 我们是使用的filebeat采集数据通过logstash发送给es的，上面的日志是logstash服务器的日志。elastic有你说的这种异常熔断功能吗？ 110 | 111 | 【回复】是用的腾讯云的ES？腾讯云的ES在内核层面内置了异常熔断的功能。当集群jvm堆内存old区占比比较高的时候，为了保证集群的稳定性，会梯度的拒绝一部分请求。 112 | 113 | 熔断功能参考：https://www.elastic.co/guide/en/elasticsearch/reference/6.4/circuit-breaker.html 114 | 115 | 116 | # 12、kibana6.7版本开发框架 117 | 【Medcl确认】React + EUI 118 | 119 | # 13、 kibana怎么关闭monitoring 120 | 121 | 意外点开了。之前用es2.2的时候，用过这个功能，自己的index还没监控的index大，所以不想让它一直监控 122 | 123 | 【确认】 124 | 已经解决了：官网有方法 ，自己没仔细找 125 | ``` 126 | PUT _cluster/settings 127 | { 128 | "transient": { 129 | "xpack.monitoring.collection.enabled": false 130 | } 131 | } 132 | ··· 133 | persistent也行 134 | 135 | 铭毅天下——Elastic基础、进阶、实战第一公众号 136 | -------------------------------------------------------------------------------- /es_accumulate/201906_report.md: -------------------------------------------------------------------------------- 1 | # 1、Transport Client 为什么会被标记成过期项目？ 2 | 大概的原因就是版本，序列化，兼容性，作为客户端却需要有大量服务端的强依赖。 3 | https://www.elastic.co/cn/blog/state-of-the-official-elasticsearch-java-clients 4 | 5 | # 2、有elasticsearch6.X join聚合 java代码实现 查询执行与kibana Dev Tools 运行结果不一致 6 | 【回复】 7 | 排查思路：1、打印出dsl，对比下核心不同。 8 | 2、不同的地方就是代码业务逻辑可能出问题的地方。 9 | 10 | 基础认知： 11 | 1、检索的时候，由于副本的差异或者刷新refresh_interval的影响，导致返回结果可能不一致，属于正常现象。 12 | 2、解决方案：加参数:perference，或者自定义路由策略，写入和检索使用相同路由。确保完全一致。 13 | 14 | # 3、es客户端性能差异？ 15 | 16 | transport客户端 > REST客户端 = High Level客户端 17 | transport客户端 是 TCP 直接访问会比 REST 的 HTTP 更快一些，但是差距不大（差距在 10% 之内） 18 | High Level 是对 Rest 的封装，性能没什么区别 19 | 20 | # 4、热更新同义词 21 | 现在有个需求需要热更新同义词,即不重启es更新同义词,找了好久没找到相关资料,各位大佬有什么好的方案.谢谢 22 | 23 | 参考项目：https://github.com/bells/elasticsearch-analysis-dynamic-synonym 24 | 25 | # 5、【常见错误】使用Java rest-high-level-client查询文档时，from+size大于100000,报各种错 26 | 27 | 阿里云专家回复： 28 | 深度翻页问题，建议通过scroll或search_after解决。 29 | Search After 30 | 31 | Elasticsearch: 权威指南 » 游标查询 Scroll 32 | 33 | 1、内存太小了，内存建议：Min（物理机内存，31GB）； 34 | 2、from+size大于100000， 建议修改：max_result_window窗口值大小。 35 | 3、建议看一下官网的建议： 36 | index.max_result_window 37 | The maximum value of from + size for searches to this index. Defaults to 10000. 38 | Search requests take heap memory and time proportional to from + size and this limits that memory. 39 | See Scroll or Search After for a more efficient alternative to raising this. 40 | 41 | 网友讨论：问题回复： 42 | 1. scroll api之前就试过，但是没办法满足要求。客户需要无规则的翻页。scroll在查询大文档的时候，性能仍然不是很好 43 | 2. search_after暂时也不用，综合考虑还是from+size方便 44 | 3. elasticsearch集群每个节点是8核16G的，在高的话，甲方不给。硬件也是没办法。qaq。不过集群是用docker+k8s部署的，方便做横向扩展。这点还可以。目前6-8个es节点 45 | 4. 针对集群，我进行的二次开发，用java rest-high-level-client写了一个符合我们要求的日志查询接口，以及集群监控接口。 46 | 说内存溢出业主要是我自己写的这个项目。跟elasticsearch集群本身的内存，没太大关系 47 | 48 | 解决办法： 49 | 1. 由于自己写的项目，在返回大量日志时，出现内存溢出情况（要求from+size查询10万条而不是官网建议，这个真没办法） 50 | 分页获取日志文档，每次返回5000条，然后在将数据进行拼接，最后返回了数据。 51 | 52 | 53 | # 6、多索引查询如何优化查询效率 54 | 55 | 按月将数据分成了多个索引，然而查询时，需要查询多个月的数据，这时发现就算是简单的查询，效率也不是很高。请问有没有好的优化方向？ 56 | 57 | 既然已经按照日期进行划分，对于历史数据（原则上不会再写入数据的），可以考虑： 58 | 1、forcemerge操作， 把分段大小设置为1， 以提升检索效率。 59 | 2、冷热数据架构机制，参考：https://www.elastic.co/cn/blog/hot-warm-architecture-in-elasticsearch-5-x 60 | 61 | 其他维度的考量-官网优化检索建议：https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-search-speed.html 62 | 63 | 建议：先定位慢的原因出在哪里？ 是配置、硬件、复杂查询的问题？还是其他。 64 | 推荐慢时间查询阅读：https://elastic.blog.csdn.net/article/details/83048087 65 | 66 | # 7、使用 IK 中文分词插件，当查询某些关键字的时候查询不到数据，请问问题出在哪里？ 67 | 68 | https://elasticsearch.cn/question/7777 69 | 70 | 问题已经解决。 71 | IK分词器主要有两种：ik_smart、ik_max_word,根据需求在创建索引的时候指定全局默认索引，或者在设置doc的单个属性的分词器。 72 | 问题：第二张图上指定的分词器不好使，还会导致其它的词条查不到数据的情况 ，具体原因需要再查。 73 | 解决办法：因属性比较简单，数据量小，所以重建索引，重新同步数据，设置索引的默认分词器，设置一切正常了。 74 | http://191.168.2.55:9200/order_index/{ 75 | "settings" : { 76 | "index" : { 77 | "analysis.analyzer.default.type": "ik_max_word" 78 | } 79 | } 80 | } 81 | 82 | # 8、high level 嗅探 83 | 84 | 嗅探可以配置在low level rest client 85 | https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current/java-rest-high-getting-started-initialization.html 86 | 通过low level rest client初始化high level rest client 87 | https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current/_usage.html 88 | 89 | # 9、jvm优化后好的飞起 90 | 91 | 优化方案：我用的是G1GC ，而且我整个堆给了31个G 92 | 93 | jvm.option文件中加入了一个-Xmn1g之后就从二十多个g变成了稳定3g左右 94 | 以后会突发异常吗 这个原理是怎么回事 95 | 96 | https://elasticsearch.cn/question/7779 97 | 98 | 参考讨论：https://elasticsearch.cn/question/7381 99 | 100 | # 10、filter对suggest起不到过滤作用 101 | 102 | 做suggest的时候，想取状态为1的数据，但是，按照下面的写法，状态为-1的数据也取出来了，代码如下，如果不是这样写，应该怎样写呢？ 103 | ``` 104 | GET pro_suggest/doc/_search 105 | { 106 | "query": { 107 | "term": { 108 | "status": { 109 | "value": 1 110 | } 111 | } 112 | }, 113 | "suggest": { 114 | "title": { 115 | "prefix": "best", 116 | "completion": { 117 | "field": "title", 118 | "size": 10 119 | 120 | } 121 | } 122 | } 123 | } 124 | ``` 125 | 126 | 【Me的处理回复】suggest 本来就没有过滤功能的哈，suggest 里面基于的基本的 term 构建的FST，只是负责快速找到相似的查询。 127 | 你如果需要过滤，可以写一个bool 查询来查询 title，结合 prefix 查询和 term 查询进行过滤，效果差不多。 128 | 129 | # 11、filebeat启动太慢 130 | 131 | registry有10000条日志文件的state数据，如果不删除这个文件，filebeat启动的时候要检测每个日志文件的state，导致启动太慢，请问有什么方法解决 132 | 133 | https://www.elastic.co/guide/en/beats/filebeat/current/faq.html#reduce-registry-size 134 | 135 | # 12、一个filebeat如何将数据输出到多个elasticsearch集群，保证两个集群的数据一致（起到备份作用） 136 | 137 | 1. 需求是需要将filebeat收集的日志，输出的两个elasticsearch集群中。并且保证两个集群中的数据都是一样的。 138 | 139 | 2. 测试 140 | 配置 141 | output.elasticsearch: 142 | hosts: ['192.168.223.26:9200','192.168.223.27:9200'] 143 | 并不能实现需求，原因是官网上介绍说，这个是安装循环顺序往两个集群中写入数据。因此最终结果是，一份数据被写到了两个不同的集群中。两个集群的数据，完全不同。 144 | 145 | 3. 求问，有没有什么办法实现，filebeat将一份数据同时写到两个elasticsearch集群中去。 146 | 147 | https://github.com/medcl/elasticsearch-proxy 148 | 试试medcl写的这个代理，可以实现双写 149 | 150 | 151 | ——铭毅天下 20190704 152 | -------------------------------------------------------------------------------- /es_accumulate/201908_report.md: -------------------------------------------------------------------------------- 1 | # 1、记一次“访问量超过1000的人数”统计，计算聚合桶的个数 2 | ES在使用过程中，我们公司有一个需求，就是需要统计活跃用户数， 3 | 我们定义活跃用户数为：今日访问量超过1000的用户，所以我们统计活跃用户数的时候需要统计“访问量超过1000的人数”。 4 | 5 | https://elasticsearch.cn/article/13435 6 | 7 | # 2、【分片分配问题】主分片全部在一个节点上，要怎么处理 8 | 求助！共4台data节点，但是分片分布不均匀，主分片全在一台节点上， 9 | 其他几台只有几个副本，造成一台机器的储存占用过高，如下图所示，这个问题要怎么处理呢。 10 | 11 | 回复：设置一下index.routing.allocation.total_shards_per_node 12 | 13 | https://elasticsearch.cn/question/8052 14 | 15 | # 3、【不建议的操作】直接移动index，分片状况为红色 16 | 移动data目录下nodes下的indees中的某个，get _cat indices时，这个索引的分片的状态为红色。 17 | 移动整个nodes没有问题，什么原因？ 18 | 怎么才能修复，或者怎么才能通过移动文件的方式，移动某个indices的数据 19 | 20 | 铭毅回复：Elasticsearch设置数据文件、段文件、translog等，所以：单独移动文件是下下策。 21 | 可以考虑：快照、reindex方式实现数据迁移。 22 | 23 | 如果真要移动文件，可以参考medcl之前的实践分享： 24 | 25 | 相同问题：不建议如下操作—— 26 | 将一个旧的es数据(400多G)迁移到新的es中的时候直接将旧es的data目录下indices文件拷贝到新es的data下(大概花了一个晚上)， 27 | 这种做法是否可取？ 28 | https://elasticsearch.cn/question/8165 29 | 30 | 相似问题：存储数据，data目录从一个机器直接移到一台新的机器是否可以直接使用？ 31 | 存储数据，data目录从一个机器直接移到一台新的机器是否可以直接使用？ 32 | 当前节点迁移（原来的集群数据迁移到新节点的集群），当前有什么好的方案？ 33 | （跨集群迁移功能由于license问题，不能使用。） 34 | 35 | https://elasticsearch.cn/question/8178 36 | 37 | # 4、elasticsearch配置文件里seed_hosts以及initial_master_nodes解释 38 | 39 | 最新版的es配置文件里有两项配置：discovery.seed_hosts和cluster.initial_master_nodes。 40 | 阅读了es官网上的一些解释，也搜索了网上的一些解释，还是感觉有点疑问。 41 | 求哪位高人给指点一下，分享下对这两项的理解呢？多谢！ 42 | 43 | 回复： 44 | - discovery.seed_hosts 的来龙去脉： 45 | 6.X 5.X对应名字：discovery.zen.ping.unicast.hosts。 46 | 对比：除了名称不同，释义部分一模一样。 47 | 再看看7.0版本升级说明： 48 | 1）https://www.elastic.co/guide/en/elasticsearch/reference/7.0/breaking-changes-7.0.htm 49 | 如果多节点集群，discovery.seed_hosts 应该配置为候选主节点，让es节点能正确地加入集群。 50 | 51 | - cluster.initial_master_nodes的来龙去脉 52 | 这也是7.X的特性，区别于之前设置min_master_count候选主节点的个数。 53 | 白话文：设置候选主机节点的主机名称列表。 54 | 当第一次启动全新的Elasticsearch集群时，会出现一个集群引导步骤，该步骤确定在第一次选举中计票的主要合格节点集。 55 | 您在生产模式下启动全新集群时，必须明确列出符合条件的节点的名称或IP地址，这些节点的投票应在第一次选举中计算。 56 | 使用cluster.initial_master_nodes设置设置此列表。 57 | initial_master_nodes不设的话，集群会默认把第一个启动的当master，其他节点也会去局域网里搜+选主， 58 | 但是这样比较危险（可能脑裂或者卡在仲裁投票的状态时间太长之类的）， 59 | 所以建议你把有选主资格的节点放里面，这样就不会浪费那么多时间、资源了。 60 | 61 | https://elasticsearch.cn/question/8037 62 | 63 | # 5、ES6.3.2 五节点集群想新增一台机器作冷节点数据备份，担心分片迁移问题，求教？ 64 | 问题比较长，建议查看原文链接： 65 | https://elasticsearch.cn/question/8056 66 | 67 | # 6、【分片分配】如果集群设置了 cluster.routing.allocation.enable:none，执行创建索引会怎么样？ 68 | ``` 69 | PUT test_index 70 | { 71 | "settings": { 72 | "index":{ 73 | "number_of_replicas" : 0, 74 | "number_of_shards": 1 75 | } 76 | } 77 | } 78 | ``` 79 | 会阻塞直至超时。 80 | 这个时候，test_index 是创建成功了的。 81 | 但是，test_index的分片无法分配。因此，集群的状态会变成Red。 82 | 83 | https://elasticsearch.cn/question/4407 84 | 85 | # 7、docker部署es集群 推荐 86 | https://github.com/bindiego/docker_images/tree/master/elastic 87 | 88 | # 8、【嵌套聚合-常见问题】elasticsearch嵌套聚合问题 89 | 90 | 在elasticsearch中能否实现这样的场景： 91 | 1.根据字段A分组，同时获取字段B的最大值max（B） 92 | 2.获取字段B的值为max（B）的记录的集合C 93 | 3.对集合C进行聚合 94 | 95 | 回复： 96 | 下面这个就是你说的场景，是可以实现的，下面是对li字段进行分组，取cost最大的值，然后对最大的cost集合进行求和聚合。 97 | ``` 98 | { 99 | "aggs": { 100 | "3": { 101 | "sum_bucket": { 102 | "buckets_path": "3-bucket>3-metric" 103 | } 104 | }, 105 | "3-bucket": { 106 | "terms": { 107 | "field": "li.keyword", 108 | "size": 5, 109 | "order": { 110 | "_key": "desc" 111 | } 112 | }, 113 | "aggs": { 114 | "3-metric": { 115 | "max": { 116 | "field": "cost" 117 | } 118 | } 119 | } 120 | } 121 | }, 122 | "size": 0, 123 | "query": { 124 | "bool": { 125 | "must": [ 126 | { 127 | "range": { 128 | "x_st": { 129 | "gte": 1565625600000, 130 | "lte": 1565711999999, 131 | "format": "epoch_millis" 132 | } 133 | } 134 | } 135 | ] 136 | } 137 | } 138 | ``` 139 | https://elasticsearch.cn/question/4799 140 | 141 | # 9、求教如何在索引阶段禁用大写转小写操作 142 | 143 | 问题：各位伙伴好，场景如下： 144 | 我现在有一个字段，这个字段可能存储汉字、也可能存储英文字母、数字或它们的组合，我现在使用的是ik_smart，它可以比较好的对付中文，但是对于英文，它基本上是按ES默认的lowercase把英文全部转成小写了。 145 | 146 | 但是我的查询，对大小写是敏感的，所以有没有什么办法，既可以保留对中文的较好切分，又可以针对英文，唯独禁用小写转化呢(其他的诸如按照空格切这种默认的还是得保留)？ 147 | 148 | 我现在的办法是使用multi fileds，大小写敏感的时候就查keyword，但是总觉得这样挺麻烦，有没有能在索引阶段，通过添加过滤这种方式解决的办法呢？ 149 | 150 | 【回复】 151 | ``` 152 | { 153 | "settings": { 154 | "analysis": { 155 | "analyzer": { 156 | "my_ik": { 157 | "type": "ik_smart", 158 | "enable_lowercase": false 159 | } 160 | } 161 | } 162 | } 163 | } 164 | ``` 165 | 基于ik_smart自定义analyzer, 同时配置参数 "enable_lowercase": false 166 | 167 | # 10、求教如何限制查询匹配中的“距离”？ 168 | 我的情景是这样的： 169 | 170 | 用户需要我使用pinyin进行一个全文检索，我在使用pinyin分词器后，发现了一个问题... 171 | 比如我要查询xinbeishi(新北市)，那么返回的结果中，可能错误的包含诸如“新华路北区联合超市”这种奇怪的数据。 172 | 我可以理解这是因为该数据中分别包含了xin、bei和shi的拼音，因此在切词匹配倒排时，把该值也错误的匹配了出来。 173 | 在查询的时候不切词也是不行的，因为用户的需求，需要liudehua和dehua liu都能查到“刘德华”，所以查询时必须切词。 174 | 我想请教各位前辈，有没有什么查询方法，可以限制不同匹配值之间的距离，以此来避免当不同字相距过远也返回的情况 175 | 或者有没有其他方法可以解决我的问题呢？ 176 | 177 | 回复：最大间隔距离是slop参数，但是只有match_phrase 或者7.x版本的span查询支持slop吧。 178 | 179 | 简单介绍一下 180 | match_phrase是把查询的词先分词成一个或者多个term，然后按照slop（默认是0，也就是多个term必须紧邻）确定多个term之间的最大移动距离来返回结果. 181 | 如果 刘德华 被拆成 liu de hua 三个term，使用match_phrase查询 德华刘，slop为0时可以不会返回结果，但是slop为2时能查到刘德华这条记录 182 | 183 | 【注意】 184 | 对于拼音，不能像英文可以用模糊查询的编辑距离去做调整。因为拼音本身是一个词语，修改/替换一个字符没有意义。 185 | 提供一个思路。搞一个keep_joined_full_pinyin为true的自定义拼音分词器，不切词，只保留全拼音，例如新北市-> xinbeishi, 搞一个字段用这个分词器解析。第一次用prefix查询这个字段，只召回新北市。如果没有召回，再查询默认pinyin分析其解析的字段。这样也能满足liudehua, dehua liu都召回刘德华的情况。 186 | 187 | # 11、ElasticSearch如何做数据迁移？ 188 | 离线全量迁移有很多种方法：elasticdump, reindex, logstash, snapshot; 189 | 在线迁移的话可以使用X-PACK的CCR功能， 190 | 或者把老集群与新集群融合成一个集群，迁移分片到新集群节点上后再剔除掉老的节点 191 | 192 | # 12、同一个分片的主分片和副本分片数据大小不一样 193 | 194 | 请教一个问题 ，对es查询时，同一个文档，每次查询的得分不一样，总是在两个值之间来回切换， 195 | 然后我看了下es中的分片数据，同一个分片的主分片和副本分片数据大小不一样。。 196 | 这个是为什么？ 197 | 198 | 回复：可能是因为用户删除了部分文档，之后主分片进行了merge， 而副本分片没有进行merge。 这种情况下主分片和副本分片上的总文档数量就会不同，打分时计算出的IDF的值不同，最终得到了不同的得分。 199 | 200 | 参考：https://www.jianshu.com/p/6de54ebf296b 201 | https://elasticsearch.cn/question/8187 202 | 203 | # 13、【脚本】数组里包含对象能否用script删除？有没有其他方法？ 204 | 因为需求改动，必须要去删除一个数组的其中一个对象。 205 | 想过先查到，然后到后台循环匹配，移除后再updateByQueryyQuery进行更新。 206 | 不知道有没有其他方法更新？ 207 | 例子: 比如我要删除这个字段里面id为1的车子对象。 应该怎么操作？ 208 | ``` 209 | cars:[ 210 | { 211 | color:'white', 212 | size:'big', 213 | id:'1' 214 | }, 215 | { 216 | color:'white', 217 | size:'small', 218 | id:'2' 219 | } 220 | ] 221 | ``` 222 | 解决方案： 223 | 用script processor试试？ 224 | script-processor:https://www.elastic.co/guide/en/elasticsearch/reference/7.3/script-processor.html 225 | 226 | 大概这个意思，你自己debug一下优化一下 227 | ``` 228 | { 229 | "script": { 230 | "lang": "painless", 231 | "source": "ctx.cars = ctx.cars.stream().filter(x -> !x.id.equals('1')).collect(Collectors.toList())" 232 | } 233 | ``` 234 | 235 | # 14、多音字分词不准的问题 236 | 你好，medcl，最近在测试拼音分词器，我使用的版本是6.8.1，会出现多音字分词不准的问题，如银行分词成yinxing，会计分词成huiji，请问这个如何解决呢 237 | 238 | 回复：这个问题我也遇到过，这个你要清理下nlp-lang包下的字典，有不少垃圾在这个字典里 239 | 240 | # 15、Elasticsearch中一个索引文档里最多可以有多少个字段？ 241 | 242 | index.mapping.total_fields.limit 243 | The maximum number of fields in an index. Field and object mappings, as well as field aliases count towards this limit. The default value is 1000. 244 | 245 | https://www.elastic.co/guide/en/elasticsearch/reference/7.2/mapping.html 246 | 247 | # 16、在es的pattern/mapping里添加了message字段，为什么值为空？ 248 | 249 | 问题：filebeat+elasticsearch+kibana6.5.4 250 | 用filebeat采集nginx日志，用自带的module/nginx解析日志，期望能在kibana看到解析之前完整的message，于是在模板的mapping里添加mesage字段，但是在kibana上看到nginx.access.message的值为空，请问应该如何配置才能看到解析前的日志？ 251 | 252 | 【回复】：看了你的另外一个帖子，我觉得有必要说一下filebeat是如何工作的。 253 | 254 | filebeat收集信息，不进行加工，在传给es的时候会调用es的_ingest的pipeline，比如你的Nginx的pipeline，加工之后存到索引中。 255 | 256 | 在另外一个帖子中你也看到了remove那段代码，这里我猜测你修改了filebeat的那个文件，但是没有修改es中对应的pipeline，导致在数据处理的时候依然把message这个字段移除掉了。 257 | 258 | 因此建议你检查一下pipeline，然后修改它，再测试一下效果，希望能帮到你 259 | 260 | # 17、【推荐】kibana插件开发教程 261 | https://kibana.gitbook.io/kibana-plugin-development-tutorial/ 262 | 263 | -------------------------------------------------------------------------------- /es_accumulate/201909_report.md: -------------------------------------------------------------------------------- 1 | # 1、Elasticsearch 聚合不准确 2 | 3 | 回复： 4 | 1.聚合本来就是不精确的。 5 | 6 | 看一下官方解读： 7 | 8 | As described above, the document counts (and the results of any sub aggregations) in the terms aggregation are not always accurate. 9 | https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html 10 | 11 | 2.如何更精确的实践方法： 12 | 13 | 方案1：设置主分片为1。注意7.x版本已经默认为1。 14 | 15 | 适用场景：数据量小的场景。 16 | 17 | 方案2：设置shard_size为比较大的值，官方推荐：size*1.5+10 18 | 19 | 适用：数据量大的场景。 20 | 21 | 方案3：早期版本中，我曾经将size设置为2的32次方减去1也就是分片支持的最大值，来解决精度问题。 22 | 23 | 原因：1.x版本，size等于0代表全部，高版本取消0值，所以设置了最大值。 24 | 适用场景：不推荐使用了。 25 | 26 | # 2、logstash gork 匹配自动换行日志 27 | 28 | 评价：实际业务可能会用到：https://elasticsearch.cn/question/8237 29 | 30 | 已经解决了，使用multiline，将每行日志都进行合并,在进行匹配 31 | ``` 32 | input { 33 | file { 34 | path => "/tomcat-/logs/cat-log/log_total.log" 35 | type => "tomcat" 36 | start_position => "beginning" 37 | codec => multiline { #使用multiline插件，整合日志 38 | pattern => "(.*请求URL.*) | (.*请求IP*.) | (.*请求方法*.) | (.*请求参数*.) | (.*接口耗时*.) | (.*返回参数*.) | (.*ERROR*.) | (.*-$)" 39 | negate => true 40 | what => "previous" #如果无法匹配，为上一行 41 | } 42 | } 43 | } 44 | ``` 45 | 46 | # 3、面试题：elasticsearch 一个数字如何设置mapping，为什么？ 47 | 48 | 考察对lucene底层数据存储结构的了解程度，看看吴大叔的文章吧https://elasticsearch.cn/article/446 49 | 50 | 铭毅观察： 51 | 考察点1：根据业务场景斟酌精度问题，没必要都是long或者高精度的double。 52 | 考察点2：实际业务场景是不是检索，可以考虑：keyword类型。 53 | 54 | # 4、idea源码调试的问题 55 | https://elasticsearch.cn/question/8243 56 | 57 | 回复： 58 | 我的环境是jdk12, idea2019.2 mac elasticsearch6.7。 比较奇怪的是启动后IDE并没有帮我打印出来启动参数，挺费解的。 59 | 我是后来自己写了一个主函数执行，发现xmx后面的单位用大写貌似有问题读不到。。。尴尬。 60 | 61 | 其实最麻烦的是后来找不到类的那个问题，这个问题我解决了两天。。 62 | 包括你用的这个方法 Edit Configurations ，给 Include dependencies with Provided scope 打上勾 我也试了，没有效果。后来特地查了下这个东西的作用，结合gradle的打包配置尝试修改了下plugin那个模块的生命周期发现有效。 63 | 64 | # 5、【推荐】一键部署高可用 Elasticsearch 集群 65 | 66 | https://elasticsearch.cn/question/8258 67 | 68 | 分享一套简化 es 集群部署的工具，支持多种模式部署（测试集群模式、线上集群模式、多机房模式等），可快速部署生产级别可用的集群。 69 | 70 | 一个命令就可以完成全部部署工作，并支持多套集群混合部署，提高机器利用率。 71 | 72 | 项目采用 ansible 开发，不需要在服务器上预先安装客户端，只需要有 ssh 连接权限即可。 73 | 74 | 已在大厂经过长时期验证。欢迎大家使用。 75 | 76 | 项目地址：https://github.com/bluecll/es-easy-setup 77 | 78 | # 6、Logstash设置queue.type为persisted 79 | 80 | 描述：如下面的代码，我部署的是最简单的es+logstash+kibana模式，在logatash的pipelines.yml中，设置了管道的属性，指定持久化以启用持久性队列，我发现logtash在/data下自动创建了该管道的文件夹。 81 | 82 | - pipeline.id: test 83 | pipeline.workers: 8 84 | path.config: "./config/ltest.conf" 85 | queue.type: persisted 86 | 87 | 88 | 问题1：那么logstash是会在当前文件夹中，另外存储一份日志数据吗？ 89 | 90 | 回复：当前文件夹会暂存当前正在处理的数据，当成队列使用，即input已经取到该数据，而filter和output还没处理的数据。 91 | 92 | 问题2：如果logstash传输到es前，另外存储了一份数据，它会在传输给es后自动删除吗？ 93 | 回复：会自动删除。 94 | 95 | # 7、Elasticsearch 线程池问题 96 | 97 | ES版本： 6.7.2 98 | 99 | 最近在看ES 的thread_pool的配置，然后这里有两种thread_pool感觉有点不清楚： 100 | Write：For single-document index/delete/update and bulk requests. 101 | index：For index/delete operations. 102 | 我感觉这两个线程池是不是有重合的地方，还是我理解的不对。然后我在网上找了区别： 103 | 104 | In 6.x the WRITE threadpool is used for shard-level bulk and resync replication operations. The INDEX threadpool is used for other update, delete, and indexing operations. 105 | 106 | 上面的解答和我的理解有点不一样，所以请教一下各位。 107 | 108 | 回复： 109 | write 在6.3版本之前叫bulk，主要就是处理bulk 和 resync 请求，也就是批量处理 110 | 111 | index 是处理 单文档的 增删改 112 | 113 | 7.0的时候把index去掉了，因为这个版本以后单文档的请求也通过bulk执行 114 | 115 | # 8、springdata中ElasticsearchTemplate的startScroll是不是不支持高亮？ 116 | 117 | scroll确认可以的。 118 | ``` 119 | POST /message_infos-08/_search?scroll=1m 120 | { 121 | "size": 100, 122 | "query": { 123 | "match" : { 124 | "content": "北京" 125 | } 126 | }, 127 | "highlight": { 128 | "fields": { 129 | "content": {} 130 | } 131 | } 132 | } 133 | ``` 134 | 135 | # 9、如何删除_id名称为%{id}的文件 136 | 137 | 铭毅备注：经常出现在实际开发中。 138 | 解决方案: 139 | url encoding编码一下就可以了。 140 | curl -XDELETE http://localhost:9200/test111/ ... retty 141 | 142 | 143 | 实测有效： 144 | ``` 145 | curl -XDELETE http://localhost:9200/test111/ ... retty 146 | { 147 | "_index" : "test111", 148 | "_type" : "doc", 149 | "_id" : "${id}", 150 | "_version" : 4, 151 | "result" : "deleted", 152 | "_shards" : { 153 | "total" : 2, 154 | "successful" : 2, 155 | "failed" : 0 156 | }, 157 | "_seq_no" : 3, 158 | "_primary_term" : 1 159 | } 160 | [size=13] 161 | [/size] 162 | ``` 163 | 164 | # 10、求ELK6.X 开源告警方案 165 | 166 | 1、go-elasticalert 167 | https://github.com/morningconsult/go-elasticsearch-alerts 168 | 169 | 2、elasticAlert 170 | https://github.com/Yelp/elastalert 171 | 172 | 3、sentinl 173 | https://github.com/sirensolutions/sentinl 174 | 实测：可以对接邮件ok。 175 | 176 | # 11、elasticsearch怎么把两个字段放在一个桶里聚合去重？太难了... 177 | 178 | 考虑下对数据的预处理， 179 | 比如1：借助：copy_to 字段：https://www.elastic.co/guide/en/elasticsearch/reference/current/copy-to.html 180 | 比如2：借助：ingest 字段整合 181 | 182 | 去重的话借助： 183 | 1、cardinality 184 | 2、top_hits聚合 185 | 3、collapse折叠 186 | 187 | https://blog.csdn.net/laoyang360/article/details/79905676 188 | 189 | # 12、ES 7.X 版是如何防止腦裂發生 190 | 不好意思，請問ES 從 7 開始移除了minimum_master_nodes 參數，移除後是如何防止腦裂的狀況發生，我看了蠻多文章，不知道有沒有比較簡單的說明好理解，感謝! 191 | 192 | 新的 zen2 自动处理了，会根据当前集群的情况，自动调整所需的最小 master 节点数。 193 | 194 | # 13、多条件多维度查询 195 | 196 | 有个业务场景，关系数据库中涉及的表有7个左右（表结构互不相同），平均每个表的数据量在500W左右，通过ES对这7个表数据做多条件、多维度的组合查询,包含聚合后按照数量查询（聚合目前是在应用程序中计算后写入ES）。该场景下在ES创建中对这7张表创建了nested结构的索引来实现需求，但发现该模式下扩展性太难，后续要加入新的表作为组合条件，很难实现。问下各位大神，有没有更好的方案支持该场景下的查询，要求查询响应快、扩展性高。谢谢 197 | 198 | 铭毅评论：实际中问的最多的问题之一，不要用关系型数据库的数据思维去使用Elasticsearch！ 199 | 200 | 个人的理解:ES很多性能很强，用到关联关系的表需要慎重；严重影响到性能;一般多表查询的处理策略有4中： 201 | 202 | 1.建多个库，手工代码做关联； 203 | 204 | 优点：各表相互独立，扩展容易； 205 | 206 | 缺点：业务逻辑都需要自己处理，关联层数多，数据量大的搜索不适合。 207 | 208 | 2.宽表,合并所有的字段; 209 | 210 | 优点:关联关系搜索方便，而且数据量大不影响； 211 | 212 | 缺点：极不容易扩展，删除和更新复杂，很难维护；单文档容量大，有效字段比率少，影响IO性能； 213 | 214 | 3.父子文档：有层次关联的做父子文档; 215 | 216 | 优点:可以做层次关系的关联，而且不用关联的时候相互独立，增加修改删除方便； 217 | 218 | 缺点：关联关系也是昂贵的开销，影响性能； 219 | 220 | 场景：能够用于增删频繁的，查询少的业务； 221 | 222 | 4.nested嵌套，相当于一个java中字段为list对象， 223 | 224 | 优点:查询性能好，没有很大关联关系的开销； 225 | 226 | 缺点：单文档大，增加修改删除，很频繁不合适； 227 | 228 | 场景：适合用于很少对表做修改的业务； 229 | 230 | ES多表查询， 231 | 第一：需要分析业务: 表的关联关系,每个表的增删状况，查询的的复杂程度，每个表的数据量级； 232 | 第二：多表方案选项,跟1的业务息息相关； es都能做，但是都不强，需要自己挑一个最合适的； 233 | 第三：后期维护方案：数据量的扩展，数据增删；能达到一个什么量级，这也关系到多表的选型方案； 234 | 235 | 一般上面,宽表和单表，大多数业务不适合，不建议使用；父子文档和嵌套，选型区别是：1. 修改频繁用父子文档，不频繁的用嵌套；2. 经常需要关联查询，优选嵌套；偶尔用一下关联用父子文档； 236 | 237 | 推荐：https://blog.csdn.net/laoyang360/article/details/88784748 238 | 239 | # 14、生产环境的ELK版本如何升级 240 | 241 | 视频推荐：https://www.elastic.co/cn/webinars/upgrading-your-elastic-stack 242 | 243 | # 15、有没有办法在 logstash 中删除 nested 中符合条件的 object？ 244 | 245 | https://elasticsearch.cn/question/8398 246 | 247 | 已解決 248 | ``` 249 | ruby { 250 | code => ' 251 | a = event.get("inventory_item") 252 | a = a.delete_if { |x| ! x["item_equipped"] } 253 | event.set("inventory_item", a) 254 | ' 255 | } 256 | ``` 257 | 258 | # 16、大量数据写入Maybe ES overloaded？ 259 | 260 | 【问题描述】 261 | ``` 262 | S的版本为：5.4 263 | 当前运行场景是这样的： 264 | 265 | 现在有6张hive表，数据量大小，规模均不一致。数据条数最多的有两千多万条，数据量少的有200w左右，多数表在500w条数据。表中最多的数据有大约200个字段。我处理的时候是对于每一张表，使用sparksql查到需要写入ES的数据，然后简单筛选一下。转换读取的json字符串为es能写的key-value形式。调用rdd写es的函数finalRdd.saveToEsWithMeta(resource, esConfig)将结果写入。 266 | 267 | 我的es配置大概如下（对应于es配置es.batch.size，在scala代码中做了配置文件的映射es_batch_size对应于es.bastch.size）： 268 | es_batch_size=1200 269 | es_batch_refresh=false 270 | es_batch_retry_count=10 271 | es_batch_retry_wait_second=30 272 | es_write_operation=upsert 273 | 274 | 写入的时候提示的错误几乎全是上面Maybe ES was overloaded?我做了如下尝试： 275 | 1.每个rdd写入es的时候数据量太大，超过了es的最大写入量（我的猜想）RDD处理的时候有一个repartition操作，可以将大量的RDD数据分散存放在不同的机器上，我尝试修改这个值让他更大，保证分到机器上RDD更小，对RDD再调用saveToEsWithMeta写入数据（50-150）。还是提示这样的错误。 276 | 277 | 2.es_batch_size比较小，每次处理的时候需要频繁的拿数据比较耗时（我的猜想），调高es_batch_size(最高设置到3000)。也是时常出现这样的错误。 278 | 279 | 3.因为偶然的因素比如集群资源波动导致es数据写入失败（我的猜想），于是我尝试添加更多的es_batch_retry_count,最多设置过60,效果依然不明显。 280 | es_batch_retry_wait_second这个时间我也修改过(改大，我猜想ES写宽表的时候可能辉比较慢，这时候当处理到宽表的时候，批处理容易超时，改大可能会好一点（最大改到了60）)，效果依旧不明显。问题还是时有发生。 281 | 282 | 现在不知道还有什么方法可以尝试，想问一下大家有没有碰到类似的问题，通常是如何解决的，不同规模的数据在往es写的时候同样ES配置是同样的吗？还有上面queued tasks = 216意思是不是我的es队列大小为200,队列中等待的任务超过了200,请求写入es的操作被拒绝了。是这样吗？ 283 | ``` 284 | 回复： 285 | 286 | es序列化具体设置:es.batch.size.bytes (default 1mb) 287 | 288 | es.batch.size.entries (default 1000) 289 | 290 | 你的字段比较多，单个doc文档比较大，es.batch.size.entries可适当调小，es.batch.size.bytes 可以大一点； 291 | 292 | 这个你可以自己根据硬盘性能和分片数自己设置; 293 | 294 | 例如:硬盘读写60M/s，集群12台，24个分片，2个副本，平均一台集群上有2个主分片需要写入，4个副本分片需要同步；那么每秒写入的理论上是60*12/3= 240M/s; 所以，可以适当调整es.batch.size.bytes；然后计算你单个doc的字节数；es.batch.size.bytes除以单个doc，就可以预估一个es.batch.size.entries的值； 295 | 296 | # 17、es集群起步三台，什么情况下用5台或者7台？？？ 297 | 298 | doom同学的回答很干脆。 299 | 300 | https://elasticsearch.cn/question/8413 301 | 302 | 这个没什么只指标吧；大多数是根据分片和内存来的； 303 | 1：30GB堆内存的节点最多可以有600-750个分片；单分片的记录条数不要超过上限2,147,483,519；一个分片30G，单台最大库容量，17.5T到22T； 304 | 2：读性能考虑;副本分片的数量；不单单是读取硬盘数据，还有计算性能，性能不足时需要添加几台 305 | 3：写性能考虑:主分片数量； 306 | 综合上面的；2和3，直接关系到分片的个数；关系也是密切的；集群规划，是根据这些考虑的；需要是总分片数。 307 | 308 | # 18、es查询结果超过16位导致精度丢失 309 | 310 | wood大叔：我在ES英文论坛问过这个问题 311 | https://discuss.elastic.co/t/long-json-number-lost-precision/72124/12 ，结论是javascript本身的限制导致ES的Dev Console显示的数值丢失精度，如果在命令行下用curl去查询就不会有问题。 312 | 313 | # 19、【推荐】集群规划官方文档翻译 314 | 问题讨论：https://elasticsearch.cn/question/8429 315 | 316 | https://blog.csdn.net/xuguokun1986/article/details/91861796 317 | 318 | # 20、Logstash服务启动为什么会把Elasticsearch服务杀死 319 | 320 | 问题探究：这不是logstash能把ES搞死，实际场景：mysql或者你的后台程序都有可能。 321 | logstash非常耗费内存，建议：单机部署。 322 | ES多数据量业务场景，建议：单机独立部署。 323 | 324 | # 21、logstash消费kafka数据乱码 325 | 326 | https://elasticsearch.cn/question/8442 327 | 328 | 【回复】 329 | 1. 数据源是gbk，input 里面解析为“GBK ，可以正常输出，默认是utf-8；output里面不用添加 charset=>"GBK"； 330 | 2.检查你的系统默认字符集；echo $LANG ;确保utf-8； 331 | 3.控制台的输出环境，也设置为utf-8； 332 | 333 | 以上3点做到，就可以正常显示； 334 | 335 | 336 | # 22、kibana7.2 用api创建index pattern如何指定space？ 337 | 338 | 【问题描述】 339 | 方给出了如下的通过cURL调用kibana api的方法，但只能在default空间创建index pattern。 340 | 如果要指定space的话需要添加什么呢？ 341 | ``` 342 | curl -k -u username:passwd -X POST "localhost:5601/api/saved_objects/index-pattern/my-pattern" -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d' 343 | { 344 | "attributes": { 345 | "title": "my-pattern-*" 346 | } 347 | } 348 | ' 349 | ``` 350 | 351 | medcl回复： 352 | ``` 353 | POST /s//api/saved_objects/index-pattern/my-pattern 354 | { 355 | "attributes": { 356 | "title": "my-pattern-*" 357 | } 358 | } 359 | ``` 360 | 361 | 362 | # 23、推荐：Elasticsearch: analyzer 教程 363 | https://blog.csdn.net/UbuntuTouch/article/details/100392478 364 | 365 | 铭毅天下 366 | 20191007 22:51 367 | -------------------------------------------------------------------------------- /es_accumulate/201911_report.md: -------------------------------------------------------------------------------- 1 | # 1、count api 和 直接设置size = 0 ， 来统计条数的区别。 2 | 官方提供了count api 来获取匹配的结果， 如下： 3 | GET /twitter/tweet/_count 4 | { 5 | "query" : { 6 | "term" : { "user" : "kimchy" } 7 | } 8 | } 9 | 那么，按照下面这种方法，和count 方法有何区别： 10 | 11 | GET /twitter/tweet/_search 12 | { 13 | "size": 0, 14 | "query" : { 15 | "term" : { "user" : "kimchy" } 16 | } 17 | } 18 | 结果都可以得到相应的总的匹配的条数。 19 | 20 | 回复： 21 | 上面返回值中有一个"relation" : "gte"表示返回的文档数超过10000个。不是精确的，如果你想得到精确的返回值，你可以这么做： 22 | 23 | GET _search 24 | 25 | { 26 | 27 | "track_total_hits": true 28 | 29 | } 30 | 这样我们就可以返回所有的文档 31 | 32 | # 2、ES查询功能上线，导致线程dump，有什么好的方法优化？ 33 | 回复： 34 | ES是需要非常强大的硬件环境支持，如果硬件不够，基本就是demo的演示。 35 | 36 | ES是高消耗内存，高消耗cpu，高消耗磁盘空间的一款开源全文检索引擎，它不是神，它的最适合的场景是全文检索。 37 | 38 | cpu核心数越多，对查询来说越好，如果有可能，最好采用40core cpu的 物理机 39 | 40 | 内存越大越好，最好是64GB物理内存，如果有可能，一台40core 64gb内存的服务器，最大存储数据量在5TB左右。 41 | 42 | 硬盘空间要合理，最好是储存数据的3.4倍(参考阿里的算法),假如存储5TB的数据，磁盘空间最好是15TB左右。最大不要超过20TB。 43 | 44 | 按照经验，当128GB内存，分配给es64gb堆内存时，存储的数据上限是15TB（最好不要超过10TB），否则出现各种问题，尤其是内存full gc。 45 | 46 | # 3、如何修改search.max_buckets 47 | PUT _cluster/settings 48 | { 49 | "persistent": { 50 | "search.max_buckets": 20000 51 | } 52 | # 4、大佬们，有一个疑惑，既然在写入文档时，有机会和时间去写translog到磁盘，为什么还要再费劲去写内存呢？ 53 | 54 | 个人认为这是对分布式应用的一个很好的实践吧，保证数据不丢失的同时尽量提高性能... 55 | 写buffer可以直接响应，提高响应性能。。但是又不能丢失内存数据，所以再写一份持久化log。。。最后，最终一致性（刷盘或重启读log）落盘segment. 56 | 57 | 性能与可靠性之间的博弈 58 | 59 | # 5、composite 多字段聚合按照count值降序返回 60 | 1.es6.8版本 61 | 2.目前使用composite 方式实现多字段聚合，遇到的问题就是想按照count值降序返回结果， 但是官方文档没有说明该方式， 只列举了按照key的降序和升序返回的方式， 请问有遇到类似情况的吗， 指教一下 62 | 官方7.5 推出了稀有聚合 rare terms aggregation 就是解决您的问题的。建议看一下。 63 | 64 | https://elasticsearch.cn/question/8715 65 | 66 | # 6、es里面是应该建多个索引，还是建一个索引进行查询更新性能更好 67 | 比如说：task有：user、title、content、thirdpart_name,thirdpart_url; 68 | 里面是user和thirtpart 在Mysql都是单独建了一张表，然后通过user_id，和thirdpart_id进行关联。 69 | 70 | es7.3需要也拆成多个索引进行管理吗？刚使用es，不知道怎么定方向 71 | 72 | 回复：ES 不适合多表 join 查询，因此推荐先 join 后存储到 ES 里面，存储单张表查询性能最佳。 73 | 74 | 当子表发生数据变化的时候可以使用 UpdateByQuery 去更新 75 | 76 | # 7、ES索引设计问题 77 | 78 | 因为网上有建议新手学习开源开发，从比较高的版本开始 ，刚开始学习使用 es 7.3.2，在搭建一套 EL+自己的查询 系统，用来采集，查看，公司客户的云上应用日志 79 | 现有一个问题，本想按 一个应用一个index，type 则对应 应用的不同文件 err.log info.log 等，如果客户应用数量达到了上万个，甚至十万个，这个。。。。我看有人说 3000个index，就已经很慢了; 80 | index的数量到底会不影响查询速度？ 81 | 82 | 如果 10万个index 里面包含 100亿级别数据 和 多个index 一起包含 100亿数据，他们之间的查询性能应该不一样吧，查询可以指定 index，范围会小很多，理论上速度会更快不是？ 83 | index 的数量 和 里面包含的数据量怎么样来平衡呢？ 84 | 85 | 回复： 86 | 一定要记住这句话， 生产环境，ES集群是有极限的。 87 | 88 | 一个集群是有最大节点限制，最大内存限制，最大磁盘空间限制的。一个集群最大索引数，最大分片数都是有限制的。 89 | 90 | 一个集群，最大节点最好不要超过20个，（分不同的场景）。一个节点的内存最好是64GB，或者128GB，硬盘最好是10TB或者20TB， 91 | cpu 至少20核心，最好40核心。 92 | 93 | 你这种场景，不应该只用一个集群， 接入一种业务，一个集群比较好(按照你的描述，业务就是你接入的应用)。 94 | 95 | 这样的最有扩展的，最大隔离不用的业务，相互之间无影响，一个集群挂掉，不影响其他集群业务。 96 | 97 | 千万不要所有业务只用一个集群，所有索引放在一个集群。 98 | 99 | 100 | # 8、多节点部署的ES做snapshot时，为什么要配置共享文件系 101 | 102 | 最近在做ES的灾备，发现大家的做法都是使用sshf指定一个节点的磁盘作为共享磁盘，让所有节点往里边写，为什么不能指定一个节点让它做呢，一定要用共享文件系统？ 103 | 104 | 回复：肯定要共享文件系统的，master在更新完快照元数据后，会用ClusterState的方式通知索引主分片所在的节点进行数据拷贝，所有数据都会放一起。 105 | 如果不是共享的，你想想会出现什么问题？ 106 | 107 | # 9、es性能测试：抛出大量429错误，CPU利用率仅70%，如何让CPU利用率跑到90%以上？ 108 | 109 | 测试拓扑：1个master节点（CPU2核，服务器内存8G），2个数据节点（CPU2核，服务器内存32G）。三个节点分别部署在三台服务器上。 110 | 111 | 测试表现：向数据节点1发送写入请求，写入速率约为600个请求每秒，大量请求返回429（reject，队列满）。但数据节点1、2的CPU利用率仅百分60%，内存60%。并未达到性能极限。 112 | 113 | 问题1：为何抛出大量429错误，CPU却没有跑满？ 114 | 问题2：如何让CPU跑到90%以上？ 115 | 116 | 回复： 117 | 1、大量请求返回429（reject，队列满）,这就说明 写入 已经达到极限了啊，都拒绝了。插入是不会消耗CPU的，除非有其他的连带操作。 118 | 比如插入的过程中，Elasticsearch 会做段文件合并，会消耗大量的cpu和load,当然也会消耗io。 119 | 一般对于es集群，都是单生产者，多消费者，或者几个生产者。而你测试的时候，好像是使用了大量的生产者去插入。 120 | 难道是想实现向mysql一样的，大量的增加，删除，修改，功能吗？ 121 | 122 | 2、es 不符合这种场景。并发修改，会导致冲突的。 123 | ES 并不适合并发修改， 有增删改需求还是考虑其他软件吧。 124 | 125 | ES 是一个全文检索框架，是专门应付全文检索查询和简单少数据的聚合查询的。 126 | 如果是单个生产者，进行增删改，那是没有问题的。 127 | 128 | 并发增删改不行。 129 | 130 | # 10、Elasticsearch 单独分离协调节点意义在哪 131 | 来社区请教一下大佬： 132 | 我在一个节点上的配置如下： 133 | node.master: false 134 | node.data: false 135 | node.ingest: false 136 | 137 | 我想用这个节点作为一个仅协调节点，让这个节点做集群的负载均衡。但是默认每一个节点都是一个协调节点，请求也会打到其他节点上。那把这个节点单独隔离的意义在哪里呢？ 138 | 139 | 回复： 140 | 5.X版本之后，没有client节点，确切的说较：协调节点。 141 | 请仔细读一下协调节点的作用： 142 | 143 | 第一：诸如搜索请求或批量索引请求之类的请求可能涉及保存在不同数据节点上的数据。 例如，搜索请求在两个阶段中执行（query 和 fetch），这两个阶段由接收客户端请求的节点 - 协调节点协调。 144 | 145 | 第二：在请求阶段，协调节点将请求转发到保存数据的数据节点。 每个数据节点在本地执行请求并将其结果返回给协调节点。 在收集fetch阶段，协调节点将每个数据节点的结果汇集为单个全局结果集。 146 | 147 | 第三：每个节点都隐式地是一个协调节点。 这意味着将所有三个node.master，node.data和node.ingest设置为false的节点作为仅用作协调节点，无法禁用该节点。 结果，这样的节点需要具有足够的内存和CPU以便处理收集阶段。 148 | 149 | # 11、【重要】关于ES7.X移除Transport Client 性能疑惑 150 | ES7.*移除Transport Client.关于原因官方虽然有解释但是都没提到性能问题 151 | 这里有篇官方的博客 https://www.elastic.co/cn/blog/benchmarking-rest-client-transport-client 152 | 对比了Rest Client和Transport Client之间的性能问题. 153 | 但是测试基准是单线程客户端. 154 | Transport Client是基于Netty实现的tcp客户端.非阻塞IO 多路复用 在高并发下表现很好 155 | 但是Rest Client是基于HTTP实现的.HTTP1.1不支持多路复用.在高并发下性能应该会下降的很明显 156 | 157 | Medcl回复：性能是会有一些影响，不过现实情况，这些差异你根本不用担心的，使用 HTTP 代替 TCP 更多的是避免版本耦合的问题，以前服务器和客户端版本不一致，会出现两边对象无法反序列化的问题，如果用 TCP，升级服务端，客户端也得都升级，什么滚动升级基本上也别想了。 此为 HTTP 性能已经足够强悍了，并发吞吐同样可以达到很高，更多的时候是其它资源先不够，此外 Rest协议底层一样也是基于 Netty 的。 158 | 159 | https://elasticsearch.cn/question/8796 160 | 161 | # 12、【星球小伙伴貌似问过】elasticsearch单字导致大结果集召回，性能出现问题，有好的方案解决吗？ 162 | 实际业务中，使用es6.x版本，其中文档数量在5亿左右，当用户输入单字，如：好，这种字的时候，容易召回上百万的结果集，导致function_score逻辑耗时超过2s。请问大家碰到这种情况是如何解决的？ 163 | 164 | 回复： 165 | （1）如果只是单字搜索不想耗时，那么： 166 | 目前兜底的打分模板不动，针对单字走另一个模板，该模板里的所有function_score匹配域保留重要字段即可，比如去掉描述、正文。因为单字场景用户提供的信息极少，用标题match+文档质量分足够出好文档。 167 | （2）如果所有搜索词都想提速，那么： 168 | 修改原有打分模板，function_score保留原有样子，在filter里追加一个must去包一个/几个match或term，通过减少字段域或minimum_should_match往更严格的方向去卡匹配阈值，通过此来减少倒排求交召回的文档数量。阈值别太严格，不影响目标文档被召回即可。 169 | 170 | # 13、ES 6.7.2中使用term query 查询 浮点类型数据出现问题 171 | 今天使用term query 查询一个浮点类型，例如12.3。发现无法匹配，然后看了一下mapping，发现type是long类型。 172 | 查询参数如下： 173 | ``` 174 | { 175 | "query": { 176 | "bool": { 177 | "must": [ 178 | { 179 | "term": { 180 | "knInfoExtend.allowanceTotal": { 181 | "value": 15.5 182 | } 183 | } 184 | } 185 | ] 186 | } 187 | } 188 | } 189 | ``` 190 | 191 | text我知道可以，但是有没有解释一下为什么这样不行 192 | 回复：问得很好，因为倒排表必须存离散型数据，一旦支持数值型，哪怕域只是[0-1]，表就炸了。token都是0.001、0.0001、0.0000001...原理上不支持 193 | 194 | # 14、【探讨】index.refresh_interval能设置到多小，有没有一个参考值 195 | 196 | 目前需要将数据写入，但需要马上搜索对其修改。服务器是16g内存，500g固态，8核的cpu。由于写入到能被搜索存在一定的间隔时间，所以现在并发操作数据经常报409版本冲突错误，所以想将间隔时间设置小一点。目前设置是500ms。但不知道再往下设置，会不会造成es其他问题。 197 | 198 | 回复： 199 | refresh_interval控制刷新内存到lucene段的生成速度，在高并发大数据量写入的情况下，时间太小会导致太多的大量小段生成，对后台段的merge以及查询需要访问更多的段都有影响，造成集群不稳定，不建议再调低。 200 | 201 | 还有一个，ES不太适合写完马上就修改的场景，修改写入的数据实际上在lucene也是新生成了一条记录。对于这种实时可见的场景，不建议用ES, 可以试试mongo或者在应用层端自己合并在ES中查询的结果。 202 | 203 | https://elasticsearch.cn/question/8901 204 | 205 | # 15、关于es聚合相关优化慢——全量聚合 206 | https://elasticsearch.cn/question/8876 207 | 回复1: 208 | 209 | 1核心：size":2147483647, 确认是否必须 210 | 2,你是多重嵌套，势必会慢 211 | 3,如何排查慢？推荐：profile:true 定位慢的根因 212 | 推荐：https://mp.weixin.qq.com/s/RTpBaFpNELQCO6VE0KMfsw 213 | 214 | 回复2： 215 | 这么说吧，所有的优化，都是因为需求不合理或者硬件资源不够导致的。 216 | 全量数据聚合，为什么要用ES呢？ 217 | 而且你可以选择离线聚合一次保存到另一个，以后的查询可以走另一个索引。 218 | 3s已经非常快了。 219 | 220 | 因为我读了那块es聚合的源码。在terms聚合的时候，有一个bucket优先队列，瓶颈在于size的数目越多，对于聚合的瓶颈越大。想看看有没有从源码上面级别去优化。 221 | 如果全量数据聚合的话，有没有其他的中间件合适？ 222 | 223 | 希望大家探讨一下！ 224 | 225 | # 16、logstash性能调优 226 | 问题：logstash读取kafka数据输出到elasticsearch，在kafka堆积了大量的数据，cpu使用率到达98%， 227 | 服务器环境是16c64g 228 | 229 | 调优： 230 | 1. pipeline.batch.delay: 5这个可以调长一点,比如50 231 | 2.部署多个logstash 232 | 3.试试携程的hangout 233 | 234 | 235 | # 17、如何优雅地关闭elasticsearch集群？ 236 | 237 | es版本5.6 238 | 由于某些原因，需要关闭整个es集群并隔一天后重新开启，请教下建议的关闭操作是什么？ 239 | 查了下_shutdown这个API已经在2.x版本之后就废弃了，网上建议的方法比较复杂https://blog.csdn.net/wangzhen3798/article/details/84069909，有没有比较推荐的操作方法？ 240 | 241 | 回复： 242 | 参考官网的： 243 | Full cluster restart upgrade 244 | https://www.elastic.co/guide/en/elasticsearch/reference/current/restart-upgrade.html 245 | 将其中升级部分去掉就好了， 246 | 247 | 核心步骤： 248 | 1、关闭集群自动分配——确保不再写入； 249 | 2、同步写盘——确保数据不丢失 250 | 3、逐台关闭节点。 251 | 252 | # 18、跨多个月存储索引数据的冷热数据分离如何实现？ 253 | 有个问题请教一下，我用elasticsearch存订单数据，在热节点保存3个月前的数据（用一个索引），在冷节点保存3个月后的数据（用一个索引），数据会先持续写入热节点。目前找到的冷热数据分离方案，都是基于按时间序列建多个hot索引（比如1天1个索引），过了几天后在把整个索引放入冷节点。 254 | 而我的业务场景是只有一个hot索引，要把里面的数据按条件定时迁移到另外一个索引，因为业务要求能跨3个月或整年查数据，请问大家有什么好的建议吗？ 或者说我这个思路行不通啊？？ 谢谢。 255 | 256 | 我现在想到的初步方案是：通过JAVA API每天定时轮循从热节点查出来在写入冷节点。但感觉这个方法不好，如有好的建议请指导一下，谢谢。 257 | 258 | wood大叔回复： 259 | 每天从热节点查出来写入冷节点这方案不靠谱，开销太高了。 你就根据单日订单量的大小，一天一个索引，或者一个月一个索引的方式来建就好了，最经济易维护的冷热数据分离方案。 因为搜索是可以跨多个索引的，所以这种建索引的方式可以满足业务上要求跨3隔越或者跨整年查询。 260 | 261 | 索引按天创建的化，日期可以作为后缀加到索引名字里，形如 "orders-YYYYMMDD" 。 代码里根据用户传入的搜索时间范围，转化成需要搜索的索引列表。 ES的搜索API构建Client时支持传入一组名称作为搜索的目标索引。 打分、排序、分页和搜单个索引没什么区别。 262 | 263 | -------------------------------------------------------------------------------- /es_accumulate/201912_report.md: -------------------------------------------------------------------------------- 1 | # 1、logstash split 使用 \\ 分隔符出错 2 | https://elasticsearch.cn/question/9264?notification_id=60904&rf=false&source=MTMwMDM= 3 | 4 | 回复：该问题已经得到解决。 5 | 如果要在split中使用反斜杠 \\ 操作的话不可以直接使用，否则会导致Logstash运行失败 6 | 7 | 下面这种做法可以解决反斜杠的问题： 8 | ``` 9 | gsub => ["serverPath", "[\\]", "/"] 10 | split => ["serverPath" , "/"] 11 | ``` 12 | # 2、如何把一个Elasticsearch上的数据全部迁移到另一个Elasticsearch服务器上？ 13 | 回复： 14 | 官方文档 reindex api 15 | 1、给目标集群新增白名单配置 16 | reindex.remote.whitelist: "otherhost:9200, another:9200, 127.0.10.*:9200, localhost:*" 17 | 2、使用reindex api 将源集群索引迁移到目标集群 18 | ``` 19 | curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d' 20 | { 21 | "source": { 22 | "remote": { 23 | "host": "http://otherhost:9200", 24 | "username": "user", 25 | "password": "pass" 26 | }, 27 | "index": "source", 28 | "query": { 29 | "match": { 30 | "test": "data" 31 | } 32 | } 33 | }, 34 | "dest": { 35 | "index": "dest" 36 | } 37 | } 38 | ' 39 | ``` 40 | # 3、请问有使用Elasticsearch做 图片搜索引擎的吗？以图搜图那种 41 | https://elasticsearch.cn/question/9128 42 | 回复1：Elastic本身的引擎是Lucene，最开始的设计是一个纯文本full-text search engine 43 | 44 | Elastic用的query只能是text或某种text的变体（即使是数字之类的其它类型） 45 | 46 | 而以图用图搜的query是图片，那么如果你需要用Elastic来做的话，则需要将图片转为某种形式的text。通常以图搜图的实现是 47 | 48 | 1. 建一个足够大的图片库，将图片特征提取出来（通常结合一些CV的操作，不会仅仅是把像素提取出来） 49 | 2. 新来一张图片时，用同样的方法，把特征提取出来 50 | 3. 用某种similarity来确定2中的图片和1中的图片距离最近的topK。通常这也可以用一些机器学习的方法来做 51 | 52 | 也就是说，如果你需要用Elastic来做以图搜图，需要比较多hack把一个本来为纯文本设计的引擎（倒排索引）来套用上，这与这个工具本身设计的理念不太切合，所以用起来也会比较尴尬。 53 | 54 | 但如果LZ一定要试试的话，我能想到的办法有 55 | 56 | 1. 自己写一个Query，直接替换ES用的Lucene的标准Query 57 | 2. 这个Query需要重新定义一个similarity，比如用余弦距离。在Index时，把图片特征存到index里，存到一个field 58 | 3. 对于一个待搜索图片，用同样的方式抽出特征。把其中的特征中的一部分建一个Query，用来搜索第2步里存的field，取5*top-K。注意这里需要比topK多，来保证召回率足够高 59 | 4. 对于collect到的所有图片candidate，再将用similarity算一次与query图片的距离，取topK 60 | 61 | 可以看到，这个实在是非常尴尬，倒排引擎的唯一作用就是预过滤，不建议这样使用 62 | 63 | 回复2：Elasticsearch现在已经支持向量检索，将图片特征转换成向量，然后进行相识度检索，已经有用户这么做了。 64 | 65 | 回复3：百万量级以下文档库，自己写个es-embedding-script-score就行，即使是O(n)精确搜索也可以在几十ms内返回TopK结果。 66 | 百万量级以上文档库，直接用milvus，milvus支持亿级向量相似计算在毫秒级完成（lg(n)近邻搜索），支持自动增量更新索引，相对FAISS免去Docker化和接口自定义等工作。 67 | 68 | 当年没有写es-embedding插件时，我还试过把embedding转成文本去用match，各种往text变体去靠，太南了.. 69 | 70 | 回复4：采用的keras下VGG16来计算图片特征向量，使用Elasticsearch+aliyun-knn 实现向量搜索，然后对召回的结果使用相似度得分做了过滤处理 71 | 72 | # 4、使用elasticsdump迁移数据，导入几个G之后就会断开。 73 | https://github.com/medcl/esm-v1 74 | 75 | # 5、ES 如何实现 SQL 查询条件 （name=1 or name=2 ） and （status=1 or status =2） 76 | 方法： 77 | 用es的_sql/translate特性，通过sql反查es语句 78 | ``` 79 | POST _sql/translate 80 | { 81 | "query": "select * from log_5c54dd7a87604fa195aad3224ab93a49 where (test=1 or test=2) and (test2=1 or test2 =2)" 82 | } 83 | ``` 84 | # 6、怎样有效解决0点数据写新索引时的性能问题？ 85 | 86 | 我的集群每天会根据日期创建一百多个新的索引。 87 | 并且有些索引写入的日志来自于很多个不同的应用程序，它们字段各不相同，mapping不是一次写入就固定下来，而是在一段时间内会频繁地更新。 88 | 89 | 现在我遇到的问题是，虽然已经预创建了第二天的索引，但每天0点，当所有数据都往新日期的索引里写时，集群还是经常卡住，数据在一段时间内无法写入，报 failed to process cluster event (put-mapping) within 30s 错误。 90 | 91 | 看错误提示，应该是这段时间各种不同的日志写入索引，索引的mapping字段在不停地更新，导致master处理不过来，写日志到es的进程在比较长的时间内无法写日志，从而导致一系列问题。 92 | 93 | 针对这种情况，我能想到的是对所有mapping，也按照前一天的配置，预先做设置，但这样如果索引模板中的mapping配置发生变化，也没办法及时更新。不知道有没有什么好的思路去解决。 94 | 95 | wood大叔回复： 96 | 日志系统最好不要用动态mapping，规模越大，带来的问题越多。 一 97 | 方面每写入一个新字段都会引起集群更新状态，对于规模较大的集群，因为状态数据比较大，master会处理不过来，造成数据一段时间无法写入； 98 | 另外一方面字符型数据默认都是创建成一个keyword类型和一个text类型，而往往只会用到其中一个类型，甚至有些根本就不会做检索和聚合， 这样大大提高了数据写入的开销，磁盘空间也会有非常大的浪费。 99 | 100 | 我们对于日志数据的mapping是设置"dynamic": "false"，不允许动态创建的。 所以新增的字段初始接入的时候是无法检索的，需要用户在我们提供的UI上自助为新字段定义类型，新类型才会被写入mapping里。 101 | 102 | # 7、错误： [has_parent] no join field has been configured 导致Full GC？ 103 | 104 | https://elasticsearch.cn/question/9071 105 | 回复： 106 | 聚合会占用大量的内存， 尤其是rcm 和 fm ， 107 | 108 | 可以使用命令查看，各节点的各个内存使用情况。 109 | 110 | 再看看，gc情况，一般发生这种事，有两种原因， 111 | 1,需求不合理 112 | 2,硬件资源不够。 113 | 114 | # 8、logstash写入es报错400 115 | [2019-11-13T14:36:05,396][ERROR][logstash.outputs.elasticsearch] Encountered a retryable error. 116 | 117 | Will Retry with exponential backoff {:code=>400, :url=>"http://192.168.10.151:9200/_bulk&quot;} 118 | 119 | logstash7.5.0 elastisearch7.5.0 120 | 121 | 回复： 122 | 400是Bad request - 这个写入的操作本身有问题，比如syntax错误之类的。 123 | 这里的endpoint是_bulk，看上去应该是已经在retry。在这条信息之前应该还有别的错误信息，也许有更多的线索。 124 | 125 | # 9、如何统计nested字段下所有子文档数 126 | 以官网文档为例，里面有一个user是nested类型，我要统计user下的所有子文档数，需要怎么写呢？求大佬指点~ 127 | 官网地址：https://www.elastic.co/guide/e ... .html 128 | ``` 129 | PUT my_index 130 | { 131 | "mappings": { 132 | "properties": { 133 | "user": { 134 | "type": "nested" 135 | } 136 | } 137 | } 138 | } 139 | 140 | PUT my_index/_doc/1 141 | { 142 | "group" : "fans", 143 | "user" : [ 144 | { 145 | "first" : "John", 146 | "last" : "Smith" 147 | }, 148 | { 149 | "first" : "Alice", 150 | "last" : "White" 151 | } 152 | ] 153 | } 154 | ``` 155 | 回复： 156 | ``` 157 | GET my_index/_search 158 | { 159 | "size": 0, 160 | "aggs": { 161 | "nest_user": { 162 | "nested": { 163 | "path": "user" 164 | }, 165 | "aggs": { 166 | "user_count": { 167 | "value_count": { 168 | "field": "user.first" 169 | } 170 | } 171 | } 172 | } 173 | } 174 | } 175 | ``` 176 | # 10、请问一下，如何将评论和销量转化为搜索相关性打分项 177 | 178 | https://elasticsearch.cn/question/9045 179 | 180 | 181 | 如果当产品的相关性差不多的情况下，如何将评论和销量作为排序的依据，把产品评论和销量比较大的产品排在评论和销量相对较小的产品上面，提高产品曝光度，或者实现评论和销量作为一个加分项，参与相关度评分计算，能提升一点评分相关度，使得这类产品能够评分高些 182 | 183 | 参考function_score 184 | field_value_factor 185 | https://www.elastic.co/guide/e ... actor 186 | 187 | 回复2； 188 | 用sort _script 也是可以的。 189 | 文档 190 | ``` 191 | Script Based Sortingedit 192 | Allow to sort based on custom scripts, here is an example: 193 | 194 | GET /_search 195 | { 196 | "query" : { 197 | "term" : { "user" : "kimchy" } 198 | }, 199 | "sort" : { 200 | "_script" : { 201 | "type" : "number", 202 | "script" : { 203 | "lang": "painless", 204 | "source": "doc['field_name'].value * params.factor", 205 | "params" : { 206 | "factor" : 1.1 207 | } 208 | }, 209 | "order" : "asc" 210 | } 211 | } 212 | } 213 | ``` 214 | # 11、ES的按周统计是由周一开始的？ 能否指定为周日为周的第一天？ 215 | 216 | 回复： 217 | 参考参数offset： 218 | https://www.elastic.co/guide/en/elasticsearch/reference/6.8/search-aggregations-bucket-datehistogram-aggregation.html#_offset 219 | 220 | # 12、ES7.x拿到total总量 221 | 回复： 222 | "track_total_hits": true, 正解。 223 | 如果不做限制，默认有用户返回上百万数据，与Elastic 追求快的理念不一致。 224 | 225 | 在你request body里加个参数就是 226 | ``` 227 | { 228 | "track_total_hits": true, 229 | "query":{} 230 | } 231 | ``` 232 | # 13、新人提问求大神指导es学习路线 233 | 234 | 互联网做ES相关开发主要有3个方向： 235 | 236 | （1）偏算法方向：搜索算法/研发工程师。工作内容往往是在"使用"和"二次开发"两方面跟ES打交道，需要知道ES一些机制、DSL写法、索引构建和某些外围插件的开发和使用。如果是偏算法，那么会对分词、查询改写、召回和精排等模块进行优化。其中需要java开发能力，比如写个服务接口，提供自己实现的某算法能力。如果是偏研发，那么可能涉及ES二次开发，需要做一些跟倒排索引构建、跳表查找加速、索引压缩等相关的底层开发，需要对搜索引擎的研发有一定的了解，ES以及底层的lucene都是java开发，自然而然也是用Java。 237 | 238 | （2）偏ops方向：ES系统/运维工程师。往往是java后台工程师会往这个方向靠，ES集群的管理、维护和升级，以及最重要的集群性能优化，都是上面搜索算法/研发工程师不具备的能力。虽然ES开箱即用，但离用得好还差个ES系统/运维工程师，而这也是很多公司缺的，因为这几年有意识往这个方向靠的java工程师不多，往往是被动得维护ES才变成了ES OPS专家。所以ES线下沙龙涉及系统优化，大家都是以经验分享，没有形成体系。 239 | 240 | （3）偏数据流方向：日志系统研发工程师。10个ES技术分享，假设有2个分享搜索、3个分享ops，其它都是分享ELK系统搭建。虽然有搜索业务的公司很多，但有日志管理需求的公司更多，其中ELK又那么好用，所以能不能用java开发ELK系统也是强需求，能不能从0到1搭一套日志管理系统，拿出手分量也够。 241 | 242 | 上面是我自己的一点了解，深度和广度都照顾下，比如做搜索尽量也会点ops，大概率会很吃香，反过来也是，加油。 243 | 244 | # 14\、mongodb没有同步到elasticsearch问题 245 | 246 | 之前一直用mongo-connector来同步商品数据库到es，但是昨天重启了下es，导致在重启期间内的mongodb数据没有同步到es，重启mongo-connector也没有用。 247 | 重启mongo-connector后数据的修改增加都没有问题，就是那个时间段的数据丢失 248 | 249 | 回复： 250 | 251 | mongo-connector 本身就是个垃圾东西。 252 | 估计没有对oplog，做失败的重试，当然，失败的重试，也会导致数据重复，下游需要幂等性。 253 | 一般发生在何种事情的，唯一办法是找到，mongo-connector 消费oplog的原理，找到消费oplog的时间点，将这个时间点还原到 254 | 255 | 失败的时候的那条oplog日志的时间，这样重启mongo-connector 后，即可从oplog 那条日志开始消费。（需要先将es，重启后的数据删除或者还原） 256 | mongo-connector 这玩意的原理，就是解析 mongodb oplog 日志表。 257 | 258 | 一条一条解析，然后按照CRUD的形式，对ES 中的数据进行增删改查。 259 | 260 | 最好不要用这些 第三方的东西，都是半成品。做这种软件，必须要考虑，幂等性，分布式，失败，故障，数据重复，数据丢失等一切可能才行。 261 | 262 | 一般情况，数据重复，都是利用 主键ID，mongodb,应该是objectId，如果是mysql 那就是主键ID，因此ES 中的ID 也是唯一的，可以保证，数据不重复,幂等性。 263 | 数据不丢失，只要能重复消费oplog就行了。 264 | 265 | 266 | # 15、elasticsearch 统计不准 sum_other_doc_count >0 267 | 268 | 1,前提认知：es聚合是近似准确的，不精确的。（和多分片取数据有关系） 269 | 270 | 2,方法：调大shard_size值，如果shard_size 取更大的值，结果会更准确。 271 | 272 | 3,还有一种方案，size改成2的32次幂减去1，不过不推荐，原因：性能问题。 273 | 274 | https://elasticsearch.cn/question/8978 275 | 276 | # 16、有什么工具或者脚本，能每月自动创建滚动索引，格式为：order_yyyy-mm 277 | 你只需要在集群里放置一个索引的模版(template)，定义好索引的settings和mappings，然后代码里往某个新索引写入数据的时候，集群会自动套用模版设置，创建一个新索引。 278 | curator 配好模板可以 279 | 280 | # 17、跨多个月存储索引数据的冷热数据分离如何实现？ 281 | 有个问题请教一下，我用elasticsearch存订单数据，在热节点保存3个月前的数据（用一个索引），在冷节点保存3个月后的数据（用一个索引），数据会先持续写入热节点。目前找到的冷热数据分离方案，都是基于按时间序列建多个hot索引（比如1天1个索引），过了几天后在把整个索引放入冷节点。 282 | 而我的业务场景是只有一个hot索引，要把里面的数据按条件定时迁移到另外一个索引，因为业务要求能跨3个月或整年查数据，请问大家有什么好的建议吗？ 283 | 284 | 或者说我这个思路行不通啊？？ 谢谢。 285 | 我现在想到的初步方案是：通过JAVA API每天定时轮循从热节点查出来在写入冷节点。但感觉这个方法不好，如有好的建议请指导一下，谢谢。 286 | 287 | 回复： 288 | 每天从热节点查出来写入冷节点这方案不靠谱，开销太高了。 你就根据单日订单量的大小，一天一个索引，或者一个月一个索引的方式来建就好了，最经济易维护的冷热数据分离方案。 因为搜索是可以跨多个索引的，所以这种建索引的方式可以满足业务上要求跨3隔越或者跨整年查询。 289 | 290 | 索引按天创建的化，日期可以作为后缀加到索引名字里，形如 "orders-YYYYMMDD" 。 代码里根据用户传入的搜索时间范围，转化成需要搜索的索引列表。 ES的搜索API构建Client时支持传入一组名称作为搜索的目标索引。 打分、排序、分页和搜单个索引没什么区别。 291 | 292 | 293 | 294 | 295 | -------------------------------------------------------------------------------- /es_accumulate/202001_report.md: -------------------------------------------------------------------------------- 1 | # 1、nestd query和bool query不能同时使用吗 2 | 使用举例： 3 | ``` 4 | { 5 | query:{ 6 | bool:{ 7 | filter:{}, 8 | must:[{ 9 | nested:{} 10 | }] 11 | } 12 | } 13 | } 14 | ``` 15 | 16 | # 2、如何禁用 ES 模糊查询 wildcard? 17 | 我想在服务端禁止有 wildcard 查询的语句执行。ES 有这个功能吗？怎么禁止一些语句查询？比如客户端当使用 wildcard 语句查询时，服务端禁止执行这种语句。可以在服务服务端设置吗？ 18 | 19 | 回复：不要直接向用户公开Elasticsearch，而是让应用程序代表用户发出请求。如果无法做到这一点，请使用一个应用程序来去除用户的请求。编写一个_search很有可能使Elasticsearch不堪重负并使集群瘫痪。所有此类搜索都应视为错误，并且Elasticsearch贡献者已尽力防止这种情况，但仍然可行。 20 | 21 | 这是官网文档说的，总结一下应该是说要搞一个网关，不要让可以使集群瘫痪级别的请求到达ES。在请求到达es之前过滤，而不是让es去禁止这些语句。 22 | 23 | 有误的地方请大神们指正 24 | 25 | #3、使用join查询，现查询子文档，怎么返回子文档相应的父文档呢？ 26 | 问题： 27 | https://elasticsearch.cn/question/9239 28 | 使用join查询，现查询子文档，结果都是子文档，然后数据需要从子文档相应的父文档取几个字段， 29 | 问怎么返回子文档对应的父文档呢？ 30 | 31 | ``` 32 | GET /my-index/_search 33 | { 34 | "query": { 35 | "parent_id": { 36 | "type": "my-child", 37 | "id": "1" 38 | } 39 | } 40 | } 41 | ``` 42 | 回复：#4、get child document by parent document 43 | ``` 44 | GET my_index/_search 45 | { 46 | "query": { 47 | "has_parent" : { 48 | "parent_type" : "question", 49 | "query" : { 50 | "match_phrase": { 51 | "text": "This is a question" 52 | } 53 | }, 54 | "inner_hits": {} 55 | } 56 | } 57 | } 58 | ``` 59 | # 4、elasticsearch painless 如何获取text类型的数据 60 | 61 | 本人在kibana中使用scripted fields功能，想要获取text类型的数据，进行处理。 62 | 阅读官方文档之后发现，并不能够通过doc获取text类型的数据 63 | ### 相对于其他脚本语言的一些限制： 64 | 65 | 只有数字、布尔、日期和地理点类型的字段可以被访问； 66 | 存储字段（Stored fields）不可用 67 | 68 | 求助，如何获取text类型的数据。 69 | 70 | 回复： 71 | es 7.x 72 | 这样取可行，ES里script的语法可以参考Java 73 | ``` 74 | { 75 | "script" : { 76 | "lang" : "painless", 77 | "source" : """String tmpTs = ctx.things; if (0 > tmpTs.indexOf('.')) {return;}""" 78 | } 79 | } 80 | ``` 81 | # 5、Elasticsearch出现周期性的慢查询 82 | 83 | 1.Elasticsearch作为搜索引擎 84 | 2.相对写少（基本都是单分片，30GB下，偶有两个索引大些，但是分片后也在30G下） 85 | 3.相对读多：总的QPS在1600+ 86 | 4.一共有4台物理机作为data node，配置为24核 32GB内存 SSD盘 87 | 88 | 请教下大家为何会出现周期性的慢查询。大家是否遇到过类似情况？如何解决。 89 | 90 | 回复： 91 | 思路1：有没有开slowlog看一下你的慢查询是什么样的query呢？还有周期性出现的话，有没监控过这些个时点有没有ES的类似segment merge、GC之类的操作？ 92 | 思路2：看下监控，是不是每次慢查询都在节点gc上，我目前碰到的大部分原因都在这。 还有可能是正好在缓存淘汰的时候查询直接走盘了也有可能。 93 | 94 | #6、ES关联查询，根据结果进行二次/多次查询 95 | 小白，看了点nested和parent/child的东西，发现这个很麻烦啊，还要做映射和修改数据，没办法直接做关联查询吗？第一次查询的结果中取某个字段给参数赋值赋值，作为第二次查询的条件参数这样的 96 | 比如这个例子里面 97 | user用户列表 98 | ``` 99 | { 100 | "name": "John Smith", 101 | "email": "john@smith.com", 102 | "dob": "1970/10/24" 103 | } 104 | ``` 105 | blog博客列表 106 | ``` 107 | { 108 | "title": "Relationships", 109 | "body": "It's complicated...", 110 | "user": "John Smith" 111 | } 112 | ``` 113 | 我先根据查询条件得到一个结果user文档，其中包括name字段值，然后我根据name字段值（例子中为"John Smith" ）构建另一个查询，查询这个user的blog，类似变量赋值的概念，或者说查询结果A.name=查询结果B.user，这里可能涉及多个A结果的问题（就是说查询A可能返回很多个name，要每一个都进行B查询导致耗费大量资源）我们暂时不考虑，假定约束每次查询A都只返回少量结果）重点在于，我期望不需要先运行查询A看到结果里面的name字段再人工构建查询B，而是可以在一个查询过程里面将查询A的结果传递给查询B进行调用，这种是否可以实现？ 114 | 115 | 回复： 116 | 小众应用场景： 117 | lookup terms可以满足你要求么？ 118 | https://www.elastic.co/guide/en/elasticsearch/reference/7.5/query-dsl-terms-query.html 119 | 120 | # 7、关于ES震荡问题是我理解的有问题吗？？？ 121 | 122 | 有个问题 集群两台，索引设置分片1 副本1.，通过_stats查询出delete文档为0，使用分词查询为什么还是会出现结果震荡，但是不使用分词查询就没有问题？这是怎么回事？ 123 | 124 | medcl回复： 125 | es 打分是分布式评分，先取局部评分TopN 在合并取 TopN，在不同节点上计算合并之后的结果是有可能存在差异，如果非常在意这个，可以使用 preference 来控制在固定的节点上进行查询。 126 | 127 | # 8、大神们好。我想问一下身份证号码这种类型的数据，怎样才能使用模糊查询呢？在不适用wildcard的情况下有没有其它第二种方式？ 128 | 129 | 阿里大佬回复： 130 | 身份证号码建议增加冗余分词字段，数据预处理，根据业务需要切分18位完整词条、前2位（省）、前4位（省市）、前6位（省市区县）、后4位、出生年月日、出生年份、出生年月、出生月日等组合。 131 | 132 | 思路2： 133 | ngram+自定义分词 134 | 135 | # 9、ES集群规划问题求助 136 | 各位少侠，目前我司doc大概在每天1.5个亿，存储空间的话大概是50G，doc需要保留一年，主要做doc的查询和聚合统计，现在要部署ES集群，想了解一下像这种日质量如何规划ES集群，大概需要几台机器做集群？索引、分片、副本该如何规划，请各位大侠指教。 137 | 138 | 回复1： 139 | 主要看是什么样子的聚合。 140 | ES 集群不适合做超强大的聚合计算。要是几十万数据聚合还是可以的。 141 | 如果是大数据量数据进行聚合，那肯定不行。 142 | 这么说吧， 143 | 100台物理机，20核心cpu40线程，128gb内存，10tbSSD，在30亿条数据基础上做聚合查询，每次聚合时间几十秒甚至几分钟。 144 | 145 | 你这种情况： 146 | 数据量很少，如果只是小聚合，比如100W数据的集合，10台物理机应该能满足 很快的聚合效率。 147 | ES 集合是严重消耗硬件资源的， 148 | 尤其是CPU和CPU LOAD，内存和硬盘，都还好，还有网卡的流量，能用万兆别用千兆，磁盘能用SSD别用普通的。 149 | 150 | CPU 最好可以40核心，最差也要20核心。 151 | 152 | 能拆分成小集群，别使用一个超级大集群。 153 | 154 | ES 是无法做到扩展的，一个集群是有限制的，这个限制包括内存，磁盘，存储的数据量，达到一定数量就到了瓶颈，这时候无法再扩展了。 155 | 156 | 拆分集群是唯一的解决方案。 157 | 158 | 回复2： 159 | 楼上大佬说的非常好了，我再补充一些，对于日志来说，一个分片最好不要超过40G的大小，50G的话最少2-3个分片吧，可以一天一个索引，副本一个就够。一年的话最好做个归档，最差也要做个冷热分离。 160 | 定期关闭索引不要一直开太多影响性能。master节点最好不要放数据，不要数据的话内存可以配小点。 161 | 如果对于要跨很多索引进行聚合的话，性能是非常差的，建议分割开进行聚合之后由拿到的结果进行二次聚合。es也有它的优劣，扬长避短，做好规范和限制。 162 | 163 | # 10、推荐：Logstash：如何使用 Logstash 和 JDBC 确保 Elasticsearch 与关系型数据库保持同步 164 | https://elasticstack.blog.csdn.net/article/details/103874185 165 | -------------------------------------------------------------------------------- /es_accumulate/202002_report.md: -------------------------------------------------------------------------------- 1 | # 1、【聚合分析】一个订单作为一个文档，返回文档中指定field出现次数超过10的文档 2 | 3 | 大家好，拜托帮我看下吧谢谢！ 4 | 5 | 就是求field（produce） 出现次数大于10 的文档，应该能实现的吧？我看官方文档aggregation 那块介绍的太多了，一时没找到，有大佬帮忙看看吗？万分感谢 6 | 比如 produce=牙膏 或者 牙刷 或者 抽纸 之类的，返回在es中出现次数大于10 的 商品的 数量 7 | 8 | 9 | 回复： 10 | 11 | 举例如下：把 12 | "min_doc_count":4 13 | 换成 14 | "min_doc_count":10 就可以了。 15 | ``` 16 | PUT product 17 | { 18 | "mappings": { 19 | "properties": { 20 | "name":{ 21 | "type":"keyword" 22 | } 23 | } 24 | } 25 | } 26 | 27 | POST product/_bulk 28 | {"index":{"_id":1}} 29 | {"name":"牙膏"} 30 | {"index":{"_id":2}} 31 | {"name":"牙刷"} 32 | {"index":{"_id":3}} 33 | {"name":"抽纸"} 34 | {"index":{"_id":4}} 35 | {"name":"牙膏"} 36 | {"index":{"_id":5}} 37 | {"name":"牙膏"} 38 | {"index":{"_id":6}} 39 | {"name":"牙膏"} 40 | 41 | POST product/_search 42 | { 43 | "size":0, 44 | "aggs": { 45 | "name_aggs": { 46 | "terms": { 47 | "field":"name", 48 | "min_doc_count":4 49 | } 50 | } 51 | } 52 | } 53 | ``` 54 | 55 | # 2、推荐：doc values 与 field data 的一些知识整理 56 | 57 | 推荐阅读：https://elasticsearch.cn/question/9325 58 | 59 | doc_value:保存在磁盘中，适用于String（text，keyword）类型，还适用于integer/long/float/double/date 类型等， 而fielddata 只适用于text类型 60 | 61 | fielddata:保存在内存中，适用于text类型 62 | 63 | 64 | # 3、logstash 正则表达式 正确写法 65 | 66 | https://elasticsearch.cn/question/9320 67 | 68 | 老师好：日志如下： 69 | 2020-02-19 10:58:14.325 - [d24692bfc49c440f83a2af3cbd4d8e32///nonautoBack/undwrt/updateImmdLevel] - 更新任务紧急程度耗时:[12]ms 70 | 71 | 想通过正则匹配出：时间，d24692bfc49c440f83a2af3cbd4d8e32，nonautoBack/undwrt/updateImmdLevel，更新任务紧急程度耗时，12这几个字段。 72 | 73 | 尝试使用：%{GREEDYDATA} - \[%{USERNAME:traceid}\/\/\/%{USERNAME:methodName}\] - \[%{[\u4e00-\u9Fa5]+}:name\]:\[%{NUMBER:proceedTime}\] 74 | 但是一直没有出来，请教老师帮忙看下。 75 | 76 | 【回复ok】正确写法： 77 | 78 | %{TIMESTAMP_ISO8601:LogDate} - \[(?[0-9A-Za-z]+)///(?[A-Za-z]+/[A-Za-z]+/[A-Za-z]+)\] - (?.*):\[(?\d+)\]ms 79 | 80 | 可以參考這樣寫法 感謝! 81 | 82 | # 4、ES超大数据集群方案请教 83 | 84 | 现状： ES数据总量100亿左右， 磁盘占用约6T 85 | 86 | 目前有32核 64G内存的机器若干（15台左右），SSD。 87 | 88 | ES内存打算分配20G左右，15台主机可用的os cache 大约在600G左右 ， 89 | 90 | 这样的话 只有约1/10的数据能被os 缓存，90%的数据都在磁盘，这样是不是机器配置远远不够？ 有没有更好的集群方案？ 91 | 92 | 【**Medcl】回复： 93 | 94 | 够不够要看你的需求，除了存储，还有考虑查询响应时间和索引吞吐的需求。 95 | 96 | Elasticsearch 基于 Mmap 的方式读取文件，是按需加载，不需要全部缓存在内存里面的。 97 | 98 | 建议实际压测一下，才知道是否达到你的需求。 99 | 100 | # 5、Elasticsearch经常报429错且数据量锐减 101 | 102 | 当前数据有3个节点，服务器都是6核。每天的数据量在400万左右，开始的时候运行正常。最近经常报429错，而且数据量锐减。线程池大小为7，reject_queue为1000。 103 | 104 | 请教各位大神，可能是哪里出了问题呢？该如何处理啊？万分感谢 105 | 106 | 【回复】 107 | 108 | 如果被reject了，可以适当加大池大小，可以存多一点。 109 | 110 | 根本方法还得提高硬件处理能力。 111 | 112 | https://elasticsearch.cn/question/9315 113 | 114 | # 6、ES SQL怎么查询Join字段 115 | 116 | 【回复】 117 | 118 | 不支持 119 | 120 | 官方回复：You can’t do joins with elasticsearch. 121 | 122 | Better to think your model differently and denormalize your data. 123 | 124 | Parent/child feature is kind of 1-n relationship but I’d only use it if absolutely necessary. 125 | 126 | https://elasticsearch.cn/question/9316 127 | 128 | # 7、script_fields怎么访问父文档属性 129 | 130 | 环境：ES7.5 131 | 132 | 问题：怎么访问myparent中的其他属性，现在默认拿的是父文档id，我想拿 其他属性。求支招............... 133 | 134 | ``` 135 | "script_fields": { 136 | "parent": { 137 | "script": { 138 | "source": "doc['join#myparent']" 139 | } 140 | } 141 | } 142 | ``` 143 | 144 | 【回复】 145 | 拿不到的。 146 | 147 | 脚本里面不支持从子对象里面拿父对象的字段。 148 | 149 | 聚合不了，es 不支持 150 | 151 | # 8、es集群机器 内存使用的一些思考 152 | 153 | 堆内存建议一看：https://elasticsearch.cn/question/9327 154 | 155 | https://juejin.im/post/5d35ae896fb9a07ed8428046 156 | 157 | ![这里随便写文字](https://img-blog.csdnimg.cn/20200326222816365.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaml1c2hpd285ODc=,size_16,color_FFFFFF,t_70#pic_center) 158 | 159 | es是使用的堆内内存，而lucene 使用的 堆外内存。 160 | 161 | elastic 的 Node Query Cache ，Shard Request Cache，Shard Request Cache 都是给查询结果使用的，Indexing Buffer 是存储新的插入文档使用的； 162 | 163 | 而 lucence的os cache 纯粹是让 倒排索引能加载到内存中 供与 查询 ， 164 | 165 | 所以总结就是 es 与luncene 一般是 各占一半内存，但是如果你的es集群 插入业务比较多，建议将jvm 内存增大，如果es集群的查询业务比较多，建议jvm内存 减少一些，让操作系统剩余使用物理内存多一些。 166 | 167 | # 9、求指教：如何在docker中配置logstash多实例，去消费kafka中的同一个topic 168 | 169 | 问题： 170 | 171 | 在docker上部署了elk,想要使用logstash去消费kafka中topic的数据，发现消费的速度跟不上生产的速度，目前想配置多个logstash去消费同一个topic中的数据， 172 | 173 | topic中已经建立4个partition。请问：是在docker下启动多个logstash的contariner吗？假如是的话，docker run的时候配置文件路径需要更改吗？ 174 | 175 | 多个logstash实例共用的同一个config文件还是不同的文件 176 | 177 | 178 | 【回复】： 179 | 180 | logstash是出了名的低效率。不如自己用其它语言写一个消费者。普通笔记本开个CentOS虚拟机（4G内存，所有软件在这虚拟机运行），单线程都可以每秒消费50K，并导入ES。多线程轻松上100K。就算用python把日志 json格式化之后，写日志到文件里，再由filebeat直接对接到ES都几十K。 181 | 182 | filebeat ---- kafka ----- python(json格式化 file) -----filebeat-----ES (简单) 183 | 184 | 或者 185 | 186 | filebeat ---- kafka ----- python(json格式化） ---ES （稍复杂，需要调用ES接口写入数据) 187 | 188 | https://elasticsearch.cn/question/9348 189 | 190 | 191 | 192 | 193 | -------------------------------------------------------------------------------- /es_accumulate/202004_report.md: -------------------------------------------------------------------------------- 1 | # 1、给es集群一键安装插件的方法有吗？ 2 | 3 | 目前，es集群中只有三个节点，发现每次安装新的插件时，都需要手动给每个节点都安装一遍插件，觉得很繁琐，不知道有没有更好的给es集群安装插件的方式？之所以需要频繁安装es的插件，是因为发现使用es插件检索数据的性能，比使用javaAPI查询的性能快很多，所以才需要频繁开发插件来适应对时延的性能要求，导致现在每来一个业务需求都需要开发插件，然后频繁给es集群手动安装插件，觉得好繁琐，不知道有没有更好的方式？ 4 | 5 | 【medcl】 6 | 可以用一些其他的工具来做，比如 Ansible，编写好 Ansible playbook，一键安装没问题 7 | 8 | # 2、ElasticSearch查询非常缓慢 9 | 10 | 初来乍到，想请教下ES的配置推荐，现在在一个测试环境，只保存3天的日志，大概3亿条数据，查询时非常缓慢。 11 | 12 | 我的配置大概是这样的，容器化部署ES。 13 | 14 | 1. 2个data节点容器各自10G内存，其中每个data节点的jvm分了5G，剩下了5G给Lucene。data节点使用普通硬盘，并且每个节点占用空间200G左右。 15 | 16 | 2. 3个master节点各自4G内存，jvm占用2G。 17 | 18 | 3. 2个client节点，各自2G内存。 19 | 20 | 现在只是普通的查询所有的数据，在kibana上查询最近3天的数据，不添加其他任何搜索搜索条件， 每次查询都要耗时2分钟所有。 21 | 22 | 请问，这种情况下的数据，应该怎么样的配置更合理，另外ES方面还有没有其他优化的点。 23 | 24 | 另外，再附上索引的mapping，因为是对接的日志文件，又是多种类型的日志文件，比如Kubernetes日志，docker日志，普通文件的日志，所以字段较多。 25 | 26 | 经常搜索的字段，也就是message字段。不过kibana上超时的搜索，未填写任何搜索字段，仅搜索了最近3天数据，搜索也特别耗时，有时甚至会超时。 27 | 28 | 【回复】 29 | 30 | 1. Kubernetes日志，docker日志，普通文件的日志——这些日志应该放在不同的索引里，这样每次查询就只要查询对应的索引就可以了，缩小搜索范围； 31 | 2. 分片数控制在每个分片20GB以下； 32 | 3. 默认的mapping是text+keyword，手动在index_template里配合适的mapping会好很多。 33 | 4. 感觉内存给的太小了。 34 | 35 | https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-search-speed.html 36 | 37 | # 3、【function_score】ES如何实现=>需求类似：用户会员等级越高，发布的内容越优先被检索到。 38 | [回复】 39 | 40 | field_value_factor 结合 function_score实现 41 | 42 | https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-function-score-query.html 43 | 44 | https://elasticsearch.cn/question/9926 45 | 46 | # 4、es普通的data节点down掉，集群有1分多钟的时间不可用 47 | 】我是一个3master，2data的集群，在进行高可用的测试时，其中一个data节点down掉后，集群变得不可用， 48 | 49 | 要等三个超时时间，大概90多秒的时间，集群才能恢复正常，请问这个问题是什么原因，大家是如何解决的？ 50 | 51 | 【回复】 52 | 你这种现象应该不是彻底进程挂掉，而是类似断网连接不上但是ES又没有认为该节点进程彻底死掉，所以会等三个超时时间不断去确认data节点是否存活。前端时间针对这种现象我有测试过，如果这个data节点上没有主分片的话还好，不会对写入有什么影响。 53 | 54 | # 5、elasticsearch单索引过大问题 55 | 56 | 由于业务的发展,线上有一些累积增加的数据索引,单索引目前最大的已经有20亿的数据,目前分片5个副本1个,查询很慢,大概八九秒左右,有没有什么优化方法,比如将一个大索引分割成几个小的索引,或者增加副本数量,是否会增加查询性能.大佬们有没有好的解决办法?目前es版本5.6.9 57 | 58 | 【回复】 59 | 单个分片的索引数量，集群的总分片数，一次搜索需要处理的数据量，执行什么样的搜索语句，这些都是影响搜索性能的关键因素。 60 | 61 | 怎么处理好这些影响因素，怎么根据业务特点制定合适的索引策略，用什么样的搜索语句去获取搜索结果，这些都是需要好好考虑和好好设计的。很明显，环境中出现了这种异常索引，说明索引策略是有问题的，需要整改索引策略。 62 | 63 | 如果数据量不是很大，比如最大的索引还只有20亿条，如果这个增长是经历了很久才长上来的，那么最简单的做法是增加索引的分片，这样就可以使得每个分片的索引数量不会太大了，因为ES底层的lucene搜索时，都是针对分片维度进行的。 64 | 65 | 但是增加分片数只能针对新生成的索引，所以如果想改善旧索引的搜索性能，可以把现在的索引reindex到新的索引中（在集群比较空闲的时候做） 66 | 67 | 如果数据量增长比较快，那么简单的增加分片就无法解决查询性能问题了，就需要更精细化的索引策略了。比如数据搜索时，会携带时间维度信息，那么索引可以按天或者按月（根据数据特点来定）生成，这样搜索时先根据时间确定索引范围，然后再执行搜索，这样可以大大提高搜索性能。当然，如果数据搜索没有按天/月搜索的一些属性，比如是需要全局搜索的，这个时候索引的生成策略可以考虑在业务上做细化，比如某些业务的放在一个索引里。 68 | 69 | 如果不好按时间生成索引，也可以考虑rollover机制，这种策略就是等到数据量积累到一定程度后，再生成一个新的索引，比较适合一些时间上数据量的变化不好评估的数据。 70 | 滚动也好，按时间生成新索引也好，都是为了控制单个分片的数据量不太大。但是如果数据量大到一定程度，每次需要搜索的东西，需要匹配或处理的东西很多时，也会碰到搜索瓶颈，这时就需要根据业务特点，做更精细化的索引分配，搜索时尽量减少索引搜索范围。 71 | 72 | 总之，索引策略需要结合业务特点进行设计，简单快捷的可以考虑按时间生成新索引，按数据量rollover索引，扩大索引分片数量等 73 | 74 | # 6、怎样查出占用cpu和内存的查询？ 75 | 76 | 日志用的es集群平时基本上只提供kibana给人查日志用，grafana上有个别图表也会用到 77 | 78 | 但是因为grafana上配置了这个es的数据源，有人有权限可以看到ES地址，也不保证有人直接通过程度连接ES的可能。 79 | 80 | 最近看监控，经常不定期的会有一波所有节点old gc数量突然增多，有时候是突然所有节点cpu升高的情况。 81 | 82 | 但是在慢查日志里，并没有发现有用时特别长的查询，也没发现有和平时不一样的查询(也有可能混在大量的查询里我没有发现) 83 | 84 | 怎么样能比较有效的发现是哪个查询导致了这种情况呢，或者如果不是查询的话，还有哪些原因可能导致这种现象。有什么好的查问题的手段吗？ 85 | 86 | 另外延伸出来的话题就是怎么对kibana进行管控，比如限制查询的时间范围，限制查询中设置的size过大，限制查询的频率(因为越慢的查询有人越等不及多刷新好几次)等等。 87 | 88 | 【回复】 89 | 90 | ES 内存 GC, cpu load 等问题 91 | 1首先要考虑并发查询的量,如果量非常的大,是很大可能造成CPU和load飙升. 92 | 2如果查询量很小,那看看是否存在重型的聚合查询,(基于10亿数据的聚合),又存在一定量的并发,非常非常大的几率造成cpu和load飙升. 93 | 3系统的某些参数,也会造成load负载飙高.比如虚拟内存相关的配置. 94 | 4linux 系统如果配置的不好,也会出现问题 95 | 5ES集群瞬间删除大量(可能是几百个索引或者几百GB)的索引,短时间内io操作频繁,会引起load标高 96 | 97 | 访问限制问题 98 | 1高版本已经有权限的控制了 99 | 100 | 2可以利用linux防火墙,将es,kibana等封起来,只对外暴露一个URL.比如nginx代理服务器 101 | 102 | 3利用nginx可以对访问的url进行重写,过滤掉一些非法的操作和参数 103 | 104 | 4也可以修改kibana和es源码进行请求的校验 105 | 106 | # 7、【别名】关于按日拆分索引的java实现 107 | 108 | 需要按日拆分索引去存储文档，有两种实现方式，想咨询下优劣或更好的方式 109 | 110 | 索引命名方式index-yyyy-MM-dd 111 | 112 | 第一种是在存储文档前用exists API判断index-yyyy-MM-dd是否存在，没有则创建一个新索引再插入文档。 113 | 114 | 第二种是创建一个索引模版，并在action.auto_create_index中添加index*，则没有索引的话会直接新建索引。 115 | 116 | 感觉第一种会有并发问题，而且每次判断也繁琐。第二种过于自由... 117 | 118 | 想知道有没有什么好的实现方式 119 | 120 | 【回复】 121 | 122 | 我们一直用的第二种。模板就是为了解决需要创建一类具有相同结构的索引而存在的。 123 | 124 | 只要管理好就没啥问题。 125 | 126 | 按日拆分的索引基本上结构是一致的。 127 | 128 | 这个需要看查询的时候是否指定了索引中存在的日期字段范围。如果指定了范围并且范围不是太大的话，性能差别可以忽略，这个时候可以用别名。如果没指定的话通过索引名或者范围比较小的别名效果更好。 129 | 130 | 总的来说，用别名或者用索引名是一个查询范围的问题，更精确的搜索范围效果更好，不过如果查询范围比较大性能也可以接受的话，也没啥大碍，别名更方便管理和使用。 131 | 132 | # 8、没有索引数据，ES节点启动候就占用3个G的内存？ 133 | 134 | 软件版本：ES6.5.4 135 | 运行环境： 136 | OS：Linux CentOS 7.4 137 | CPU：16C 138 | Mem：32G 139 | ES Heap：16G 140 | 141 | ES集群搭建完成，启动后，数据节点的堆内存占用就试用了3个G，没有新增其他插件和字典库，这3个G的内存，后续会通过GC回收掉吗？启动是加载了什么会占用3个G? 142 | 143 | 【回复】 144 | 这3G是jvm分配使用的内存，很多应该是临时对象，young gc后就能释放。 145 | 你可以通过jstat -gc pid命令查看old区内存使用情况 146 | 147 | # 9、scroll search会产生额外一次查询 148 | 149 | ES版本：6.3 150 | 按照官方文档操作：https://www.elastic.co/guide/e ... ments 151 | 152 | 发现第一次search是多余的（循环外的：SearchResponse searchResponse = client.search(searchRequest, RequestOptions.DEFAULT); 153 | ） 154 | 155 | 假设分页size是2000，记录数2500； 156 | 157 | 那循环外第一次search返回2000 158 | 循环内第一次返回2000 159 | 循环内第二次返回500 160 | 161 | 第一次的查询是浪费的，请问这个问有解吗？ 162 | 163 | 【回复】 164 | 165 | 如果是scroll的话，searchRequest需要设scroll参数 166 | 167 | searchRequest.scroll( TimeValue ) 168 | 169 | 才会去执行scroll搜索的，如果不设就是普通检索了。 170 | 171 | 从第二次scroll开始，就不能用searchRequest了，要用SearchScrollRequest，它的最主要的参数是scrollId，new SearchScrollRequest(scrollId) 172 | 173 | 然后每次需要重新做这个SearchScrollRequest传进client，直到结果里的数据list为空，代表符合你query条件的数据已经被完全滚动了 174 | 175 | # 10、中文拼音自定义混合搜索的问题 176 | 177 | 数据里面有 小蜜 小米 小迷 三条数据 178 | 我想搜索 小米 会先出现 小蜜 接下来是小米 179 | 我想问下中文拼音混合搜索具体如何测试和搜索 180 | 谢谢大佬 181 | 182 | 【回复】 183 | 184 | 拼音和汉字单独定义，搜索的时候，给汉字的权重高一些，拼音的权重低一点 185 | ``` 186 | { 187 | "productName": { 188 | "type": "text", 189 | "analyzer": "ik_smart", 190 | "search_analyzer": "ik_smart", 191 | "fields": { 192 | "pinyin": { 193 | "type": "text", 194 | "analyzer": "ik_pinyin_analyzer", 195 | "search_analyzer": "ik_pinyin_analyzer" 196 | } 197 | } 198 | } 199 | } 200 | ``` 201 | 202 | 203 | 204 | -------------------------------------------------------------------------------- /es_accumulate/202005_report.md: -------------------------------------------------------------------------------- 1 | # 1、网站报错，elastic索引莫名其妙的被关闭，需要重新开启索引？ 2 | 暴露公网，被关闭索引 3 | 第二天上班发现网站打不开了，使用elasticsearch-head查看其他的索引变成index:close，莫名其妙的被关闭了；需要重新开启索引才行。而且生成了一个索引名：a_close_your_elastic_port9200_then_opentheindexagain； 4 | 我有二个centos服务器都是这种情况，就隔几分钟几乎同时发生的。是配置的问题还是被别人黑了 还是怎么了 奇了个怪？ 5 | https://elasticsearch.cn/question/10020 6 | 7 | 原因：看样子是被人为的关闭的，你是不是把 es 暴露在公网了，有很多脚本会自动扫描 8 | 9 | # 2、esrally官网压测的数据，在内网有吗？ 10 | Q：esrally 是一个压测工具，我们可以下载下来自行压测自己的集群，当然官方也有基于 esrally 的 benchmark 持续更新。详细参考：https://elasticsearch-benchmarks.elastic.co/ 11 | 12 | # 3、es 放到 data 目录里的 文档json 没压缩吧？ 13 | A：底层 lucene 的数据结构分为多种，行存原始 json 在 store field 中是有压缩的，支持不同的压缩算法，可以配置，默认是LZ4，通过 best_compress 参数可以选择压缩比更高的 deflate，但性能也有些影响。列存的 doc value 有非常类似 RLE 的编码策略压缩，但是做的不完善。我们在内核优化版本里面做了加强。 14 | 15 | # 4、ES5以上版本可以设置flush的interval吗？ 16 | 我看老版本的ES文档上是有 index.translog.flush_threshold_period 这个参数的，可以指定多久后进行一次flush操作，默认是30分钟。 17 | 18 | 但我在ES5以上版本试了下发现这个参数已经没有了，只能设置index.translog.flush_threshold_size参数，指定translog达到一定大小后才flush。 19 | 20 | 这样会出现一个问题，当我把flush_threshold_size设置的较大时，比如4gb，所有不再有写入的索引，它们的每个分片上都有0-4g不等大小的tranglog文件，这些文件加起来占用的磁盘空间很可观。我只能每天手动对全部索引做一次flush才能释放掉。 21 | 22 | 为什么会取消flush_threshold_period这个参数呢，如果有了这个参数，我上面说的情况就可以解决了。 23 | 24 | 25 | 回复： 26 | 从 5.0 版本开始，索引的设置，不再使用配置文件elasticsearch.yaml 或者命令行。 27 | 28 | In previous versions Elasticsearch allowed to specify index level setting as defaults on the node level, inside the elasticsearch.yaml file or even via command-line parameters. From Elasticsearch 5.0 on only selected settings like for instance index.codec can be set on the node level. All other settings must be set on each individual index. To set default values on every index, index templates should be used instead. 29 | 30 | 可以使用动态索引设置 31 | ``` 32 | curl -XPUT 'localhost:9200/my_index/_settings' -d ' 33 | { 34 | "index" : { 35 | "translog" : { 36 | "flush_threshold_size" : "512mb" 37 | } 38 | } 39 | }' 40 | ``` 41 | 42 | https://www.elastic.co/guide/en/elasticsearch/reference/5.0/index-modules-translog.html 43 | 44 | # 5 、【经常被问】Kibana 中 beats监控数据如何计算得到的呢？ 45 | medcl 回复：这种 rates 吞吐，用 datehistgram aggs，取对应指标的 count 就出来了。 46 | 47 | # 6、聚合查询是否支持类似SQL IN的用法 48 | SELECT COUNT(*) FROM test_select WHERE transID IN (SELECT transID FROM test_select WHERE `msg` = "TransStart" AND `type` = "Login") AND `result` = "Succ" 49 | 50 | 在如上数据中执行以下SQL查询，直接查找出 result为Succ并且type=Login的数据，在ES中是否支持这种查询呢？ 51 | 52 | 【medcl】：Elasticsearch 暂时还不支持 IN query。 53 | 54 | # 7、关于 CrateDB 和 Elasticsearch 55 | 有人实际用过CrateDB吗？感觉基于Elasticsearch的GroupBy做了一些不同的调增，并支持join 56 | 附文：https://crate.io/cratedb-comparison/cratedb-vs-elasticsearch/ 57 | 58 | medcl 回复：join 慎用，如果一定要用，用关系型数据库。 59 | 60 | # 8、【数据清洗】请问一下，用canal同步复杂数据到ES的问题 61 | 需要实现一个功能，增量或者全量同步数据到ES，但是映射的字段比较复杂，很多字段需要计算后得出的值才能映射过去，如果采用canal能实现这个功能吗，很多字段不是一对一映射，当某个字段改变了，需要经过复杂计算，然后把计算结果同步到ES中的某个字段 62 | 63 | 回复：一个参考，canal数据经过kafka 然后接spark stream 翻译后再接kafka ,如果数据处理简单，可以用ingest节点处理 64 | 65 | # 9、es API 查询 和 数据类型的奇妙关系 66 | 碰到了一个小问题： es 版本为 7.6， text类型的数据 使用 wildcard 方法是无法查出来的，意识到这个问题很好解决。但是想学习一下关于es 数据结构比较深层次的知识，以便于再碰到这样的问题，我能明白是因为什么而查不出来。 67 | 求大神推荐较全的资料，非常感谢 68 | 69 | 回复：简单说下， 70 | 第一：es在5.x后分为两种数据类型：keyword和text 71 | 两种类型适用场景不同： 72 | keyword适合精准匹配，举例：手机号字段 73 | text适合基于分词的全文检索，举例：正文内容字段 74 | 75 | 第二：检索类型 wildcard类似mysql like语句，本质也是模糊匹配 不是全文检索 76 | 不同检索类型的选型 建议：kibana dev tool 77 | 对比测试下 78 | 79 | 【medcl】：wildcard是通配符匹配，要作用在一个完整的字符串上面。 80 | keyword 类型的字段是一个整字符串term； 81 | text 类型会分词成多个字符 term； 82 | 83 | 可以了解下 Elasticsearch 的 Mapping 和 Lucene 的原理 。 84 | # 10、关于index.translog.durability的疑问 85 | index.translog.durability有两个参数，request和async,我对这两个参数都不是很理解。 86 | 官方文档7.7版本：https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-translog.html# 87 | request的解释是 88 | (default) fsync and commit after every request. In the event of hardware failure, all acknowledged writes will already have been committed to disk. 89 | 这里是指什么意思啊？是指每个请求都执行一次fsync，可是不是说fsnyc代价大，要放到translog中吗？ 90 | 然后第二个参数async解释是 91 | fsync and commit in the background every sync_interval. In the event of a failure, all acknowledged writes since the last automatic commit will be discarded. 92 | 如果选择了这个参数后又会导致什么变化呢？ 93 | 看了很久都没搞懂，来论坛问问大家，谢谢了。 94 | 95 | 回复：fsync：对应系统级别的中的direct I/O，对直接写入到磁盘中，不经过page cache 96 | async：对应系统级别的buffer I/O，会写到page cache，在{index.translog.sync_interval}时间以后会把page cache中的内容再写入到磁盘。比fsync快，但是在index.translog.sync_interval期间机器宕机的话，这些数据没写入到磁盘中，会丢失。 97 | 98 | # 11、ElasticSearch 7.x 不需要优化分片的数量了吗？ 99 | 100 | 每个分片上的数据量过大会导致查询过慢，因此当数据量过大时需要指定分片的数量来保证每个分片数据大小在30G以下。 101 | es7.x版本之后不需要指定分片数量了吗？默认一个分片不会影响性能吗？本人才疏学浅，没在官方文档中找到答案。望大佬解答 102 | 103 | 【medcl】使用 ILM 自动进行切分很方便，可以限制单个分片固定大小比如 30G。 104 | 105 | 分片（shard）：一个ES的index由多个shard组成，每个shard承载index的一部分数据。 106 | 107 | 副本（replica）：index也可以设定副本数（numberofreplicas），也就是同一个shard有多少个备份。对于查询压力较大的index，可以考虑提高副本数（numberofreplicas），通过多个副本均摊查询压力。 108 | 109 | shard数量（numberofshards）设置过多或过低都会引发一些问题：shard数量过多，则批量写入/查询请求被分割为过多的子写入/查询，导致该index的写入、查询拒绝率上升；对于数据量较大的inex，当其shard数量过小时，无法充分利用节点资源，造成机器资源利用率不高 或 不均衡，影响写入/查询的效率。 110 | 111 | 对于每个index的shard数量，可以根据数据总量、写入压力、节点数量等综合考量后设定，然后根据数据增长状态定期检测下shard数量是否合理。 112 | 113 | 基础架构部数据库团队的推荐方案是： 114 | 115 | 对于数据量较小（100GB以下）的index，往往写入压力查询压力相对较低，一般设置3~5个shard，numberofreplicas设置为1即可（也就是一主一从，共两副本） 。 116 | 117 | 对于数据量较大（100GB以上）的index： 118 | 119 | 一般把单个shard的数据量控制在（20GB~50GB） 120 | 121 | 让index压力分摊至多个节点：可通过index.routing.allocation.totalshardsper_node参数，强制限定一个节点上该index的shard数量，让shard尽量分配到不同节点上 122 | 123 | 综合考虑整个index的shard数量，如果shard数量（不包括副本）超过50个，就很可能引发拒绝率上升的问题，此时可考虑把该index拆分为多个独立的index，分摊数据量，同时配合routing使用，降低每个查询需要访问的shard数量。 124 | 125 | # 12、对于纯写入节点是否有必要把index buffer设置很高呢？ 126 | indices.memory.index_buffer_size 这个值默认是10%，我测试过纯写入情况下，把这个值分别调成30% 50% 80%，发现数据写入速率只有轻微的提高。 127 | 128 | 我的一个es集群，由于经常有从其他数据源导入数据，导入完成后不再有写入，只有纯查询的情况，为了避免导入时影响查询，现在是专门设置了一组节点用于导数据，完成之后分片迁移到其他节点。 129 | 130 | 1.这组仅用于导数据的节点，有必要把index_buffer_size调大吗。除了这个参数外，还有其他参数需要调整吗。 131 | 2.假如调成了80%，是代表它会独占这80%内存，仅剩20%给其他用途，还是说内存是争用的，它最大能够用到80%呢。 132 | 133 | 回复：Q1:这个问题还挺有意思的，我尝试着回答下。首先index buffer这个池是用来缓冲数据写入的，数据写入buffer以后，默认1s以后就会被写入磁盘。所以除非你能在1s以内写入大于buffer池的内容（起码有几百M到几G），不然单纯的提升buffer池是没意义的。 134 | 再回到你的写入场景。你现在是要尽量的提升写的性能，可以在疯狂写入的期间（1）把集群rebalance关闭（2）把shard副本关闭，相信可以提升不少的写入性能。如果都做了，可以（1）降低下refresh的频率 135 | 136 | （2）提高merge_factor的值，降低merge次数。但是我觉得可能意义不大。 137 | 最后，确保没有使用自定义id，bulk性能差非常多。 138 | Q2:没记错是个最大值。 139 | 140 | # 13、删除index下type的mapping 141 | 142 | 我搜索到的是可以删除某个type下的数据，那么还是留了mapping 143 | 我想把mapping也删除，请大佬指点，谢谢。 144 | 145 | 已知的删除数据语句如下： 146 | ``` 147 | POST index/type/_delete_by_query?conflicts=proceed 148 | { 149 | "query":{ 150 | "match_all":{} 151 | } 152 | } 153 | ``` 154 | 回复：mapping 建立完後只可以增加字段 不可以修改或刪除字段。 155 | 要修改mapping 用reindex 去處理，會比較好。 156 | 不然就是直接刪除整個index 重建。 157 | 158 | 159 | -------------------------------------------------------------------------------- /es_accumulate/202008_report.md: -------------------------------------------------------------------------------- 1 | # 1、【常见问题】spark调用bulkprocessor批量入库es，存在少量丢数 2 | 3 | spark调用bulkprocessor批量入库es，存在少量丢数 4 | 5 | elasticsearch使用spark调用bulkprocessor批量入库es，2亿数据量丢数几百条不知道怎么定位丢数，index字段数据类型已定制成全keyword类型，似乎不是因为类型导致丢数，数据源是标准交易数据，脏数据的概率比较低，请问大家有思路定位分析一下丢数原因 6 | 7 | 8 | 探讨： 9 | 10 | 目前有想过两个比较笨重的方式 11 | 12 | 1.入库少量数据，重现丢数场景，逐条打印，对比数据。这个量级起码也要几十万，很笨重 13 | 14 | 2.在数据源进入spark之前，就增加一个自增字段，并以此字段为自定义ID（之前是进入spark再自增ID），再复现丢数场景后，通过字段查询，找到丢数的字段id，对应到源数据，再对比数据分析 15 | 16 | 不知道大伙有没有更快捷的的方式定位分析一下 17 | 18 | 19 | # 2、《Elasticsearch源码解析与优化实战》这本书中,有关6.x的新版副本恢复方法. 20 | 21 | 书中集群启动流程章节中,副分片recovery模块中有这样描述到: 22 | 23 | 旧版副分片恢复都会去从主分片拉取全量的数据.在ES6.x后,优化了这个操作,不拉取全量数据,而是标记每个操作.在正常的写操作中,每次写入成功的操作都分配一个序号,通过对比序号就可以计算出差异范围. 24 | 25 | 实现方式是: 添加了global checkpoint和local checkpoint,主分片负责维护global checkpoint,代表所有分片都写入这个序号的位置,local checkpoint代表当前分片已写入成功的最新位置,恢复时通过对比两个序列号,计算出缺失的数据范围,然后通过translog重放这部分数据 26 | 27 | 疑问一: 所有分片都写入这个序号的位置,这个所有分片是指主分片还是副分片还是主副分片? 28 | 29 | 疑问二: 代表当前分片都写入成功的最新位置,这个分片又是指什么分片? 30 | 31 | 疑问三: 对比两个序列号,计算出缺失的数据范围,那没缺失的数据是如何恢复到副本的? 32 | 33 | 34 | 回复： 35 | 36 | Q:所有分片都写入这个序号的位置,这个所有分片是指主分片还是副分片还是主副分片? 37 | 38 | A:主分片 && 副分片 都到达了这个序号 39 | 40 | Q:代表当前分片都写入成功的最新位置,这个分片又是指什么分片? 41 | 42 | A:主分片，或者副分片 43 | 44 | Q:对比两个序列号,计算出缺失的数据范围,那没缺失的数据是如何恢复到副本的? 45 | 46 | A：数据没有差异，无需拷贝数据，这个过程就快速完成了 47 | 48 | # 3、index的时候那些routing信息存了有什么用？？？ 49 | 50 | 原来一直以为在PUT a/b/c?routing=XXX时，这些XXX信息是不存的。 51 | 52 | 后来发现它是存到文档里面去的。 53 | 54 | 想了几天也没有明白存这些信息有什么用？岂不是浪费空间？ 55 | 56 | “你的问题补充太简单了，一个详细的问题描述能够让大家更快的帮助你，请继续完善问题描述！”？？？ 57 | 58 | 回复： 59 | 60 | routing非常有用，可以用来解决很多天生分布式带来的问题，比如算分，比如顺序，比如搜索的正确性。一般场景下很难用到。 61 | 62 | https://elasticsearch.cn/question/10654 63 | 64 | # 4、elasticsearch多模块是否被覆盖 65 | 66 | 我的elasticsearch版本是7.7.1。 我的想法是ES在初始化索引时不创建副本，不刷新索引，只有一个主分片。 67 | 68 | 创建索引后如果遇到logstash-nginx-*的文档就将文档写入logstash-nginx索引里，然后将刷新时间改为120s, 30个主分片，1个副本。 69 | 70 | 回复： 71 | template里面order的优先级，越大的会覆盖小的 72 | 73 | # 5、es7.1es 批量更新字段值报错 74 | 75 | 回复： 76 | ``` 77 | POST test/_update_by_query 78 | { 79 | "script": { 80 | "lang": "painless", 81 | "source": "if(ctx._source.age== 29){ctx._source.age= 30}" 82 | } 83 | } 84 | ``` 85 | 我测试了是可以的。v7.8 86 | 87 | # 6、查询量大时，总有少量请求响应时间长，怎样避免呢？ 88 | 比如一个比较简单的查询，根据用户id查询这个用户的信息，正常情况下都是几ms的响应时间。 89 | 90 | 当qps到达几千每秒时，总有0.1%不到的比例的查询，响应时间会达到十几或者几十ms，如果是对响应时间要求高的情况，可能就超时了。 91 | 92 | 服务器资源给的非常充足，每台服务器的cpu使用率连10%都不到，仍然会有这种情况。这样的话即使再加服务器，也没法解决问题。 93 | 94 | 这种情况可能是什么原因呢，有办法通过调优吗，达到在服务器负载不高的情况下，接近100%的快速响应。 95 | 96 | 回复： 97 | 98 | 做到100%的无毛刺是很难的，有时候网络抖动、GC、磁盘等都会出现毛刺的。 99 | 100 | 要解决这个办法，最有效的就是使用补偿查询的方式，当某个请求耗时超过一定比率后，比如超过5ms还未返回，则立即再发出一条一模一样的请求，哪个优先返回用哪个。 101 | 102 | 回复2： 103 | 104 | 这种情况一般是查询额外触发了缓存去缓存大量数据，比如 查询5次 会触发缓存， 聚合也会触发缓存，腾讯云Elasticsearch Service 服务做过这方面的内核优化 。 105 | -------------------------------------------------------------------------------- /es_accumulate/202009_report.md: -------------------------------------------------------------------------------- 1 | # 1、logstash 如何将如下日志中的时间（非data格式）转换为@timestamp 2 | 3 | 萌新遇到logstash收集日志是无法过滤出非格式化的时间，日志片段如下 4 | 5 | [SCRIPT - MUST] 2020.09.23 16:30:31 线程(0)连接(1460) 6 | 7 | filter 应该怎么写 才可以将 2020.09.23 16:30:31 提取出来当作@timestamp 8 | 9 | ``` 10 | filter { 11 | grok { 12 | pattern_definitions => { "GROKTIME" => "%{YEAR}.%{MONTHNUM}.%{MONTHDAY} %{HOUR}:%{MINUTE}:%{SECOND}" } 13 | match => { "message" => "%{GROKTIME:groktime}" } 14 | } 15 | date { 16 | match => [ "groktime", "yyyy.MM.dd HH:mm:ss"] 17 | remove_field => ["groktime"] 18 | } 19 | } 20 | ``` 21 | 22 | # 2、es 如何在should 的查询集合中取最大的那个 23 | ``` 24 | "should": [ 25 | "match_phrase": {"query": "青梅竹马", "boost": 1}, 26 | "match_phrase": {"query": "青梅", "boost": 0.5}, 27 | "match_phrase": {"query": "竹马", "boost": 0.5}, 28 | ] 29 | ``` 30 | 如果有一个doc 匹配上了“青梅”，“竹马”， “青梅竹马”。我should出来的得分不希望是三个得分相加，而是取最大值。 31 | 32 | 拜托各位大佬，都来给点建议吧。 33 | 34 | 回复： 35 | 36 | 用dis_max，文档是 https://www.elastic.co/guide/en/elasticsearch/reference/7.2/query-dsl-dis-max-query.html 37 | 38 | 39 | 40 | # 3、ES全量备份与增量备份 41 | 42 | 一、描述：ES权威指南中文版中关于ES的备份有下面这么一句： 43 | 44 | “你的第一个快照会是一个数据的完整拷贝，但是所有后续的快照会保留的是已存快照和新数据之间的差异。随着你不时的对数据进行快照，备份也在增量的添加和删除。这意味着后续备份会相当快速，因为它们只传输很小的数据量。” 45 | 46 | 二、问题： 47 | 1、如何判断各个快照间的依赖关系？是否可以通过命令查询出来？ 48 | 49 | 2、都是增量，意味着，快照一直都要保留？ 50 | 51 | 3、假设每天或每周对ES做一次快照，后续的快照都是增量的备份，在恢复完整索引的时候，就是需要从第一个快照到后面的所有快照数据都在？ 52 | 53 | 4、后续快照都是增量备份，这个空间只涨不减这个就不大合理了吧。 54 | 55 | 回复： 56 | 57 | 以下仅为个人理解，如有其它见解请不吝赐教： 58 | 59 | 先回答你的问题1. 不同快照之间有相同索引，那么就可能存在依赖，但是并不是所有数据都对旧快照的文件存在依赖关系。没有命令可以查询 60 | 61 | 2. 如果你不删除旧的快照，文件会一直保留 62 | 63 | 3. 依据你恢复的快照决定，存在依赖的就会要求相关旧文件 64 | 65 | 4. 快照需要定期清理的 66 | 67 | 再谈谈快照机制，快照实际就是对lucene文件以及es整合配置的一次备份，备份的主要内容是，lucene core索引文件（实际存储的数据文件），es的配置（存储了如何确定一个索引包含哪些lucene文件的相关配置）。 68 | 69 | 快照的机制基于lucene的持久化原理，1.只会对数据进行新增，也就是新创建文件，不会修改旧文件；2. 修改数据会执行，将旧数据标为删除，然后新增新数据索引；3. 索引定期进行合并（merge），合并也是生成新的文件，然后删除合并的相关文件。 70 | 71 | 以上就是说，一个索引，数据一旦变更，那么只会出现新文件生成，旧文件删除。快照就是基于这样的理论去实现的。 72 | 73 | 74 | 继续你的问题。很大一部分是文件的依赖关系能保持多久，这个很难回答。正常来讲，如果你的索引的旧文件没有发生合并，那么这个依赖文件就会一直存在。如果发生合并，那么依赖关系就不存在了。 75 | 76 | 总的来说，定期清理快照是非常有必要的。 77 | 78 | # 4、es重建索引，Id字段生成算法变更 79 | 目前生产环境有索引A，由于历史缘故，id字段值为UUID 80 | 81 | 现在想把id生成算法改为hash(name+age+sex+iolid) 82 | 83 | 怎么通过重建索引实现 84 | 85 | 生产环境目前6台机器，100多个T数据 86 | 87 | 找了一些资源都不满足要求，请求大神回复 88 | 89 | 回复： 90 | 91 | 我找了两个相关的问题。 92 | 93 | painless没有现成的hash算法，可以自己实现，然后reindex指定_id。我也不知道效率怎么样，楼主可以试试。 94 | 95 | 1. stackoverflow is-it-possible-to-have-a-computed-id-field-by-hashing-other-fields-of-the-docum 96 | 97 | 2. discuss.elastic.co how-to-change-a-documents--id-during-a-reindex 98 | 99 | # 5、elasticsearch能不能实现判断是否存在字段，然后再添加查询条件 100 | 101 | 使用java的RestHighLevelClient。 102 | 103 | 问题是建立在这样的情况下： 104 | 105 | 1、多个索引在一个查询语句同时查询，结果进行排序； 106 | 107 | 2、每个索引之间字段不完全相同，需要对不同索引添加不同的查询条件，希望能通过判断某索引的某field是否存在，然后针对field添加只作用于这个索引的查询条件（这个查询条件不影响查询其他没有这个字段的索引）； 108 | 109 | 索引之间不需要关联，只是想要一个多索引查询能针对每个索引添加个性查询条件 110 | 111 | 感谢大神们帮忙 112 | 113 | 回复： 114 | 115 | 可以实现的，组合多个bool查询。比如下面这个示例： 116 | ``` 117 | "query": { 118 | "bool": { 119 | "should": [ 120 | { 121 | "bool": { 122 | "must": [ 123 | { 124 | "term": { 125 | "query-field": { 126 | "value": "query-term" 127 | } 128 | } 129 | } 130 | ], 131 | "filter": [ 132 | { 133 | "terms": { 134 | "_index": [ 135 | "index-1", 136 | "index-2" 137 | ] 138 | } 139 | } 140 | ] 141 | } 142 | }, 143 | { 144 | "bool": { 145 | "must": [ 146 | { 147 | "term": { 148 | "no-match-query-field": { 149 | "value": "no-match-query-term" 150 | } 151 | } 152 | } 153 | ], 154 | "must_not": [ 155 | { 156 | "terms": { 157 | "_index": [ 158 | "index-1", 159 | "index-2" 160 | ] 161 | } 162 | } 163 | ] 164 | } 165 | } 166 | ] 167 | } 168 | } 169 | ``` 170 | 171 | # 6、ES集群负载不均的问题 172 | 173 | 3台机器，6个节点，第一台机器的两个节点负载相比其他机器高很多，Java客户端配置了IP轮巡，还是这种情况 174 | 175 | https://elasticsearch.cn/question/10740 176 | 177 | 回复： 178 | 179 | 问题解决了， 180 | 181 | 是由于第一台机器内存不足造成的，加了内存恢复正常了， 182 | 183 | 总结原因，是因为系统内存不足，留给Lucence的内存空间不够导致查询缓慢，分配的查询任务由于慢造成任务堆积 184 | 185 | 186 | -------------------------------------------------------------------------------- /es_accumulate/202010_report.md: -------------------------------------------------------------------------------- 1 | # 1、一个糟糕的设计 2 | 3 | https://elasticsearch.cn/question/10827 4 | 5 | 场景是静态化查询字段+动态关系过滤的问题 6 | 7 | 由于es无法支持我的关系查询的需要，所以我需要将静态字段查询用es实现（因为字段非常的多，很多是来源于不同的表聚合出来的进=静态字段），动态关系查询用mysql实现，最后将es和mysql的结果集取交集，最后分页。 8 | 9 | 请问有没有什么比较好的实现方案？两个一起使用后运算感觉问题很大? 10 | 11 | 回复： 12 | 13 | 这就是糟糕的设计，以后肯定是灾难。 14 | 15 | # 2、EQL 不支持哪些操作 16 | 17 | PowerShell下如下的运行语句（出于隐私目的，没写出ip和端口）: 18 | curl.exe -X GET "x.x.x.x:x/_sql" -H 'Content-Type: application/json' -d"SELECT none_pay_course_list FROM user_portrayal where uc_id=4001464" ; 19 | 20 | 运行结果： 21 | {"took":33,"timed_out":false,"_shards":{"total":6,"successful":6,"skipped":0,"failed":0},"hits":{"total":{"value":1,"relation":"eq"},"max_score":0.0,"hits":[{"_index":"user_portrayal","_type":"_doc","_id":"4001464_1","_score":0.0,"_source":{"none_pay_course_list":[{"course":"11_30"},{"course":"11_37"},{"course":"11_23"},{"course":"11_38"}]}}]}} 22 | 23 | 提出问题： 24 | 如何改写运行语句，使得能够计算出none_pay_course_list的数组中元素个数。此处目测正确答案为4.（本人试过了split,count,size,length等各种各样的组合，但是还是未得到正确的答案，望得到解答，十分感谢） 25 | 26 | 直接看官方回复： 27 | 28 | https://www.elastic.co/guide/en/elasticsearch/reference/current/eql-syntax.html#eql-syntax-limitations 29 | 30 | # 3、ES udpate upsert性能如何优化？ 31 | 32 | https://elasticsearch.cn/question/10881 33 | 34 | ES版本5.6，数据量在3000万左右，数据更新频率比较频繁，总共的更新速度大概是1w/s-5w/s。 35 | 最新的数据先进kafka，再由flink消费写入ES。 36 | 37 | 目前发现在默认的ES配置下，bulk update或者upsert的速度始终上不去，所有节点的cpu使用率才25%左右，速度最高只能到1w/s左右。 38 | 39 | 如果改成这些数据全部是插入，不做更新操作，那么cpu可以跑满，而且kafka的消费绝对没有积压。 40 | 41 | 试过增加节点，效果很小，速度看起来有一点点的增加。试过增加分片数，有效果，但仍然不是很明显。 42 | 43 | 请问是什么原因导致这个现象呢，增加分片对写入速度有提升又是为什么呢？ 44 | 45 | 像这种场景，有没有办法直接的提升update/upsert速率，或者间接解决，比如全部用插入的方式写入，查询时同一个id的记录取时间最近的数据。那么查询方式还有删除旧数据这块怎么设计比较好 46 | 47 | 【精彩回复】 48 | 49 | - 1.update是先get再insert然后再delete（标记删除）旧的文档，和insert相比，肯定update耗时多 50 | 51 | - 2.由于一次操作完成时长多，线程池数量有限，导致cpu只有25%（猜测...） 52 | 53 | - 3.适当增加ES分片，对写入是有一点提高，因为相当于多出来了lucene进程，可以接收的请求多了，付出的代价就是分片多了之后同步数据是需要消耗性能的，然后查询更是会性能降低 54 | - 4.客户端使用层面：可以全部使用insert提高性能，然后定时去delete，定时（低峰期）合并segment，优化数据结构 55 | - 5.集群本身层面：可以控制refresh的频率，translog设置，副本可以先干掉（写完再补回来），线程池参数修改-------这些都是危险操作，评估后再进行实践 56 | 57 | 在上面基础上补充： 58 | - 1. 使用ES自动的id，不要指定id 59 | - 2. 提高操作系统 filesystem cache 60 | - 3. 关注下 index_buffer_size 这个参数 61 | 62 | # 4、排序优先级 63 | 64 | 如何查询置顶商品并排序？ 65 | 66 | 问题表述: 67 | - 搜索电商商品,后台运营将商品标志为是否置顶, 68 | - 如果这个商品被标志为置顶商品(is_ontop),在查询的时候, 69 | - 使其排在最前面.同时先按照销量排序, 70 | - 如何销量相同再按照商品上架时间来编写怎么编写dsl语句 71 | 72 | 【基础解决方案】 73 | ``` 74 | GET index/_search 75 | { 76 | "from": 0, 77 | "size": 10, 78 | "query": { 79 | "function_score": { 80 | "query": { 81 | "bool": { 82 | "should": [{ 83 | "constant_score": { 84 | "filter": { 85 | "match": { 86 | "sk": { 87 | "query": "耐克" 88 | } 89 | } 90 | } 91 | } 92 | }] 93 | } 94 | } 95 | } 96 | }, 97 | "sort": [{ 98 | "is_ontop": { 99 | "order": "desc" 100 | } 101 | }, { 102 | "saleCount": { 103 | "order": "desc" 104 | } 105 | }, 106 | { 107 | "saleTime": { 108 | "order": "desc" 109 | } 110 | } 111 | ] 112 | } 113 | ``` 114 | sort排序中，排在前面的优先级高，后面的优先级低，当前一个的值相同时，才会根据后一个排序。 115 | 116 | is_ontop 排第一位，优先排置顶的，当is_ontop 相同时，才会根据saleCount降序，以此类推。 117 | 118 | 【新功能解决方案】 119 | 120 | 新版本有一个类似置顶的查询，可以先将置顶的查出来完后用这个查询就会排在最前面。 121 | 122 | 使用：Pinned Query 123 | 124 | - Pinned： 就是固定的意思。 125 | - Pinned Query 精准含义： 126 | 127 | 提升所选文档的排名，使其高于与给定查询匹配的文档。 128 | 129 | 此功能通常用于引导搜索者查找精选的文档，这些文档在搜索的任何“有机”匹配项之上被提升。 使用存储在_id字段中的文档ID来标识升级或“固定”的文档。 130 | 131 | Demo 举例： 132 | 133 | ``` 134 | GET /_search 135 | { 136 | "query": { 137 | "pinned": { 138 | "ids": [ "1", "4", "100" ], 139 | "organic": { 140 | "match": { 141 | "description": "iphone" 142 | } 143 | } 144 | } 145 | } 146 | } 147 | ``` 148 | 149 | # 5、CCR(跨集群复制) 订阅集群会与 领导集群数据完全相同么？ 150 | 151 | 现公司想实现一个场景： 152 | 153 | A 生产集群，对外提供服务，时效是2个月，每天滚动删除60天前的数据 154 | 155 | B 备份集群，同步生产集群的数据，时效是6个月，每天滚动删除180天前的数据 156 | 157 | 使用CCR来从A同步到B可以么？ 158 | 159 | 或者说A被删除的数据会不会也同步在B删除呢？ 160 | 161 | 如果同步删除的话，还有没有快照之外的其他方式来实现前面的业务场景呢，请大神给个思路 162 | 163 | 【Medcl 回复】 164 | 165 | CCR 可以实现索引的同步，生命周期可以在两个集群分开管理。 166 | 167 | A 集群和 B 集群的索引处于同步状态的话是不能被删的。需要先解除同步关系。如果是日志场景，都是新增的数据，可以在 Rollover 之后使用 Unfollow 来自动解除同步关系。 168 | 169 | # 6、es怎么能通过一个同义词获得其他所有的同义词 170 | 171 | 我搜索时匹配到同义词的某个词，我想把它所有的同义词都找出来，用java api可以实现吗，现在能想到的就是去读txt文本，有更好的方法吗？ 172 | 173 | 【回复】 174 | 可以借助： analyzer API 实现。 175 | 176 | # 7、closed index 如何漂移 177 | 178 | 【问题】 179 | 180 | 现在有个 ES 集群, 有20台左右的物理机. 现在要将其中的3台物理机下线.但是其中有许多 closed indices. 181 | 182 | 如何只让要下线的3台物理机里的 indices(包括 closed indices) 漂移到其他机器上. 183 | 184 | 【核心实现】 185 | ``` 186 | PUT /_cluster/settings 187 | { 188 | "transient": { 189 | "cluster.routing.allocation.exclude._ip": "192.168.0.1,192.168.0.2,192.168.0.3" 190 | } 191 | } 192 | ``` 193 | 194 | 首先停止往要下掉的节点分配， 195 | 196 | 使用cluster.routing.allocation.exclude._ip或者cluster.routing.allocation.exclude._name 197 | 198 | 然后通过监控api确认分片都自动迁移到其它节点后，停掉旧节点服务。 199 | 200 | # 8、搜索字段长度大于2的数据 201 | 202 | 版本v7.9.2，字段是keyword类型，以下是文档中看到的方法，执行没有报错也没有数据返回，还有一些更老的写法我就不贴了 203 | 204 | ``` 205 | 如果你要进行筛选操作，你可以使用 filter 206 | DELETE test_index 207 | 208 | PUT test_index 209 | { 210 | "mappings": { 211 | "properties": { 212 | "name":{ 213 | "type": "keyword" 214 | } 215 | } 216 | } 217 | } 218 | 219 | POST test_index/_bulk 220 | {"index":{"_id":1}} 221 | {"name":"BKing"} 222 | {"index":{"_id":2}} 223 | {"name":"Tom"} 224 | {"index":{"_id":3}} 225 | {"name":"Steven"} 226 | {"index":{"_id":3}} 227 | {"name":"Kn"} 228 | {"index":{"_id":4}} 229 | {"name":"M"} 230 | {"index":{"_id":5}} 231 | {"name":"Jack Smith"} 232 | 233 | GET /test_index/_search 234 | 235 | POST test_index/_search 236 | { 237 | "query": { 238 | "bool": { 239 | "filter": [ 240 | { 241 | "script": { 242 | "script": { 243 | "lang": "painless", 244 | "source": "doc['name'].value.length() >= 2 && doc['name'].value.length() <= 5" 245 | } 246 | } 247 | } 248 | ] 249 | } 250 | } 251 | } 252 | 253 | ``` 254 | 255 | 256 | 257 | -------------------------------------------------------------------------------- /es_accumulate/202011_report.md: -------------------------------------------------------------------------------- 1 | # 1、写入elasticsearch慢解决方案 2 | 3 | https://elasticsearch.cn/question/10967 4 | 5 | rally,设置1个client（bulk 为3000）测试写入elasticsearch，速度为5000每秒（可能是数据比较大），查看服务器负载cpu ,IO并不高。 6 | 7 | rally,设置10个client（bulk 为3000）测试写入elasticsearch，速度为30000+每秒（可能是数据比较大），查看服务器负载cpu ,大约用了70%。 8 | 9 | 请问一下， 10 | 11 | 1、在设置1个client下，还能优化ES的写入速度么？为啥发挥不出来ES的性能呢？ 12 | 13 | 2、在设置10个client下，写入速度快了，服务器负载也提高了，说明了发挥了ES的性能，ES这个原理是什么？ 14 | 15 | 【回复】 16 | - client少的时候你可以适当的调大bulk的大小，多试几种bulk尺寸就能试出当前环境下最合适的bulk尺寸了。 17 | 18 | - 当加大了bulk尺寸就变相的减少了数据传输的次数，减少IO时间。 19 | 20 | - 还有性能也和你当前client的带宽有关的，如果10个client不在同一个服务器上可以考虑下这种情形。 21 | 22 | - bulk 就是一次批量数据问题 太大 太小都不合适需要根据每天数据大小，进行调整测试。 23 | 24 | - 有两种方法可以提供数据导入的速度： 25 | 1） 把 replicas 设置为0，这样避免在数据导入时复制数据。等数据导入完毕后，再修改 replicas 的数量为想要的数据 26 | 27 | 2）在默认的情况下 refresh_interval 为1s，如果你有大批量的数据，你可以把这个 refresh_interval 设置为 -1，等数据导入完毕后，再设置为默认值，或者自己想要的值， 28 | 29 | # 2、elasticsearch 官网下载中的oss 版本是什么意思？ 30 | 31 | 【medcl 回复】 32 | 33 | https://elasticsearch.cn/question/10979 34 | 35 | oss 就是不包括 xpack 的版本，你如果要带 xpack 的版本就下默认的版本就行了，并且也没有单独的 xpack 插件下载了哈，何必这样麻烦呢。 36 | 37 | # 3、【非常精彩】图解 Elasticsearch 搜索底层原理 38 | 39 | https://elasticsearch.cn/question/10976 40 | 41 | # 4、Result window is too large 问题 42 | 43 | 从上面的报错信息，可以看到ES提示我结果窗口太大了，并且在后面也提到了要求我修改index.max_result_window参数来增大结果窗口大小。除了这个方法还有啥好的方法呢 也不能总是改这个设置 44 | 45 | 【回复1】 46 | 47 | index.max_result_window 指定深度分页时最多查询多少条，默认是10000，你这设置的也太大了吧，不怕OOM吗 48 | 49 | 【回复2】 50 | 这个问题的解决源头在场景，想清楚你为啥需要这么深度的分页，是否有必要。如果是大量数据导出的场景用scroll 51 | 52 | # 5、关于Elasticsearch 读取数据的方式【精彩讨论】 53 | 54 | https://elasticsearch.cn/question/10989 55 | 56 | # 6、term _id 查询导致磁盘读非常高 57 | 58 | 根据_id查询没有用GET，而是通过term去查询，结果导致磁盘非常高 59 | 机器配置3台 16C/32G jvm16G 60 | 61 | 业务是按着月份分的索引，分别为index-2020.09， index-2020.10，index-2020.11 62 | 每个索引12个主分片 63 | 每个索引的大小都是100G，共300G 64 | 65 | ``` 66 | GET index-*/_search 67 | { 68 | "query": { 69 | "term": { 70 | "_id": { 71 | "value": "2ec1d06bc8734447a0c71bc09e2a1845_592" 72 | } 73 | } 74 | } 75 | } 76 | ``` 77 | _id是自动生成的id 78 | 79 | QPS非常低，只有2个左右，但是造成了磁盘的大量的读，读在150MB左右，磁盘负载很高 80 | 81 | 目前猜想，换成get会变好，想问下上面这个查询什么原理，造成这么大的读磁盘 82 | 83 | # 7、elasticsearch拆分索引【方案探讨】 84 | 85 | 请教各位大佬一个问题，我们公司将每个应用的日志都存在一个索引里面，其中包含Error、Info、Debug等日志，每天会产生一个索引。 86 | 87 | 由于现在应用接入的越来越多，每天的索引量越来越大，我们现在想将单索引根据日志级别拆分为多个索引。 88 | 89 | 例如 error_202011_25、info_202011_25.。请问一下各位大佬有没有什么好的思路和解决方案 90 | 91 | 【回复1】 92 | 93 | 解决方案： 94 | 对存量数据处理：按日志级别新建索引，例：error_20201126_log、info_20201126_log。reindex旧索引数据到新索引的时候对日志级别进行过滤 95 | 96 | 对增量数据处理：写入es层进行改造。对日志级别做判断，写入不同的索引。 97 | 98 | 建议：按日志区分索引不合理，error日志量对比info日志量应该占很小比例，按日志级别拆效果不好。多个应用日志最好写入不同的日志索引里。如果需要跨多个索引搜索根据语法选择多个索引即可。 99 | 100 | 更多精彩：https://elasticsearch.cn/question/11025 101 | 102 | # 8、logstash收取日志反向计算问题。 103 | 104 | logstash在收取日志中有个PRI部分（一个数值），这部分是由facility和severity两部分组成的。方法是facility*8+severity。现在，在日志中得到一个数值，怎么在logstash中把severity部分计算出来？ 105 | 106 | 比如：PRI=30=二进制0001 11100 其中serverity部分只最后三位 110=十进制6，我需要这个6。有什么方法可以把这个值在logstash中计算出来？ 107 | 108 | 109 | 处理方法： 110 | ``` 111 | ruby { 112 | 113 | code => " 114 | service = event.to_hash #把event对象转换为hash对象 115 | a = service['syslog-num'] #读取日志的PRI值syslog-num 116 | b = Integer(a) #把PRI值转换成整数 117 | x = b.to_s(2) #把PRI值转换为二进制 118 | y = x[-3..-1] #读取二进制的最后三位，得到severity 119 | z = '0b' + y #把二进制值转化为机器认识的二进制码 120 | q = Integer(z) #把二进制转换为十进制 121 | event.set('syslog-num',q) #把severity值写回syslog-num中 122 | " 123 | } 124 | ``` 125 | 谢谢楼上和一只菜鸟的知乎分享。 126 | 127 | # 9、es怎么获取最新数据？或者说取ID最大的一条数据怎么办？ 128 | 129 | 数据已经超过一万条了，想像mysql那样取最新的一条数据，怎么搞都不对，网上查也无结果，有大佬知道吗？谢谢了! 130 | 我的代码是这样的： 131 | ``` 132 | GET /game/_search 133 | { 134 | "track_total_hits": true, 135 | "query": {"range": {"gid": {"gte": 0 } } }, "size": 1 136 | } 137 | ``` 138 | 139 | 【回复】 140 | 141 | 通过pipeline在插数据的时候同时塞时间戳进去，取最新的一条就直接按时间戳倒排就好 142 | 143 | ES应该没法直接查最新的记录，你可以对时间戳字段排序，取第一个；防止性能问题，你的查询条件最好别是null，不过你这总共才1w条应该没什么问题 144 | 145 | 146 | # 10、master更新mapping线程block 147 | ``` 148 | elk日志集群，每天有预创建索引，因为是日志集群无法每个mapping都添加，但是索引太多涉及到更新mapping，引起线程blocked，想问下解决方案是否有调优方向，这个问题目前集群必现。 149 | es版本：7.6.2 150 | 151 | ``` 152 | 153 | 我们用的就是template，是预创建索引的，但是template开启的动态mapping，因为是日志集群，没有特别详细的问每一个业务日志都做成一个模板，都是公用一套模板，然后其它字段是动态生成的，最近一个月由于业务接入越来越多，这个问题现在每天定时更新索引或者mapping时已经必现，必须要同时重启master才能恢复，所以想问下老师是否遇到过或者有没有一些好的解决方案，还请老师指导一下。 154 | 155 | 【回复1】 156 | es默认开启动态字段的索引功能，但你们字段太多的情况下，再更新会导致集群master很卡。解决方法：禁止template的动态索引功能，这会导致新的字段不能被作为检索条件，如果动态索引是你们业务必须的话，那就要考虑拆分索引了，特殊的业务就不要和通用的业务糅杂在一起了，不要因为一些总是动态添加字段的业务日志影响所有的日志的可用性。 157 | 158 | 拆分日志，但是日志的名称都用统一的前缀 "log_index_"，你在检索时指定的索引名称 为 "log_index_*"，这样就能检索所有的日志索引了，和你用一个索引时一样的功能 159 | 160 | 【回复2】 161 | 用 _cluster/health 看下number_of_pending_tasks是多少，如果排队了很多，再用 162 | _cat/pending_tasks看看有哪些任务阻塞。 163 | 164 | 165 | 166 | 167 | -------------------------------------------------------------------------------- /es_accumulate/202012_report.md: -------------------------------------------------------------------------------- 1 | # 1、使用Elasticdump备份数据，发现备份的数据文档中_id错乱 2 | 3 | 使用Elasticdump备份集群A中的数据，备份命令如下： 4 | ``` 5 | ./elasticdump --input=http:// ip:port/my_index --output=/data/my_index_data.json --type=data 6 | ``` 7 | 备份完后查看json文件中的数据发现每个文档中的_id都变了，并不是原始文档中的_id值，但是_source里面的内容是正确的。 8 | 注：索引中的数据的_id都是通过代码设置，并非随机值； 9 | 10 | 【medcl 回复】 11 | 12 | elasticdump 不知道，esm 应该是没问题的。 13 | 14 | https://github.com/medcl/esm 15 | 16 | # 2、怎么修改Elasticsearch的生命周期策略 17 | 18 | 问一下各位大佬，我们现在有一个需求是可以动态修改索引的生命周期策略。比如说，有一个索引将于10天后会被删除。 19 | 20 | 我可以修改这个生命周期策略，将10天删除改为30天删除。我看Kibana上只能删除重新添加，没有修改的地方。请问一下各位大佬有好的想法和思路么 21 | 22 | 【回复】 23 | 24 | get _ilm/policy/xxx，修改策略后，再put就可以了。 25 | 26 | # 3、【探讨】是否有设置可以保证主分片和副本分片都平均分配？ 27 | 28 | 目前我设置total_shards_per_node保证分片均匀分配，但是这样只能保证每个节点上的分片数量相同，主副本分配还是随机的。 29 | 30 | 例如索引有12个分片，分配在3个节点。有的节点可能是3主1副分片，有的节点是1主3副分片。 31 | 32 | 这样在写入负载较高的索引上，实际运行时会导致比较明显的cpu资源不均衡，3主1副的节点cpu使用明显高于1主3副的。 33 | 34 | 即使我手动把分片调整为每个节点都是2主2副，也经常会因为自动均衡或者偶尔有主副分片切换，导致重新不均衡。 35 | 36 | 有没有什么分片分配的设置，能让ES自动保证主分片和副本分片都要保持平均呢？ 37 | 38 | 【回复讨论】 39 | 40 | 我这边有两个情况: 41 | 1.集群里其他按天建的索引，在创建和删除时，会导致各节点分片略有不均，触发自动均衡，这时那个负载比较高的索引中的分片有可能就会迁移，这个通过total_shards_per_node可以限制住。 42 | 43 | 2.这个负载高的索引，本身会因为写入负载比较高，导致有时主分片像是挂掉一样，触发主副本切换，导致原来已经手动调整好的状态又被打破，这时又需要再进行手动调整，我遇到的这种情况比较多，没办法自动调整成上面说的主、副本分别都平均的状态。 44 | 45 | # 4、是否可以在ES的search slow log中添加额外信息？ 46 | 47 | 版本：ES-5.2.2 48 | 49 | 在排查问题时，通过search slow log虽然能找到具体的查询，但是很难找到对应的具体业务点。 50 | 51 | 所以想能不能在search的时候，传给ES服务端一个类似业务上的traceId，然后在慢查询中记录这个traceId，有助于排查这个慢查询是从哪里来的。 52 | 53 | 【回复】 54 | 55 | 慢日志打印时会输出你的query信息，你在查询时添加一个不存在的field，放上你的traceId，在输出日志时不就能看到traceId信息了吗 56 | 57 | # 5、Elasticsearch主备集群如何实现数据的一致性 58 | 59 | 设计了Elasticsearch主备集群，数据会对两个集群进行双写，如何保证两个集群的数据一致性呢？是只要主集群写入成功就算成功，还是备集群数据写入成功才算成功呢？linux系统centos7.6，es7.6 60 | 61 | 【回复】 62 | 63 | 为啥要在应用层双写呢？直接用ES的工具CCR进行主备同步不好吗，不需要考虑一致性的问题，ES自身保证最终一致性。 64 | 65 | CCR的主备限制有点多，follow不能直接转leader，leader集群挂了之后操作的步骤比较多，而且等leader 集群重新起来后又会有问题...另一种双向的follow也有很多限制....貌似没有什么完美的解决方案～ 66 | 67 | 【回复2】 68 | 69 | 不用ccr的话，可以通过kafka双写，利用kafka的重试保证一致性 70 | 71 | # 6、请教各位大佬，怎么查看索引处于ILM索引生命周期中的那个阶段 72 | 73 | ``` 74 | GET index/_ilm/explain 75 | ``` 76 | 77 | # 7、es 跨集群增量同步数据 78 | 79 | es 7.10 ，快照可以完成两个集群数据的最终同步吗？本地集群和远程集群都会写入各自新的数据。不要求实时同步。 80 | 81 | 【回复】 82 | 83 | 快照的本质是备份数据 84 | 85 | 您的需求：应该类似双写或者同步，考虑下：elastic_dump reindex 或者logstash 同步 或者 medcl 大佬的开源的esm等 86 | 87 | es跨集群还有ccr功能 88 | 89 | # 8、【有趣讨论】ES堆内存分配越大，入库性能反而变小，有没有大佬知道为啥？ 90 | 91 | 物理内存：32G 92 | 硬盘：200G 93 | CPU：8核 94 | 95 | ES版本：6.8.13 96 | 97 | 单机版测试。 98 | 99 | 数据量：1200万条日志，共6.8G 100 | 101 | 使用esrally进行压测，bulk size 5000docs，5个client 102 | 103 | 分别给ES分配2G、4G、6G、8G、10G、12G、14G、16G堆内存，结果发现分配内存越大，入库吞吐量反而变小了 104 | 105 | 分配2G时性能最好 106 | 107 | 【回复】 108 | 109 | 单从heap的角度分析：heap并不是越大越好，越大GC时间越长，反而会影响到那段时间的吞吐量 110 | 111 | 可以参考下 https://www.elastic.co/cn/blog/a-heap-of-trouble 112 | 113 | 如果目的是增加ES吞吐量，有其他方式的，比如调整refresh、translog、副本、niofs等等，和heap相关行没有那么大，主要是依赖ES的性能与系统的优化逻辑 114 | 115 | # 9、为什么elasticsearch中副本碎片恢复的索引阶段如此缓慢？ 116 | 117 | 为什么elasticsearch中副本分片恢复的索引阶段如此缓慢？ 118 | 119 | 数据节点重启后，发现副本分片长时间处于初始化状态。 120 | 121 | 对于_cat/recovery接口，发现它们大多是副本分片，处于索引阶段。 122 | 123 | 副本分片恢复是向下恢复还是增量恢复？如何适应增量拉动 124 | 125 | ES的版本是7.7。 126 | 127 | 谢谢你的回答。 128 | 129 | 【回复】 130 | 131 | 如果数据量比较大，恢复慢是正常的吧。调大 132 | 133 | node_concurrent_recoveries 134 | 135 | 这个试试 136 | 137 | # 10、【升级问题】请教各位大佬，es如何从6.6.2平滑升级到6.8 138 | 139 | 请教一下各位大佬，本人小白菜一枚刚开始接触ES，如有冒犯请多包涵。公司准备将es从6.6.2升级到6.8。测试环境为单机环境，生产环境为集群模式。请问一下各位大佬有没有什么好的建议升级 测试环境和生产环境。生产环境前提是保证数据不丢失，不重启平滑升级。测试环境前提是保证数据不丢失，可重启。以下是我的见解。 140 | 单机环境：拍摄ES快照，保存当前数据。将实时数据存储于Redis中，重新安装es6.8将快照进行恢复，然后把Redis中的实时数据插入到新es中。 141 | 142 | 【回复】 143 | 144 | 建议你先多读几遍upgrade guie : https://www.elastic.co/guide/en/elastic-stack/6.8/upgrading-elastic-stack.html 145 | 另外测试环境应该也配置多节点，这样可以在测试环境上模拟生产环境升级的过程 146 | 147 | # 11、es向量余弦相似度计算可以设置阈值吗？比如相似度大于0.8的才返回。 148 | 149 | 文档太多，但是如果用size来限制返回数量又不合理，比如设置size=100，有可能里面只有前几个是有用的，其他都不相似，也有可能里面全是相似的，而且还漏了很多，所以觉得用size不合理。想通过相似度的阈值来筛选一下文档。 150 | 151 | 【回复】 152 | 153 | 可以获取第一个文档的相关性打分，然后将这个打分乘以0.8，使用min_socre指定为该值重新查询 154 | 155 | https://www.elastic.co/guide/en/elasticsearch/reference/7.2/search-request-min-score.html 156 | 157 | # 12、Elastic Search CCR增量同步 158 | 159 | 各位大佬，目前在调研使用CCR来实现异地复制。 160 | 161 | 从官方的介绍和使用中，已经了解到其follow索引的创建、自动跟随等高级特性。也了解到CCR的基础模型是由follow索引发起pull请求来进行数据同步。 162 | 163 | 想问下，CCR是如何触发增量同步的呢？follow索引的时效性是如何保证的？ 164 | 165 | 【回复】 166 | 167 | leader上会注册follow的Listener，当有集群状态变更或者数据修改时，会notify这个Listener， 168 | 169 | 具体的实现你可以看es的源码：org.elasticsearch.xpack.ccr.action.AutoFollowCoordinator，比如他的updateAutoFollowers 方法就是告诉follower集群状态变更了，同步增量数据过去。 170 | 171 | - 1 创建follow任务时，follower节点会先恢复远程索引的数据 172 | - 2 恢复完成后会创建一个定时任务 173 | - 3. 根据你的配置请求leader（有最大等待时间，有重试机制，具体看官方文档，一旦拿到新数据，会立刻进行下一次请求），获取上次的translog的seqNo到最新的（根据配置调整单次的获取量）的operations 174 | - 4. 持久化leader的operations到本地。 175 | - 5. 重复3-4 176 | 177 | https://elasticsearch.cn/question/11109 178 | 179 | # 13、Too Many Requests rest并发查询报错es_rejected_execution_exception 180 | 181 | 【回复】 182 | 183 | 慢查询过多，自然search线程池排队的任务过多。看你的查询语句，regexp和size过多的分桶聚合都是性能非常差的。想办法从业务场景上优化，尽量避免使用这类的查询。 184 | 185 | # 14、ES首次查询速度很慢 186 | 187 | es版本号6.8.1，一台物理机部署了五个节点，每个节点的jvm内存设置成了31G，物理机内存大小为512G，索引大小130G，12亿条数据，第一次查询时间几十秒，后面就是毫秒级了， 188 | 189 | 做了些预加载的设置（index.store.preload: ["nvd", "dvd", "tim", "doc", "dim"]），但好像不起作用，DSL语句：{ 190 | 191 | 192 | https://elasticsearch.cn/question/11132 193 | 194 | 【回复】 195 | 196 | 第一次要把那些用到的文件加载到文件缓存里，这样下次用到就能直接从缓存里读取了，ES的数据很大部分是不加载到JVM堆里的，所以第一次慢以后快是正常的 197 | 198 | 聚合数据的话, 可以用到分片缓存， 注意使用 199 | 200 | 官网URL+/guide/en/elasticsearch/reference/current/shard-request-cache.html 201 | 202 | 203 | 可以试试用execution_hint，把segment再merge一下 204 | 205 | # 15、求每天日志量的平均值， 206 | 207 | 实现参考： 208 | ``` 209 | POST /_search 210 | { 211 | "size": 0, 212 | "aggs": { 213 | "sales_per_month": { 214 | "date_histogram": { 215 | "field": "date", 216 | "calendar_interval": "month" 217 | }, 218 | "aggs": { 219 | "sales": { 220 | "sum": { 221 | "field": "price" 222 | } 223 | } 224 | } 225 | }, 226 | "avg_monthly_sales": { 227 | "avg_bucket": { 228 | "buckets_path": "sales_per_month>sales" 229 | } 230 | } 231 | } 232 | } 233 | ``` 234 | 235 | # 16、什么情况会集群uuid不一致导致加入集群一直失败 236 | 237 | https://elasticsearch.cn/question/11141 238 | 239 | 【回复】 240 | 241 | uuid是集群的唯一标识。节点之间 cluster state不一致就可能出现，比如把一个节点从A集群移动到B集群，或者不小心误删了一个节点的cluster state。 242 | 243 | 你这个问题可以考虑复位cluster uuid，看下elasticsearch-node detach-cluster命令 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | -------------------------------------------------------------------------------- /es_accumulate/jvm.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mingyitianxia/deep_elasticsearch/3ca24364e3f3a784b5ebe030bd3fb63cc83f0d2d/es_accumulate/jvm.png -------------------------------------------------------------------------------- /es_dsl_study/1.ingest_dsl.md: -------------------------------------------------------------------------------- 1 | # 1、rename 修改字段名称管道 2 | 3 | 将字段名称：hostname 改成了 host。 4 | 5 | ``` 6 | PUT _ingest/pipeline/rename_hostname 7 | { 8 | "processors": [ 9 | { 10 | "rename": { 11 | "field": "hostname", 12 | "target_field": "host", 13 | "ignore_missing": true 14 | } 15 | } 16 | ] 17 | } 18 | 19 | 20 | POST server/values/?pipeline=rename_hostname 21 | { 22 | "hostname": "myserver" 23 | } 24 | ``` 25 | 26 | # 2、append 添加管道 27 | 28 | 说明： 为字段tags 添加值。 29 | ``` 30 | PUT _ingest/pipeline/append_tags 31 | { 32 | "processors": [ 33 | { 34 | "append": { 35 | "field": "tags", 36 | "value": ["production", "phone", "USA"] 37 | } 38 | } 39 | ]} 40 | ``` 41 | 42 | # 3、Convert字段类型处理器 43 | 44 | 不在mapping层面修改，而是在字段数据层修改 45 | 46 | ``` 47 | PUT _ingest/pipeline/my-pipeline-id 48 | { 49 | "description": "converts the content of the id field to an integer", 50 | "processors" : [ 51 | { 52 | "convert" : { 53 | "field" : "id", 54 | "type": "integer" 55 | } 56 | } 57 | ] 58 | } 59 | ``` 60 | 61 | # 4、script 管道处理 62 | 63 | 来自球友提问：https://t.zsxq.com/NN3bmmy 64 | 65 | 目的：字符串类型的时间转成时间戳类型 66 | 67 | ``` 68 | PUT /_ingest/pipeline/seats 69 | { 70 | "description": "update datetime for seats", 71 | "processors": [ 72 | { 73 | "script": { 74 | "source": "String[] split(String s, char d) { int count = 0; for (char c : s.toCharArray()) { if (c == d) { ++count; } } if (count == 0) { return new String[] {s}; } String[] r = new String[count + 1]; int i0 = 0, i1 = 0; count = 0; for (char c : s.toCharArray()) { if (c == d) { r[count++] = s.substring(i0, i1); i0 = i1 + 1; } ++i1; } r[count] = s.substring(i0, i1); return r; } String[] dateSplit = split(ctx.date, (char)\"-\"); String year = dateSplit[0].trim(); String month = dateSplit[1].trim(); if (month.length() == 1) { month = \"0\" + month; } String day = dateSplit[2].trim(); if (day.length() == 1) { day = \"0\" + day; } boolean pm = ctx.time.substring(ctx.time.length() - 2).equals(\"PM\"); String[] timeSplit = split(ctx.time.substring(0, ctx.time.length() - 2), (char)\":\"); int hours = Integer.parseInt(timeSplit[0].trim()); int minutes = Integer.parseInt(timeSplit[1].trim()); if (pm) { hours += 12; } String dts = year + \"-\" + month + \"-\" + day + \"T\" + (hours < 10 ? \"0\" + hours : \"\" + hours) + \":\" + (minutes < 10 ? \"0\" + minutes : \"\" + minutes) + \":00+08:00\"; ZonedDateTime dt = ZonedDateTime.parse(dts, DateTimeFormatter.ISO_OFFSET_DATE_TIME); ctx.datetime = dt.getLong(ChronoField.INSTANT_SECONDS)*1000L;" 75 | } 76 | } 77 | ] 78 | } 79 | 80 | #A date in the format YYYY-MM-DD where the second digit of both month and day is optional. 81 | #A time in the format HH:MM* where the second digit of both hours and minutes is optional. The star (*) represents either the String AM or PM. 82 | 83 | DELETE test_index_10 84 | PUT test_index_10 85 | { 86 | "mappings": { 87 | "properties": { 88 | "date":{ 89 | "type":"text" 90 | }, 91 | "time":{ 92 | "type":"text" 93 | } 94 | } 95 | } 96 | } 97 | 98 | POST test_index_10/_doc/1 99 | { 100 | "date":"2020-3-10", 101 | "time":"2:35AM" 102 | } 103 | 104 | POST test_index_10/_update_by_query?pipeline=seats 105 | 106 | GET test_index_10/_search 107 | 108 | GET test_index_10/_mapping 109 | ``` 110 | 核验后发现，新增了long类型的datetime字段 111 | 112 | 113 | # 5、for each管道处理 114 | ``` 115 | PUT _ingest/pipeline/pipeline_trim 116 | { 117 | "processors": [ 118 | { 119 | "foreach": { 120 | "field": "text", 121 | "processor": { 122 | "trim": { 123 | "field": "_ingest._value" 124 | } 125 | } 126 | } 127 | } 128 | ] 129 | } 130 | ``` 131 | 132 | 133 | 134 | # 6 线上实战问题 1 135 | es可以根据_id字符串切分，再聚合统计吗 136 | 比如： 137 | 数据1、_id=C12345 138 | 数据2、_id=C12456 139 | 数据3、_id=C31268 140 | 141 | 通过es聚合统计 142 | C1开头的数量有2个 143 | C3开头的数据有1个 144 | 145 | 这个API怎么写，有大佬指导下吗？ 146 | 147 | ``` 148 | PUT _ingest/pipeline/split_id 149 | { 150 | "processors": [ 151 | { 152 | "script": { 153 | "lang": "painless", 154 | "source": "ctx.myid_prefix = ctx.myid.substring(0,2)" 155 | } 156 | } 157 | ] 158 | } 159 | 160 | DELETE my_index_0003 161 | PUT my_index_0003 162 | { 163 | "mappings": { 164 | "properties": { 165 | "my_id":{ 166 | "type": "keyword" 167 | }, 168 | "myid_prefix":{ 169 | "type":"keyword" 170 | } 171 | } 172 | } 173 | } 174 | 175 | 176 | PUT my_index_0003/_bulk 177 | {"index":{"_id":1}} 178 | {"myid":"c12345"} 179 | {"index":{"_id":2}} 180 | {"myid":"C12456"} 181 | {"index":{"_id":3}} 182 | {"myid":"C31268"} 183 | 184 | POST my_index_0003/_update_by_query?pipeline=split_id 185 | { 186 | "query":{ 187 | "match_all":{ 188 | 189 | } 190 | } 191 | } 192 | 193 | GET my_index_0003/_search 194 | ``` 195 | 196 | # 7、线上实战问题 2 197 | 插入的时候，能不能对原数据进行一定的转化，再进行indexing 198 | ``` 199 | { 200 | "headers":{ 201 | "userInfo":[ 202 | "{ \"password\": \"test\",\n \"username\": \"zy\"}" 203 | ] 204 | } 205 | } 206 | ``` 207 | 这里面的已经时字符串了，能在数据插入阶段把这个json转成object么？ 208 | @BlandyKevin https://www.elastic.co/guide/en/elasticsearch/reference/master/json-processor.html 209 | 210 | 实战DSL 回答： 211 | ``` 212 | ELETE my_index_0004 213 | PUT my_index_0004/_doc/1 214 | { 215 | "headers":{ 216 | "userInfo":[ 217 | "{\"password\": \"test\", \"username\": \"zy\"}" 218 | ] 219 | } 220 | } 221 | 222 | PUT _ingest/pipeline/json_builder 223 | { 224 | "processors": [ 225 | { 226 | "json": { 227 | "field": "headers.userInfo", 228 | "target_field": "headers.userInfo.target" 229 | } 230 | } 231 | ] 232 | } 233 | 234 | 235 | POST my_index_0004/_update_by_query?pipeline=json_builder 236 | { 237 | "query": { 238 | "match_all": {} 239 | } 240 | } 241 | ``` 242 | 243 | # 8、 线上实战问题 3 244 | 各位 有没有试过用foreach和script结合使用？比如：我想对一个list每个值后面都加一个字符 245 | 比如 {"tag":["a","b","c"]}这样一个文档 我想变成 {"tag":["a2","b2","c2"]}这样的 246 | 247 | 实战回答： 248 | ``` 249 | PUT my_index_0005/_doc/1 250 | { 251 | "tag": ["a","b","c"] 252 | } 253 | 254 | PUT _ingest/pipeline/add_builder 255 | { 256 | "processors": [ 257 | { 258 | "script": { 259 | "lang": "painless", 260 | "source": """ 261 | for (int i=0; i < ctx.tag.length;i++) { 262 | ctx.tag[i]=ctx.tag[i]+"2"; 263 | } 264 | """ 265 | } 266 | } 267 | ] 268 | } 269 | 270 | POST my_index_0005/_update_by_query?pipeline=add_builder 271 | { 272 | "query": { 273 | "match_all": {} 274 | } 275 | } 276 | 277 | GET my_index_0005/_search 278 | ``` 279 | 280 | # 9、 线上实战问题（20210208 更新） 281 | 问题来源：死磕 Elasticsearch 星球微信群 282 | 283 | 问题描述： 284 | 285 | 想请教一下，pipeline里面的split分成了四个，怎么通过set同时赋给四个新的字段？我查了一下例子都是拆分后通过set取其中的一个值。 286 | 287 | 我目的是split拆分后，把array里面的每个值单独拿出来通过set赋予新字段。 288 | 289 | ``` 290 | PUT source_index/_doc/1 291 | { 292 | "tags":"pingpang,basketball,football", 293 | "first_name":"zhao", 294 | "last_name":"zi long", 295 | "three_name":"1111", 296 | "four_name":"2222" 297 | } 298 | 299 | PUT _ingest/pipeline/my_pipeline 300 | { 301 | "description": "just for testing", 302 | "processors": [ 303 | { 304 | "split": { 305 | "field": "tags", 306 | "separator": "," 307 | } 308 | }, 309 | { 310 | "script": { 311 | "lang": "painless", 312 | "source": "ctx.field_a = ctx.tags[0]; ctx.field_b=ctx.tags[1]; ctx.field_c=ctx.tags[2]" 313 | } 314 | } 315 | ] 316 | } 317 | 318 | POST source_index/_update_by_query?pipeline=my_pipeline 319 | { 320 | "query":{ 321 | "match_all":{} 322 | } 323 | } 324 | 325 | GET source_index/_search 326 | ``` 327 | -------------------------------------------------------------------------------- /es_dsl_study/10.split.md: -------------------------------------------------------------------------------- 1 | # 索引split本质 2 | 3 | 在ES6.1版本之后，支持了索引shard的切分，与其说是支持了切分， 4 | 5 | 不如说是提供了一个接口，将原有的数据可以快速复制到新的索引下，并保持数据结构的不变，仅仅是增加了索引分片。 6 | 7 | 8 | ``` 9 | PUT /test_split_index 10 | { 11 | "settings": { 12 | "index.number_of_shards" : 2, 13 | "index.number_of_routing_shards" : 10, 14 | "index.number_of_replicas": 0 15 | } 16 | } 17 | 18 | POST /test_split_index/_bulk?pretty 19 | { "index": {}} 20 | { "user":"zhangsan", "age":"12"} 21 | { "index": {}} 22 | { "user":"lisi", "age":"25"} 23 | { "index": {}} 24 | { "user":"wangwu", "age":"21"} 25 | { "index": {}} 26 | { "user":"zhaoliu", "age":"16"} 27 | { "index": {}} 28 | { "user":"sunjiu", "age":"40"} 29 | 30 | POST /test_split_index/_close 31 | 32 | ### 防止在切分过程中有数据写入 33 | PUT /test_split_index/_settings?pretty 34 | { 35 | "settings": { 36 | "index.blocks.write": true 37 | } 38 | } 39 | 40 | POST /test_split_index/_open 41 | POST /test_split_index/_split/split_index_target?pretty 42 | { 43 | "settings": { 44 | "index.number_of_shards": 10 45 | } 46 | } 47 | 48 | GET test_split_index 49 | 50 | GET split_index_target 51 | ``` 52 | 53 | https://www.cnblogs.com/woniu4/p/8466069.html 54 | 55 | -------------------------------------------------------------------------------- /es_dsl_study/11.aggs_by_composite buckets.md: -------------------------------------------------------------------------------- 1 | # 多字段组合聚合样例 2 | ``` 3 | DELETE composite_test 4 | PUT composite_test 5 | { 6 | "mappings": { 7 | "properties": { 8 | "area":{"type":"keyword"}, 9 | "userid":{"type":"keyword"}, 10 | "sendtime":{"type":"date"} 11 | } 12 | } 13 | } 14 | 15 | POST composite_test/_bulk 16 | { "index":{"_id":1}} 17 | {"area":"33","userid":"400015","sendtime":"2019-01-17T00:00:00"} 18 | { "index":{"_id":2}} 19 | {"area":"33","userid":"400015","sendtime":"2019-01-17T00:00:00"} 20 | { "index":{"_id":3}} 21 | {"area":"35","userid":"400016","sendtime":"2019-01-18T00:00:00"} 22 | { "index":{"_id":4}} 23 | {"area":"35","userid":"400016","sendtime":"2019-01-18T00:00:00"} 24 | { "index":{"_id":5}} 25 | {"area":"33","userid":"400017","sendtime":"2019-01-17T00:00:00"} 26 | 27 | GET composite_test/_search 28 | { 29 | "size": 0, 30 | "aggs": { 31 | "my_buckets": { 32 | "composite": { 33 | "sources": [ 34 | { 35 | "area_aggs": { 36 | "terms": { 37 | "field": "area" 38 | } 39 | } 40 | }, 41 | { 42 | "userid_aggs": { 43 | "terms": { 44 | "field": "userid" 45 | } 46 | } 47 | }, 48 | { 49 | "sendtime_data_his_aggs": { 50 | "date_histogram": { 51 | "field": "sendtime", 52 | "interval": "1d", 53 | "format": "yyyy-MM-dd" 54 | } 55 | } 56 | } 57 | ] 58 | } 59 | } 60 | } 61 | } 62 | ``` 63 | -------------------------------------------------------------------------------- /es_dsl_study/12.terms_lookup.md: -------------------------------------------------------------------------------- 1 | # terms look up 本质上可以当做关联查询 2 | 3 | # Terms lookup mechanism 4 | 5 | ## Adding test data 6 | 7 | ``` 8 | PUT /users/_doc/1 9 | { 10 | "name": "John Roberts", 11 | "following" : [2, 3] 12 | } 13 | ``` 14 | 15 | ``` 16 | PUT /users/_doc/2 17 | { 18 | "name": "Elizabeth Ross", 19 | "following" : [] 20 | } 21 | ``` 22 | 23 | ``` 24 | PUT /users/_doc/3 25 | { 26 | "name": "Jeremy Brooks", 27 | "following" : [1, 2] 28 | } 29 | ``` 30 | 31 | ``` 32 | PUT /users/_doc/4 33 | { 34 | "name": "Diana Moore", 35 | "following" : [3, 1] 36 | } 37 | ``` 38 | 39 | ``` 40 | PUT /stories/_doc/1 41 | { 42 | "user": 3, 43 | "content": "Wow look, a penguin!" 44 | } 45 | ``` 46 | 47 | ``` 48 | PUT /stories/_doc/2 49 | { 50 | "user": 1, 51 | "content": "Just another day at the office... #coffee" 52 | } 53 | ``` 54 | 55 | ``` 56 | PUT /stories/_doc/3 57 | { 58 | "user": 1, 59 | "content": "Making search great again! #elasticsearch #elk" 60 | } 61 | ``` 62 | 63 | ``` 64 | PUT /stories/_doc/4 65 | { 66 | "user": 4, 67 | "content": "Had a blast today! #rollercoaster #amusementpark" 68 | } 69 | ``` 70 | 71 | ``` 72 | PUT /stories/_doc/5 73 | { 74 | "user": 4, 75 | "content": "Yay, I just got hired as an Elasticsearch consultant - so excited!" 76 | } 77 | ``` 78 | 79 | ``` 80 | PUT /stories/_doc/6 81 | { 82 | "user": 2, 83 | "content": "Chilling at the beach @ Greece #vacation #goodtimes" 84 | } 85 | ``` 86 | 87 | ## Querying stories from a user's followers 88 | 89 | ``` 90 | GET /stories/_search 91 | { 92 | "query": { 93 | "terms": { 94 | "user": { 95 | "index": "users", 96 | "id": 1, 97 | "path": "following" 98 | } 99 | } 100 | } 101 | } 102 | ``` 103 | 104 | 最后查询解读： 105 | 106 | 查询了stories 索引中，满足：user （取值注意：从users索引中的， id=1 ，following 字段取值）的结果值。 107 | -------------------------------------------------------------------------------- /es_dsl_study/13.update.md: -------------------------------------------------------------------------------- 1 | ``` 2 | # update 3 | POST twitter/_doc/1 4 | { 5 | "user":"kimchy" 6 | } 7 | 8 | 9 | POST twitter/_update_by_query?conflicts=proceed 10 | { 11 | "query": { 12 | "term": { 13 | "user": "kimchy" 14 | } 15 | } 16 | } 17 | 18 | #新增字段 19 | POST twitter/_update_by_query 20 | { 21 | "script": { 22 | "source": "if (ctx._source.likes != null) {ctx._source.likes++;} else {ctx._source.likes = 0;}", 23 | "lang": "painless" 24 | }, 25 | "query": { 26 | "match_all":{} 27 | } 28 | } 29 | 30 | GET twitter/_search 31 | 32 | # 以下两种方式等价 33 | POST twitter/_update_by_query 34 | { 35 | "script": { 36 | "source": "ctx._source.user = 'mingyi'", 37 | "lang": "painless" 38 | }, 39 | "query": { 40 | "term": { 41 | "user": "kimchy" 42 | } 43 | } 44 | } 45 | 46 | POST twitter/_update_by_query 47 | { 48 | "script": { 49 | "source": "ctx._source['user'] = 'mingyitianxia'", 50 | "lang": "painless" 51 | }, 52 | "query": { 53 | "term": { 54 | "user": "mingyi" 55 | } 56 | } 57 | } 58 | 59 | ``` 60 | -------------------------------------------------------------------------------- /es_dsl_study/14.join.md: -------------------------------------------------------------------------------- 1 | DELETE my_index 2 | # 定义父子文档 3 | ``` 4 | PUT my_index 5 | { 6 | "mappings": { 7 | "properties": { 8 | "my_join_field": { 9 | "type": "join", 10 | "relations": { 11 | "question": "answer" 12 | } 13 | } 14 | } 15 | } 16 | } 17 | ``` 18 | 19 | # 插入数据 20 | ``` 21 | PUT my_index/_doc/1?refresh 22 | { 23 | "text": "This is a question", 24 | "my_join_field": { 25 | "name": "question" 26 | } 27 | } 28 | 29 | PUT my_index/_doc/2?refresh 30 | { 31 | "text": "This is another question", 32 | "my_join_field": { 33 | "name": "question" 34 | } 35 | } 36 | 37 | PUT my_index/_doc/3?routing=1&refresh 38 | { 39 | "text": "This is an answer", 40 | "my_join_field": { 41 | "name": "answer", 42 | "parent": "1" 43 | } 44 | } 45 | 46 | PUT my_index/_doc/4?routing=1&refresh 47 | { 48 | "text": "This is another answer", 49 | "my_join_field": { 50 | "name": "answer", 51 | "parent": "1" 52 | } 53 | } 54 | 55 | GET my_index/_search 56 | { 57 | "query": { 58 | "match_all": {} 59 | }, 60 | "sort": ["_id"] 61 | } 62 | 63 | GET my_index/_search 64 | ``` 65 | # parent_id的含义：返回 parent_id=给定id的：父文档对应的子文档 66 | ``` 67 | GET my_index/_search 68 | { 69 | "query": { 70 | "parent_id": { 71 | "type": "answer", 72 | "id": "1" 73 | } 74 | } 75 | } 76 | ``` 77 | 78 | # 根据父文档条件查询子文档信息 79 | ``` 80 | GET my_index/_search 81 | { 82 | "query": { 83 | "has_parent": { 84 | "parent_type": "question", 85 | "query": { 86 | "match": { 87 | "text": "question" 88 | } 89 | } 90 | } 91 | } 92 | } 93 | ``` 94 | 95 | # 根据子文档查询父文档信息 96 | ``` 97 | GET my_index/_search 98 | { 99 | "query": { 100 | "has_child": { 101 | "type": "answer", 102 | "query": { 103 | "match_all": {} 104 | }, 105 | "max_children": 10, 106 | "min_children": 1, 107 | "score_mode": "min" 108 | } 109 | } 110 | } 111 | ``` 112 | 113 | # 查询子文档对应的父文档，同时借助：inner_hits将该父文档对应的全部子文档一并返回 114 | ``` 115 | POST my_index/_search 116 | { 117 | "query": { 118 | "has_child": { 119 | "type": "answer", 120 | "query": { 121 | "match": { 122 | "text": "answer" 123 | } 124 | }, 125 | "inner_hits": {} 126 | } 127 | } 128 | } 129 | ``` 130 | 131 | -------------------------------------------------------------------------------- /es_dsl_study/15.multi-match.md: -------------------------------------------------------------------------------- 1 | # 1、默认 best_fields 与 dis_max等价 2 | ``` 3 | POST blogs/_search 4 | { 5 | "query": { 6 | "multi_match": { 7 | "type": "best_fields", 8 | "query": "Quick pets", 9 | "fields": [ 10 | "title", 11 | "body" 12 | ], 13 | "tie_breaker": 0.2 14 | } 15 | } 16 | } 17 | ``` 18 | # 与上述best_fields等价 19 | ``` 20 | POST blogs/_search 21 | { 22 | "query": { 23 | "dis_max": { 24 | "queries": [ 25 | { 26 | "match": { 27 | "title": "Quick pets" 28 | } 29 | }, 30 | { 31 | "match": { 32 | "body": "Quick pets" 33 | } 34 | } 35 | ], 36 | "tie_breaker": 0.2 37 | } 38 | } 39 | } 40 | ``` 41 | 42 | # most_fields 43 | ``` 44 | DELETE /titles 45 | PUT /titles 46 | { 47 | "mappings": { 48 | "properties": { 49 | "title": { 50 | "type": "text", 51 | "analyzer": "english", 52 | "fields": { 53 | "std": { 54 | "type": "text", 55 | "analyzer": "standard" 56 | } 57 | } 58 | } 59 | } 60 | } 61 | } 62 | 63 | POST titles/_bulk 64 | { "index": { "_id": 1 }} 65 | { "title": "My dog barks" } 66 | { "index": { "_id": 2 }} 67 | { "title": "I see a lot of barking dogs on the road " } 68 | ``` 69 | 70 | # 2、most_fields 与下面的bool等价 71 | ``` 72 | GET /titles/_search 73 | { 74 | "query": { 75 | "multi_match": { 76 | "query": "barking dogs", 77 | "type": "most_fields", 78 | "fields": [ 79 | "title^10", 80 | "title.std" 81 | ] 82 | } 83 | } 84 | } 85 | ``` 86 | # 与上面的most_fields等价 87 | ``` 88 | GET titles/_search 89 | { 90 | "query": { 91 | "bool": { 92 | "should": [ 93 | { 94 | "match": { 95 | "title": { 96 | "query": "barking dogs", 97 | "boost": 10 98 | } 99 | } 100 | }, 101 | { 102 | "match": { 103 | "title.std": "barking dogs" 104 | } 105 | } 106 | ] 107 | } 108 | } 109 | } 110 | ``` 111 | 112 | https://www.elastic.co/guide/en/elasticsearch/reference/7.2/mapping-boost.html 113 | 114 | 115 | # cross_fields 116 | ``` 117 | PUT test003/_bulk 118 | {"index":{"_id":1}} 119 | {"first_name":"Will","last_name":"Smith"} 120 | {"index":{"_id":2}} 121 | {"first_name":"Smith","last_name":"Jones"} 122 | {"index":{"_id":3}} 123 | {"first_name":"Smith","last_name":"Will"} 124 | ``` 125 | # 3、与下面的bool查询逻辑一致 126 | ``` 127 | GET test003/_validate/query?explain=true 128 | { 129 | "query": { 130 | "multi_match" : { 131 | "query": "Will Smith", 132 | "type": "cross_fields", 133 | "fields": [ "first_name", "last_name" ], 134 | "operator": "and" 135 | } 136 | } 137 | } 138 | ``` 139 | 140 | GET test003/_validate/query?explain=true 141 | 返回： "explanation" : "+blended(terms:[first_name:will, last_name:will]) +blended(terms:[first_name:smith, last_name:smith])" 142 | 143 | # 与上面的cross_fields 基本等价，评分不一致，待深究 144 | ``` 145 | POST test003/_validate/query?explain=true 146 | { 147 | "query": { 148 | "bool": { 149 | "must": [ 150 | { 151 | "dis_max": { 152 | "queries": [ 153 | { 154 | "match": { 155 | "first_name": "Will" 156 | } 157 | }, 158 | { 159 | "match": { 160 | "last_name": "Will" 161 | } 162 | } 163 | ] 164 | } 165 | }, 166 | { 167 | "dis_max": { 168 | "queries": [ 169 | { 170 | "match": { 171 | "first_name": "Smith" 172 | } 173 | }, 174 | { 175 | "match": { 176 | "last_name": "Smith" 177 | } 178 | } 179 | ] 180 | } 181 | } 182 | ] 183 | } 184 | } 185 | } 186 | ``` 187 | POST test003/_validate/query?explain=true 188 | "explanation" : "+(first_name:will | last_name:will) +(first_name:smith | last_name:smith)" 189 | 190 | ``` 191 | ## 相关阅读 192 | - https://www.elastic.co/guide/en/elasticsearch/reference/7.1/query-dsl-dis-max-query.html 193 | -------------------------------------------------------------------------------- /es_dsl_study/16.aggs.md: -------------------------------------------------------------------------------- 1 | # 1、聚合某个字段，后获取其发帖天数最多的前两个 2 | 3 | 软件版本；elasticsearch 5.6.4 4 | 5 | 问题：例如：name字段有 （张三、李四、王五） 三种值，pubtime字段是发帖时间（YYYY-MM-dd），现在要查询发帖天数最多的两个人，该如何写语句？ 6 | 7 | 【回复】 8 | 9 | ``` 10 | PUT my_index_009 11 | { 12 | "mappings": { 13 | "properties": { 14 | "name": { 15 | "type": "text", 16 | "fields": { 17 | "keyword": { 18 | "type": "keyword" 19 | } 20 | } 21 | }, 22 | "publish_time": { 23 | "type": "date" 24 | } 25 | } 26 | } 27 | } 28 | 29 | POST my_index09/_bulk 30 | {"index":{"_id":1}} 31 | {"name":"张三","publish_time":"2020-05-01" } 32 | {"index":{"_id":2}} 33 | {"name":"李四","publish_time":"2020-05-02" } 34 | {"index":{"_id":3}} 35 | {"name":"王五","publish_time":"2020-05-03" } 36 | {"index":{"_id":4}} 37 | {"name":"张三","publish_time":"2015-05-02" } 38 | {"index":{"_id":5}} 39 | {"name":"张三","publish_time":"2015-05-03" } 40 | {"index":{"_id":6}} 41 | {"name":"李四","publish_time":"2015-05-04" } 42 | {"index":{"_id":7}} 43 | {"name":"王五","publish_time":"2015-05-05" } 44 | {"index":{"_id":8}} 45 | {"name":"张三","publish_time":"2015-05-04" } 46 | 47 | POST my_index09/_search 48 | { 49 | "size": 0, 50 | "aggs": { 51 | "name_aggs": { 52 | "terms": { 53 | "field": "name.keyword", 54 | "shard_size":10, 55 | "size": 2 56 | }, 57 | "aggs": { 58 | "date_aggs": { 59 | "value_count": { 60 | "field": "publish_time" 61 | } 62 | } 63 | } 64 | } 65 | } 66 | } 67 | ``` 68 | -------------------------------------------------------------------------------- /es_dsl_study/2.aggs_having.md: -------------------------------------------------------------------------------- 1 | https://elasticsearch.cn/question/7948#!answer_12068 2 | 3 | # 背景： 4 | 某公司在网上做一项调查，对公司员工的基本信息进行收集。目前得到一批数据进行分析。 5 | 现在有以下问题需要进行分析 6 | 数据： 7 | 8 | 100w家，每个公司有N个部门，每个部门有N个员工 9 | 10 | 11 | # 要求： 12 | 查询满足【同一家公司内同一部门里，年龄在25-30岁之间的男性员工超过10人】的公司有哪些？ 13 | 数据结构该如何设计？如图想了两种数据结构，不知道那种合适。 14 | Elasticsearch能否像SQL的having count>N的这种方式作为query的条件筛选么？ 15 | 16 | ES版本5.4.3 17 | 18 | # 备注：以上场景根据实际业务进行改编，数据量要比以上说明要多很多 19 | 20 | 以下建模使用了非nested存储，铺平存储。 21 | 22 | ``` 23 | DELETE company_infos 24 | PUT company_infos 25 | { 26 | "mappings": { 27 | "_doc": { 28 | "properties": { 29 | "no": { 30 | "type": "long" 31 | }, 32 | "name": { 33 | "type": "text", 34 | "fields": { 35 | "keyword": { 36 | "type": "keyword" 37 | } 38 | } 39 | }, 40 | "sex": { 41 | "type": "keyword" 42 | }, 43 | "age": { 44 | "type": "integer" 45 | }, 46 | "company_name": { 47 | "type": "text", 48 | "fields": { 49 | "keyword": { 50 | "type": "keyword" 51 | } 52 | } 53 | }, 54 | "department": { 55 | "type": "text", 56 | "fields": { 57 | "keyword": { 58 | "type": "keyword" 59 | } 60 | } 61 | } 62 | } 63 | } 64 | } 65 | } 66 | 67 | POST /_bulk 68 | { "index" : { "_index" : "company_infos", "_type" : "_doc", "_id" : "1" } } 69 | { "no" : 1, "name":"zhangsan", "age":25, "company_name":"xiaomi", "department":"waa","sex":"man"} 70 | { "index" : { "_index" : "company_infos", "_type" : "_doc", "_id" : "2" } } 71 | { "no" : 2, "name":"lisi", "age":30, "company_name":"xiaomi", "department":"waa","sex":"man"} 72 | { "index" : { "_index" : "company_infos", "_type" : "_doc", "_id" : "3" } } 73 | { "no" : 3, "name":"wangwu", "age":27, "company_name":"huawei", "department":"haa","sex":"man"} 74 | { "index" : { "_index" : "company_infos", "_type" : "_doc", "_id" : "4" } } 75 | { "no" : 4, "name":"zhaoliu", "age":29, "company_name":"huawei", "department":"haa","sex":"man"} 76 | { "index" : { "_index" : "company_infos", "_type" : "_doc", "_id" : "5" } } 77 | { "no" : 5, "name":"fengqi", "age":35, "company_name":"huawei", "department":"haa","sex":"man"} 78 | { "index" : { "_index" : "company_infos", "_type" : "_doc", "_id" : "6" } } 79 | { "no" : 6, "name":"laoliu", "age":28, "company_name":"huawei", "department":"haa","sex":"man"} 80 | 81 | 82 | 83 | POST company_infos/_search 84 | { 85 | "size": 0, 86 | "aggs": { 87 | "company_names_aggs": { 88 | "terms": { 89 | "field": "company_name.keyword", 90 | "size": 10 91 | }, 92 | "aggs": { 93 | "department_aggs": { 94 | "terms": { 95 | "field": "department.keyword" 96 | }, 97 | "aggs": { 98 | "sex_aggs": { 99 | "terms": { 100 | "field": "sex", 101 | "size": 10 102 | }, 103 | "aggs": { 104 | "employee_count": { 105 | "range": { 106 | "field": "age", 107 | "ranges": [ 108 | { 109 | "from": 25, 110 | "to": 31 111 | } 112 | ] 113 | }, 114 | "aggs": { 115 | "my_filter": { 116 | "bucket_selector": { 117 | "buckets_path": { 118 | "the_doc_count": "_count" 119 | }, 120 | "script": "params.the_doc_count > 1" 121 | } 122 | } 123 | } 124 | } 125 | } 126 | } 127 | } 128 | } 129 | } 130 | } 131 | } 132 | } 133 | ``` 134 | -------------------------------------------------------------------------------- /es_dsl_study/3.aggs_pipeline_bucketscript.md: -------------------------------------------------------------------------------- 1 | # 需求描述： 2 | 我要实现的需求相当于求一个学校里某个年级某个班级的学生总分，占整个整个年级总分的多少。 3 | 4 | # 需求地址 5 | https://wx.zsxq.com/dweb/#/index/225224548581 6 | 7 | # 聚合他山之石——方法论（魏彬原创） 8 | https://elasticsearch.cn/article/629 9 | 10 | # 某个年级某个班级的学生总分，占整个整个年级总分的多少 DSL实战实现 11 | ``` 12 | DELETE school_grade_class_student 13 | PUT school_grade_class_student 14 | { 15 | "settings": { 16 | "number_of_replicas": 0, 17 | "number_of_shards": 1 18 | }, 19 | "mappings": { 20 | "doc": { 21 | "properties": { 22 | "grade": { 23 | "type": "text", 24 | "fields": { 25 | "keyword": { 26 | "type": "keyword" 27 | } 28 | } 29 | }, 30 | "class": { 31 | "type": "text", 32 | "fields": { 33 | "keyword": { 34 | "type": "keyword" 35 | } 36 | } 37 | }, 38 | "student_name": { 39 | "type": "text", 40 | "fields": { 41 | "keyword": { 42 | "type": "keyword" 43 | } 44 | } 45 | }, 46 | "student_score": { 47 | "type": "float" 48 | } 49 | } 50 | } 51 | } 52 | } 53 | 54 | POST school_grade_class_student/_bulk 55 | {"index":{"_type":"doc","_id":1}} 56 | {"grade":"一年级","class":"一班","student":"zhangsan11","student_score":35} 57 | {"index":{"_type":"doc","_id":2}} 58 | {"grade":"二年级","class":"一班","student":"bb","student_score":55} 59 | {"index":{"_type":"doc","_id":3}} 60 | {"grade":"一年级","class":"二班","student":"cc","student_score":25} 61 | {"index":{"_type":"doc","_id":4}} 62 | {"grade":"一年级","class":"一班","student":"dd","student_score":75} 63 | {"index":{"_type":"doc","_id":5}} 64 | {"grade":"二年级","class":"一班","student":"ee","student_score":85} 65 | {"index":{"_type":"doc","_id":6}} 66 | {"grade":"一年级","class":"二班","student":"ff","student_score":95} 67 | 68 | 69 | #一班占据年级的总比例 70 | #一年级一班：35+75=110，一年级总分：35+25+75+95=230，比例=110/230=47.82 71 | #一年级二班 100% 72 | POST school_grade_class_student/_search 73 | { 74 | "size": 0, 75 | "aggs": { 76 | "grade_aggs": { 77 | "terms": { 78 | "field": "grade.keyword", 79 | "size": 10 80 | }, 81 | "aggs": { 82 | "class_aggs_filter": { 83 | "filter": { 84 | "terms": { 85 | "class.keyword": ["一班"] 86 | } 87 | }, 88 | "aggs": { 89 | "sum_aggs_by_class": { 90 | "sum": { 91 | "field": "student_score" 92 | } 93 | } 94 | } 95 | }, 96 | "sum_aggs_by_grade": { 97 | "sum": { 98 | "field": "student_score" 99 | } 100 | }, 101 | "classofgrade-percentage": { 102 | "bucket_script": { 103 | "buckets_path": { 104 | "classscore": "class_aggs_filter > sum_aggs_by_class", 105 | "gradescore": "sum_aggs_by_grade" 106 | }, 107 | "script": "params.classscore / params.gradescore * 100" 108 | } 109 | } 110 | } 111 | }, 112 | "sum_aggs_by_school": { 113 | "sum": { 114 | "field": "student_score" 115 | } 116 | } 117 | } 118 | } 119 | ``` 120 | -------------------------------------------------------------------------------- /es_dsl_study/4.script_field.md: -------------------------------------------------------------------------------- 1 | # 问题：能否在一个查询中 查询两个条件 在对两个结果进行除法计算 2 | 3 | 请教各位一个问题，我们有一个场景，想通过1个查询语句，计算两个查询结果的除法，比如，我有一个查询条件，用 idc: "BJ" 能统计出有100条数据符合要求 ，第二个条件 idc: "SH"，能统计出有200个数据，我现在想要取到 100 / 200 这个值 50% 这个数据，请问能有办法实现吗？请各位大神指点一下。 4 | 5 | # 参考 es6.6版本 6 | 7 | ``` 8 | PUT test01_index/_doc/5 9 | { 10 | "x_value":15, 11 | "y_value":3 12 | } 13 | 14 | 15 | POST test01_index/_doc/_search 16 | { 17 | "script_fields": { 18 | "my_divide_field": { 19 | "script": { 20 | "lang": "expression", 21 | "source": "doc['y_value'].value != 0 ? doc['x_value'].value / doc['y_value'].value : 0" 22 | } 23 | } 24 | } 25 | } 26 | ``` 27 | 28 | # 2、查一个字段是否存在，且长度大于1 29 | ``` 30 | POST test01_index/_doc/_search 31 | { 32 | "query": { 33 | "bool": { 34 | "must": { 35 | "exists": { 36 | "field": "cont" 37 | } 38 | }, 39 | "filter": { 40 | "script": { 41 | "script": "doc['cont'].length >= 1" 42 | } 43 | } 44 | } 45 | } 46 | } 47 | ``` 48 | 49 | # 3、全局更新字段，一个值赋值给另外一个 50 | ``` 51 | POST test_info/_update_by_query?conflicts=proceed 52 | { 53 | "script": { 54 | "source": "ctx._source.contnew = ctx._source.cont", 55 | "lang": "painless" 56 | }, 57 | "query": { 58 | "exists": { 59 | "field": "cont" 60 | } 61 | } 62 | } 63 | ``` 64 | -------------------------------------------------------------------------------- /es_dsl_study/5.fielddata_dsl.md: -------------------------------------------------------------------------------- 1 | # 提问: 2 | 请问一下，我存储一个人喜爱的运动，前端传递过来的数据是id，名称，是一个list集合，我在es怎样设计存储数据结构？ 3 | 4 | 是存储一个字符串，还是怎么弄，查询时如何查询？第一次弄，不确定怎么设计好，希望大佬解答，将不胜感激。 5 | 6 | ``` 7 | DELETE hobby_index 8 | PUT hobby_index 9 | { 10 | "mappings": { 11 | "_doc": { 12 | "properties":{ 13 | "name":{ 14 | "type":"text", 15 | "analyzer":"ik_smart", 16 | "fields":{ 17 | "keyword":{ 18 | "type":"keyword" 19 | } 20 | } 21 | }, 22 | "hobby":{ 23 | "type":"text", 24 | "analyzer":"ik_smart", 25 | "fields":{ 26 | "keyword":{ 27 | "type":"keyword" 28 | }}, 29 | "fielddata":true 30 | } 31 | } 32 | } 33 | } 34 | } 35 | 36 | POST hobby_index/_doc/1 37 | { 38 | "name":"张三", 39 | "hobby":["乒乓球", "羽毛球", "篮球"] 40 | } 41 | 42 | POST hobby_index/_doc/2 43 | { 44 | "name":"李四", 45 | "hobby":["乒乓球", "篮球"] 46 | } 47 | 48 | POST hobby_index/_doc/3 49 | { 50 | "name":"王五", 51 | "hobby":["乒乓球"] 52 | } 53 | 54 | GET hobby_index/_search 55 | 56 | #聚合维度 57 | POST hobby_index/_search 58 | { 59 | "size":0, 60 | "aggs": { 61 | "hobby_aggs": { 62 | "terms": { 63 | "field": "hobby", 64 | "size": 10 65 | } 66 | } 67 | } 68 | } 69 | 70 | 71 | #检索维度 72 | POST hobby_index/_search 73 | { 74 | "query": { 75 | "bool": { 76 | "should": [ 77 | { 78 | "match_phrase": { 79 | "hobby": "乒乓球" 80 | } 81 | }, 82 | { 83 | "match_phrase": { 84 | "hobby": "篮球" 85 | } 86 | }, 87 | { 88 | "match_phrase": { 89 | "hobby": "羽毛球" 90 | } 91 | } 92 | ] 93 | } 94 | 95 | } 96 | } 97 | ``` 98 | 99 | ES版本：6.6.1 100 | -------------------------------------------------------------------------------- /es_dsl_study/6.scripting.md: -------------------------------------------------------------------------------- 1 | # 1、返回以XX为开头的字段的全部信息 2 | ``` 3 | POST seats/_search 4 | { 5 | "query": { 6 | "bool":{ 7 | "filter": { 8 | "script":{ 9 | "script":{ 10 | "lang":"painless", 11 | "source": "doc['theatre'].value.startsWith('Down')" 12 | } 13 | } 14 | } 15 | } 16 | } 17 | } 18 | ``` 19 | 20 | # 2、 21 | 请教大神指点。我有个中文的文本tesxt。已经分词，数据库中字段存放的是ik分词 公司名称：中国电信集团有限公司潍坊分公司 22 | 。我想所搜一个关键字我要求必须匹配度为95%。 23 | ``` 24 | GET bingo_sel/bingo_test/_search? 25 | { 26 | "query": { 27 | "query_string":{ 28 | "default_field":"公司名称", 29 | "query": "中国电信", 30 | "minimum_should_match":"90" 31 | } 32 | } 33 | } 34 | ``` 35 | 这个可以搜索出机构。但我想要的是公司名称整个匹配的90%，而不是我搜索字段的90%匹配 36 | 37 | 期望的结果是： 中国电信集团有限公司潍坊 可以查询出来 38 | 中国电信 不能查询出来 39 | 40 | 请大神指点方向 41 | 42 | 43 | ``` 44 | PUT bingo_sel 45 | { 46 | "mappings": { 47 | "properties": { 48 | "name":{ 49 | "type":"text", 50 | "analyzer": "ik_max_word", 51 | "fields": { 52 | "keyword":{ 53 | "type":"keyword" 54 | }, 55 | "standard":{ 56 | "type":"text", 57 | "analyzer":"standard" 58 | } 59 | } 60 | } 61 | } 62 | } 63 | } 64 | 65 | POST bingo_sel/_bulk 66 | {"index":{"_id":1}} 67 | {"name":"中国电信"} 68 | {"index":{"_id":2}} 69 | {"name":"中国电信集团有限公司潍坊"} 70 | {"index":{"_id":3}} 71 | {"name":"中国电信集团有限公司潍坊分公司"} 72 | 73 | 74 | POST bingo_sel/_search 75 | { 76 | "query": { 77 | "bool": { 78 | "must": [ 79 | { 80 | "match_phrase": { 81 | "name.standard": "中国电信集团有限公司潍坊" 82 | } 83 | }, 84 | { 85 | "prefix": { 86 | "name.keyword": { 87 | "value": "中国电信集团有限公司潍坊" 88 | } 89 | } 90 | }, 91 | { 92 | "script": { 93 | "script": { 94 | "source": "doc['name.keyword'].value.length() > 11", 95 | "lang": "painless" 96 | } 97 | } 98 | } 99 | ] 100 | } 101 | } 102 | } 103 | ``` 104 | -------------------------------------------------------------------------------- /es_dsl_study/7.analysis.md: -------------------------------------------------------------------------------- 1 | ``` 2 | 3 | DELETE test 4 | PUT test 5 | { 6 | "mappings": { 7 | "properties": { 8 | "afval": 9 | { 10 | "type":"keyword" 11 | } 12 | } 13 | } 14 | } 15 | 16 | POST test/_doc/1 17 | { 18 | "afval":"00:01" 19 | } 20 | 21 | POST test/_search 22 | { 23 | "query": { 24 | "term": { 25 | "afval": { 26 | "value": "00:01" 27 | } 28 | } 29 | } 30 | } 31 | 32 | POST test/_search 33 | { 34 | "query": { 35 | "wildcard": { 36 | "afval": { 37 | "value": "*00:01*" 38 | } 39 | } 40 | } 41 | } 42 | 43 | POST test/_doc/2 44 | { 45 | "afval":"987pou" 46 | } 47 | 48 | # 搜不出来 49 | POST test/_search 50 | { 51 | "query": { 52 | "term": { 53 | "afval": "pou" 54 | } 55 | } 56 | } 57 | 58 | #能搜出来 59 | POST test/_search 60 | { 61 | "query": { 62 | "wildcard": { 63 | "afval": "*pou*" 64 | } 65 | } 66 | } 67 | 68 | # 自定义分词解决问题 69 | DELETE testext 70 | PUT testext 71 | { 72 | "settings": { 73 | "analysis": { 74 | "analyzer": { 75 | "my_analyzer": { 76 | "tokenizer": "my_tokenizer" 77 | } 78 | }, 79 | "tokenizer": { 80 | "my_tokenizer": { 81 | "type": "ngram", 82 | "min_gram": 1, 83 | "max_gram": 1, 84 | "token_chars": [ 85 | ] 86 | } 87 | } 88 | } 89 | }, 90 | "mappings": { 91 | "properties": { 92 | "afval":{ 93 | "type":"text", 94 | "analyzer":"my_analyzer" 95 | } 96 | } 97 | } 98 | } 99 | 100 | GET testext/_mapping 101 | 102 | POST testext/_doc/2 103 | { 104 | "afval":"987pou" 105 | } 106 | 107 | POST testext/_analyze 108 | { 109 | "text": "987pou", 110 | "analyzer": "my_analyzer" 111 | } 112 | 113 | POST testext/_search 114 | { 115 | "query": { 116 | "match_phrase": { 117 | "afval": "pou" 118 | } 119 | } 120 | } 121 | ``` 122 | 123 | 124 | -------------------------------------------------------------------------------- /es_dsl_study/8.ngram.md: -------------------------------------------------------------------------------- 1 | # 1、使用edge ngram将每个单词都进行进一步的分词切分，用切分后的ngram来实现前缀搜索推荐功能 2 | ``` 3 | DELETE my_index 4 | PUT /my_index 5 | { 6 | "settings": { 7 | "analysis": { 8 | "filter": { 9 | "autocomplete_filter": { 10 | "type": "edge_ngram", 11 | "min_gram": 1, 12 | "max_gram": 20 13 | } 14 | }, 15 | "analyzer": { 16 | "autocomplete": { 17 | "type": "custom", 18 | "tokenizer": "standard", 19 | "filter": [ 20 | "lowercase", 21 | "autocomplete_filter" 22 | ] 23 | } 24 | } 25 | } 26 | } 27 | } 28 | 29 | GET /my_index/_analyze 30 | { 31 | "analyzer": "autocomplete", 32 | "text": "quick brown" 33 | } 34 | 35 | PUT /my_index/_mapping 36 | { 37 | "properties": { 38 | "title": { 39 | "type": "text", 40 | "analyzer": "autocomplete", 41 | "search_analyzer": "standard" 42 | } 43 | } 44 | } 45 | 46 | POST my_index/_doc/1 47 | { 48 | "title":"hello world" 49 | } 50 | 51 | 52 | GET /my_index/_search 53 | { 54 | "query": { 55 | "match_phrase": { 56 | "title": "hello w" 57 | } 58 | } 59 | } 60 | ``` 61 | 示例来自中华石杉讲义，7.2版本实践一把 62 | 63 | # 2、星球问题： 64 | 65 | 您好，请教个问题。我现在有2千多万的手机号码信息保存在es里。5个分片，3个节点。 66 | 67 | 现在的需求是将后八位相同的号码匹配到一起，重新放到一个index里。组成情侣号。 68 | 69 | 方便后续查询情侣号列表。我目前的做法是用scroll查询出一万条，多线程循环一万条中的每条，去全库扫描--- 70 | 71 | 但是这种做法一分钟才能处理一万条。您有什么新的思路没。 72 | 73 | 74 | # 2.1 方案一 75 | 76 | 描述如下： 77 | 78 | （1）手机号的切词要注意，这里按照ngram切词，后面可能用到（实际聚合没用，检索会用） 79 | 80 | （2）聚合terms+top_hits 获取相同手机号的号码列表 81 | 82 | （3）reindex 这些对应手机号所在的id数据到目标索引 83 | 84 | ``` 85 | DELETE phone_index 86 | PUT phone_index 87 | { 88 | "mappings": { 89 | "properties": { 90 | "phone_number": { 91 | "type": "text", 92 | "fields": { 93 | "keyword": { 94 | "type": "keyword" 95 | } 96 | }, 97 | "analyzer": "ngram_analyzer" 98 | } 99 | } 100 | }, 101 | "settings": { 102 | "number_of_replicas": 0, 103 | "index": { 104 | "max_ngram_diff": "13", 105 | "analysis": { 106 | "analyzer": { 107 | "ngram_analyzer": { 108 | "tokenizer": "ngram_tokenizer" 109 | } 110 | }, 111 | "tokenizer": { 112 | "ngram_tokenizer": { 113 | "token_chars": [ 114 | "letter", 115 | "digit" 116 | ], 117 | "min_gram": "1", 118 | "type": "ngram", 119 | "max_gram": "11" 120 | } 121 | } 122 | } 123 | } 124 | } 125 | } 126 | 127 | POST phone_index/_bulk 128 | {"index":{"_id":1}} 129 | {"phone_number" : "13511112222"} 130 | {"index":{"_id":2}} 131 | {"phone_number" : "13611112222"} 132 | {"index":{"_id":3}} 133 | {"phone_number" : "13711112222"} 134 | {"index":{"_id":4}} 135 | {"phone_number" : "13811112222"} 136 | {"index":{"_id":5}} 137 | {"phone_number" : "13822112222"} 138 | 139 | 140 | GET phone_index/_search 141 | { 142 | "aggs": { 143 | "genres": { 144 | "terms": { 145 | "script": { 146 | "source": "doc['phone_number.keyword'].value.substring(3,11)", 147 | "lang": "painless" 148 | }, 149 | "min_doc_count": 2, 150 | "size": 10, 151 | "shard_size": 200 152 | } 153 | } 154 | } 155 | } 156 | GET _cat/indices 157 | GET phone_index/_search 158 | { 159 | "size": 0, 160 | "aggs": { 161 | "genres": { 162 | "terms": { 163 | "script": { 164 | "source": "doc['phone_number.keyword'].value.substring(3,11)", 165 | "lang": "painless" 166 | }, 167 | "min_doc_count": 2, 168 | "size": 100 169 | }, 170 | "aggs": { 171 | "top_hits_aggs": { 172 | "top_hits": { 173 | "size": 100, 174 | "sort": [ 175 | { 176 | "phone_number.keyword": { 177 | "order": "asc" 178 | } 179 | } 180 | ] 181 | } 182 | } 183 | } 184 | } 185 | } 186 | } 187 | 188 | PUT phone_index_loves 189 | 190 | POST _reindex 191 | { 192 | "source": { 193 | "index": "phone_index", 194 | "query": { 195 | "terms": { 196 | "_id": [ 197 | 1, 198 | 2, 199 | 3, 200 | 4 201 | ] 202 | } 203 | } 204 | }, 205 | "dest": { 206 | "index": "phone_index_loves" 207 | } 208 | } 209 | 210 | GET phone_index_loves/_search 211 | ``` 212 | 213 | # 2.2、方案二 214 | 215 | 注意：方案一中的script很重，建议写入的时候，将后8位数据作为一个字段写入。 216 | 217 | 其他步骤雷同。 218 | -------------------------------------------------------------------------------- /es_dsl_study/9.template.md: -------------------------------------------------------------------------------- 1 | ``` 2 | PUT sampleindex/_doc/1 3 | { 4 | "Value":123 5 | } 6 | 7 | GET sampleindex/_mapping 8 | 9 | 10 | PUT _template/sample_dynamic_template 11 | { 12 | "index_patterns": [ 13 | "sample*" 14 | ], 15 | "mappings": { 16 | "dynamic_templates": [ 17 | { 18 | "handle_integers": { 19 | "match_mapping_type": "long", 20 | "mapping": { 21 | "type": "integer" 22 | } 23 | } 24 | }, 25 | { 26 | "handle_date": { 27 | "match": "date_*", 28 | "unmatch": "*_text", 29 | "mapping": { 30 | "type": "date" 31 | } 32 | } 33 | } 34 | ] 35 | } 36 | } 37 | 38 | DELETE sampleindex 39 | PUT sampleindex/_doc/1 40 | { 41 | "Value":123, 42 | "date_curtime":"1574494620000" 43 | } 44 | 45 | GET sampleindex/_mapping 46 | ``` 47 | -------------------------------------------------------------------------------- /es_howtodo/how_to_do_elasticsearch.md: -------------------------------------------------------------------------------- 1 | # Elasticsearch 十万个 怎么办？ 2 | 3 | 【死磕ES知识星球】 4 | 5 | http://t.cn/RmwM3N9 6 | 7 | 8 | 【死磕ES公众号】 9 | 10 | 铭毅天下； 11 | 12 | 【加微信】 13 | 14 | elastic6，精进Elastic! 15 | 16 | ... 17 | 18 | 2020-国庆-花6个小时-梳理版本-V1.0 19 | 20 | 题记： 21 | 梳理知识星球的问题和知识点，让大家普遍反应的问题变成你、我的认知常识问题，提升你的 Elasticsearch 技术认知。 22 | 23 | 全面覆盖 死磕 Elasticsearch 知识星球的近3年全部球友提问问题，都是实战干货问题，都是实战解答。 24 | 25 | 花费近6个小时（只有国庆有这么多时间梳理），你值得拥有！！ 26 | 27 | # 1、遇到 Elasticsearch 集群规划问题，怎么办？ 28 | 29 | https://t.zsxq.com/VvFeIaa 30 | 31 | https://t.zsxq.com/iaurF2n 32 | 33 | https://t.zsxq.com/F27A2rf 34 | 35 | https://t.zsxq.com/uNVRzjU 36 | 37 | https://t.zsxq.com/6E6mU7Q 38 | 39 | https://t.zsxq.com/FAIMNNf 40 | 41 | https://t.zsxq.com/2fAEyB6 42 | 43 | 索引、分片等规划避坑指北必读： 44 | https://t.zsxq.com/7iiiM7m 45 | 46 | https://t.zsxq.com/7iiiM7m 47 | 48 | # 2、遇到 Elasticsearch 分片分配问题，怎么办？ 49 | 50 | https://t.zsxq.com/7iiiM7m 51 | 52 | https://t.zsxq.com/YNNjAyF 53 | 54 | https://t.zsxq.com/yVV7YVV 55 | 56 | https://t.zsxq.com/iAiEayV 57 | 58 | https://t.zsxq.com/2niY3fE 59 | 60 | https://t.zsxq.com/ZfEmYnE 61 | 62 | https://t.zsxq.com/ufAyzNJ 63 | 64 | 如何保障分片分配均衡策略如下： 65 | 66 | https://t.zsxq.com/7aAEmUZ 67 | 68 | https://t.zsxq.com/37yVfEu 69 | 70 | https://t.zsxq.com/BYVNRbM 71 | 72 | 分片数和副本数设置必读： 73 | 74 | https://t.zsxq.com/BuBMrFQ 75 | 76 | https://t.zsxq.com/QNZJEQn 77 | 78 | 单个文档有大小限制吗？ 79 | 80 | https://t.zsxq.com/3fu3J23 81 | 82 | # 3、遇到 Elasticsearch CPU 使用率高相关问题，怎么办？ 83 | https://t.zsxq.com/fqNNVny 84 | 85 | https://t.zsxq.com/R7QzFMR 86 | 87 | https://t.zsxq.com/AIuzVjA 88 | 89 | https://t.zsxq.com/EiQbyrJ 90 | 91 | 阿里云 关于CPU使用率的建议： 92 | 93 | https://t.zsxq.com/Yjmqb6U 94 | 95 | https://t.zsxq.com/EiQbyrJ 96 | 97 | https://t.zsxq.com/uz7M7ei 98 | 99 | Mysql 同步 ES CPU使用率 高怎么办？ 100 | 101 | https://t.zsxq.com/Ee2zVnm 102 | 103 | https://t.zsxq.com/QjiAMVF 104 | 105 | 国企线上 ES CPU 问题： 106 | 107 | https://t.zsxq.com/RNzz7I6 108 | 109 | https://t.zsxq.com/NZBaImE 110 | 111 | 高并发 QPS飙升问题： 112 | 113 | https://t.zsxq.com/vjIIaEI 114 | 115 | # 4、遇到 Elasticsearch 内存 相关问题，怎么办？ 116 | 117 | https://t.zsxq.com/B2fUNne 118 | 119 | https://t.zsxq.com/EQbuB2f 120 | 121 | https://t.zsxq.com/R7QzFMR 122 | 123 | https://t.zsxq.com/ZZFmMZ3 124 | 125 | 内存必读笔记： 126 | 127 | https://t.zsxq.com/IM37iUJ 128 | 129 | 内存拆解图解分析 130 | 131 | https://t.zsxq.com/qjUVFMz 132 | 133 | https://t.zsxq.com/YZNrbEM 134 | 135 | # 5、遇到 Elasticsearch 磁盘 相关问题，怎么办？ 136 | 137 | https://t.zsxq.com/FYrzRJm 138 | 139 | https://t.zsxq.com/r7UbAYb 140 | 141 | https://t.zsxq.com/Z3V3zRJ 142 | 143 | 有赞磁盘IO 问题——高配机器磁盘io不达标引发的写入、查询超时问题。 144 | 145 | https://t.zsxq.com/me6mUzR 146 | 147 | # 6、遇到 Elasticsearch 故障 问题，怎么办？ 148 | 149 | https://t.zsxq.com/a6MNvNR 150 | 151 | https://t.zsxq.com/AyzZvjY 152 | 153 | https://t.zsxq.com/f27mmYb 154 | 155 | https://t.zsxq.com/urZNneQ 156 | 157 | # 7、遇到 Elasticsearch 写入性能优化问题，怎么办？ 158 | 159 | https://t.zsxq.com/Z3V3zRJ 160 | 161 | https://t.zsxq.com/2RJQjMJ 162 | 163 | https://t.zsxq.com/QjemeYf 164 | 165 | https://t.zsxq.com/uz7M7ei 166 | 167 | https://t.zsxq.com/iYnEqb2 168 | 169 | https://t.zsxq.com/7QN7qNf 170 | 171 | https://t.zsxq.com/Ea6QNnY 172 | 173 | bulk 性能优化实践： 174 | 175 | https://t.zsxq.com/FAy7iI2 176 | 177 | 178 | # 8、遇到 Elasticsearch 检索/查询性能优化问题，怎么办？ 179 | https://t.zsxq.com/AIuzVjA 180 | 181 | https://t.zsxq.com/AQVjQby 182 | 183 | https://t.zsxq.com/Z3V3zRJ 184 | 185 | 性能问题排查通识方法论 186 | 187 | https://t.zsxq.com/JqbieEi 188 | 189 | https://t.zsxq.com/7QN7qNf 190 | 191 | https://t.zsxq.com/eYBIyr3 192 | 193 | 脚本检索，慢慢慢，怎么办？ 194 | 195 | https://t.zsxq.com/IQFU7y7 196 | 197 | 大文件检索性能优化方案： 198 | 199 | https://t.zsxq.com/ba2b6Mz 200 | 201 | 8亿数据查询慢，如何优化： 202 | 203 | https://t.zsxq.com/aqfy7YJ 204 | 205 | # 9、遇到 Elasticsearch 选型问题，怎么办？ 206 | 207 | https://t.zsxq.com/vRv3nqb 208 | 209 | https://t.zsxq.com/eAqzfmq 210 | 211 | https://t.zsxq.com/jIMVJmq 212 | 213 | 关于Elasticsearch 和 clickhouse 适用场景和选型指南，腾讯云大佬如是说： 214 | 215 | https://t.zsxq.com/3F2VN7A 216 | 217 | https://t.zsxq.com/6UVnE6y 218 | 219 | 220 | mysql 到 ES 同步选型： 221 | 222 | https://t.zsxq.com/Rni6Ey3 223 | 224 | https://t.zsxq.com/q3RF6IQ 225 | 226 | ES 升级选型必读： 227 | 228 | https://t.zsxq.com/RZrJ6UJ 229 | 230 | 231 | 传统数据库与 ES边界，选型必读： 232 | 233 | https://t.zsxq.com/6UVnE6y 234 | 235 | Elasticsearch 技术方案选型的10个注意事项： 236 | 237 | https://t.zsxq.com/JAiYfmu 238 | 239 | https://t.zsxq.com/q3RF6IQ 240 | 241 | https://t.zsxq.com/vBAeqZ3 242 | 243 | Elasticsearch在处理大数据量实时聚合的时候会响应非常慢，方案选型可以考虑Flink或者Spark。 244 | 245 | https://t.zsxq.com/yrfEQny 246 | 247 | # 10、遇到 Elasticsearch 数据建模问题，怎么办？ 248 | 249 | https://t.zsxq.com/aUBImiq 250 | 251 | https://t.zsxq.com/j2jUVJY 252 | 253 | https://t.zsxq.com/EQvVBYr 254 | 255 | https://t.zsxq.com/6UVnE6y 256 | 257 | https://t.zsxq.com/aUBImiq 258 | 259 | 数据建模的重要性，再多强调也不为过！ 260 | 261 | https://t.zsxq.com/eQ3rVBq 262 | 263 | 理想的Mapping 是怎么样的？ 264 | 265 | https://t.zsxq.com/rZF27Yr 266 | 267 | # 11、遇到 Elasticsearch 节点下线问题，怎么办？ 268 | 269 | https://t.zsxq.com/byBYNvv 270 | 271 | https://t.zsxq.com/Aaqn237 272 | 273 | https://t.zsxq.com/qJeayjq 274 | 275 | # 12、遇到 Elasticsearch 集群角色划分，怎么办？ 276 | 277 | https://t.zsxq.com/6aubqvz 278 | 279 | https://t.zsxq.com/U7AmAaA 280 | 281 | https://t.zsxq.com/2fAEyB6 282 | 283 | 284 | https://t.zsxq.com/FUZvByf 285 | 286 | 图解角色划分： 287 | 288 | https://t.zsxq.com/FUZvByf 289 | 290 | https://t.zsxq.com/uB6UfyB 291 | 292 | 58 同城角色 划分实践 293 | 294 | https://t.zsxq.com/Z7uNrVB 295 | 296 | https://t.zsxq.com/FUZvByf 297 | 298 | 299 | 300 | # 13、遇到 Elasticsearch gc 问题，怎么办？ 301 | 302 | https://t.zsxq.com/FmqRfiq 303 | 304 | https://t.zsxq.com/R7QzFMR 305 | 306 | 307 | https://t.zsxq.com/urFqJyB 308 | 309 | https://t.zsxq.com/n6iUJmM 310 | 311 | 312 | https://t.zsxq.com/iAiEayV 313 | 314 | https://t.zsxq.com/6yrNF23 315 | 316 | OOM问题排查： 317 | 318 | https://t.zsxq.com/mAqRv3R 319 | 320 | 请求超时问题汇总： 321 | 322 | https://t.zsxq.com/iAiEayV 323 | 324 | scroll 遍历导致的gc 问题 解决方案： 325 | 326 | https://t.zsxq.com/2BUZRJU 327 | 328 | 母婴店 搜索架构师反馈的gc问题： 329 | 330 | https://t.zsxq.com/ubyrRzn 331 | 332 | # 14、遇到 Elasticsearch 恢复问题， 怎么办？ 333 | 334 | https://t.zsxq.com/nyfiAam 335 | 336 | https://t.zsxq.com/ubyrRzn 337 | 338 | 339 | 340 | # 15、遇到 Elasticsearch 宕机问题，怎么办？ 341 | 342 | https://t.zsxq.com/q7YNfIa 343 | 344 | https://t.zsxq.com/UzBqNvR 345 | 346 | https://t.zsxq.com/V72VjEQ 347 | 348 | https://t.zsxq.com/aaI62JM 349 | 350 | https://t.zsxq.com/yrnMzrN 351 | 352 | https://t.zsxq.com/AmMBMRb 353 | 354 | 集群红色排查： 355 | 356 | https://t.zsxq.com/mYvJqzz 357 | 358 | 一个节点挂了，为什么集群宕机了？ 359 | 360 | https://t.zsxq.com/MvBEUfq 361 | 362 | 363 | 警惕 wildcard 模糊查询 364 | 365 | https://t.zsxq.com/UJiQvjY 366 | 367 | 避免写入太快： 368 | 369 | https://t.zsxq.com/V72VjEQ 370 | 371 | # 16、遇到 Elasticsearch 面试概念不清，怎么办？ 372 | 373 | 推荐一个好习惯：时刻准备面试 374 | 375 | https://t.zsxq.com/q3F2vZ3 376 | 377 | https://t.zsxq.com/n6iUJmM 378 | 379 | 面试题：如何避免脑裂？ 380 | 381 | https://t.zsxq.com/JQz7aQr 382 | 383 | # 17、遇到 Elasticsearch 段合并问题，怎么办？ 384 | 385 | https://t.zsxq.com/2niY3fE 386 | 387 | https://t.zsxq.com/nyBmuVz 388 | 389 | https://t.zsxq.com/2VBmqZ3 390 | 391 | https://t.zsxq.com/2niY3fE 392 | 393 | https://t.zsxq.com/6UNfMb6 394 | 395 | https://t.zsxq.com/BAaaima 396 | 397 | # 18、遇到 Elasticsearch Reject 问题，怎么办？ 398 | 399 | https://t.zsxq.com/QjiAMVF 400 | 401 | https://t.zsxq.com/BUf2jIa 402 | 403 | https://t.zsxq.com/VVN3RNN 404 | 405 | 406 | https://t.zsxq.com/fmIYZvr 407 | 408 | 409 | https://t.zsxq.com/NjeurrJ 410 | 411 | https://t.zsxq.com/QjiAMVF 412 | 413 | 414 | https://t.zsxq.com/YNJQfUJ 415 | --------------------------------------------------------------------------------