J'utilise ElasticSearch 2.4, avec le plugin icu_analysis ajouté pour fournir le tri sur le texte japonais. Il fonctionne assez bien sur mon environnement local, qui a un nombre limité de documents, mais lorsque je tente sur un ensemble de données plus réaliste, les requêtes échouent avec l'CircuitBreakingException suivante:provoquant CircuitBreakingException sorte imbriquée à l'aide icu_collation pour le texte japonais
"CircuitBreakingException[[fielddata] Data too large, data for [translations.name.jp_sort] would be larger than limit of [10239895142/9.5gb]]"
Je comprends que cela se produit lors d'une tentative de tri sur fielddata avec un grand nombre de documents et que docvalues doivent être utilisés à la place - mais je ne sais pas si cela peut être fait dans cette situation ou pourquoi il ne se produit pas déjà.
Il y a environ 470 millions de documents dans l'index, qui stockent les traductions comme un document imbriqué - seulement 35 millions sur l'ensemble contiennent une traduction japonaise. Voici le mappage pour les documents:
{
"settings" : {
"number_of_shards" : 6,
"number_of_replicas": 0,
"analysis": {
"filter": {
"trigrams_filter": {
"type": "ngram",
"min_gram": 3,
"max_gram": 3
},
"japanese_ordering": {
"type": "icu_collation",
"language": "ja",
"country": "JP"
}
},
"analyzer": {
"trigrams": {
"tokenizer": "my_ngram_tokenizer",
"filter": "lowercase"
},
"japanese_ordering": {
"tokenizer": "keyword",
"filter": [ "japanese_ordering" ]
}
},
"tokenizer": {
"my_ngram_tokenizer": {
"type": "nGram",
"min_gram": "3",
"max_gram": "3",
"token_chars": [
"letter",
"digit",
"symbol",
"punctuation"
]
}
}
}
},
"mappings" : {
"product" : {
"_all" : {
"enabled" : false
},
"properties" : {
"name" : {
"type" : "string",
"analyzer": "trigrams",
"fields": {
"value" : {
"type": "string",
"index": "not_analyzed"
}
}
},
"record_status" : {
"type" : "integer"
},
"categories" : {
"type" : "integer"
},
"variant_status" : {
"type" : "integer"
},
"visit_count" : {
"type" : "integer"
},
"translations": {
"type": "nested",
"properties": {
"name": {
"type": "string",
"fields": {
"jp_sort": {
"type": "string",
"analyzer": "japanese_ordering"
}
}
},
"language_id": {
"type": "short"
}
}
}
}
}
}
}
et c'est la requête qui est CircuitBreaking:
{
"from": 0,
"size": 20,
"query": {
"bool": {
"should": [],
"must_not": [],
"must": [{
"nested": {
"path": "translations",
"score_mode": "max",
"query": {
"bool": {
"must": [{
"match": {
"translations.name": {
"query": "\u30C6\u30B9\u30C8",
"boost": 5
}
}
}]
}
}
}
}]
}
},
"filter": {
"bool": {
"must": [{
"terms": {
"variant_status": ["1"],
"_cache": true
}
}, {
"nested": {
"path": "translations",
"query": {
"bool": {
"must": [{
"term": {
"translations.language_id": 9,
"_cache": true
}
}]
}
}
}
}, {
"term": {
"record_status": 1,
"_cache": true
}
}],
"must_not": [{
"term": {
"product_collections": 0
}
}]
}
},
"sort": [{
"translations.name.jp_sort": {
"order": "asc",
"nested_path": "translations"
}
}]
}
Le 5.5 ES version a introduit un nouveau type de champ appelé 'icu_collation_keyword' qui résout le problème que vous rencontrez. Vous pouvez en lire plus ici: https://www.elastic.co/blog/elasticsearch-5-5-0-released – Val
Cela fait réellement résoudre - j'ai passé quelques heures de mise à jour mes requêtes et indexeur pour le changement de version, et puis essayé icu_collation_keyword. Ça marche bien, et c'est rapide! Si vous voulez soumettre votre commentaire en réponse, je le marquerai comme accepté. Merci! –