Chaque indexe est spécifique à une langue et possède un analyseur particulier pour cette langue
Sinon oui c'est le même rôle
dans chaque indexe on a déjà des types : (cpTitle, cpDesc, advText, keyWord etc...)
L'idée c'était d'avoir un indexe par langue
Chaque type peut avoir son analyseur propre.
Bon j'vais pas tout péter. J'vais essayer avec plus de RAM 
Comme dit @dadoonet pourquoi ne pas utiliser un analyseur ?
PUT /labels
{
"mappings": {
"label": {
"properties" : {
"title": {
"type" : "string"
},
"title_fr": {
"type": "string",
"analyser": "french"
},
"title_en": {
"type": "string",
"analyser": "english"
}[...]
Avec un seul shard et un mapping comme celui-ci utilisant des analyseurs propres, ton serveur devrait beaucoup mieux se porter.
Et sans tout pêter tu peux faire un Snapshot & Restore et réindexer les documents.
Pas vraiment. Snapshot et Restore ne fonctionne pas par document mais sauvegarde un index dans son ensemble (y compris son organisation : nb de shards, mappings, ...).
Si tu veux faire de la réindexation, tu peux lire mon blog à ce sujet. Il y a d'autres méthodes également.
J'ai pu augmenter la capacité des machines. J'ai accès à 24 processeurs et 8 Go de RAM par serveur.
Le problème ne se produit maintenant que si j'ai des champs indexés avec le plugin phonetic. Sur mes TU c'est toujours sur le même document que ça va partir en vrille. Ce n'est pas le document en lui même qui pose problème par contre, c'est l'enchainement de 49253 inserts ce qui n'est à priori pas énorme.
Mon code :
...
BulkProcessor bulkProcessor;
bulkProcessor = BulkProcessor.builder(elasticSearchService.getClient(), new BulkProcessor.Listener() {
@Override
public void beforeBulk(long executionId, BulkRequest request) {
}
@Override
public void afterBulk(long executionId, BulkRequest request, BulkResponse response) {
if (response.hasFailures()) {
for (BulkItemResponse item : response.getItems()) {
LOGGER.error("Processing to index \"{}\" with type \"{}\" failed for entity id {} with message {}", item.getIndex(), item.getType(),
item.getId(), item.getFailureMessage());
LOGGER.error(response.buildFailureMessage());
}
}
LOGGER.info("bulk insert composed of {} actions took {}. Time per document {}", request.numberOfActions(), response.getTookInMillis(),
response.getTookInMillis() / request.numberOfActions()
);
}
@Override
public void afterBulk(long executionId, BulkRequest request, Throwable afterBulk) {
LOGGER.error("Error while index in ELS failure:"+afterBulk.getMessage(), afterBulk);
}
})
.setFlushInterval(TimeValue.timeValueSeconds(5))
.setBulkActions(1).setConcurrentRequests(1).build();
for (String line : lines) { // CSV lines containing the table,index & field that I need to insert
System.out.println(line);
tabLine = line.split(";");
bulkProcessor.add(new IndexRequest(tabLine[0], tabLine[1]).source(jsonBuilder().
startObject()
.field("code", tabLine[2])
.field("hash", tabLine[3])
.field("text", tabLine[4])
.endObject()));
}
...
Je suis toujours avec du Elastic 1.7.0 sur de FreeBsd.
Dans mon rc.conf j'ai
elasticsearch_min_mem=4G
elasticsearch_max_mem=4GLe mapping actuel : http://pastebin.com/aUETpBbQ
Ce mapping est il non viable avec Elastic ? Faut il que je le repense entièrement en utilisant par exemple labels comme nom d'index et les champ text-fr, text-en, text-pl etc ... ?
Cordialement,
Blured.
Dans le livre 'ElasticSearch The definitive guide, il est indiqué que les différentes solutions sont viables :
. One language per document
. One language per field
Idem dans les tutoriaux d'elastic.
Je suis monté à 16 Go de heap, toujours le même problème
Je ne sais pas pour les autres, mais pour moi, il est difficile ici de comprendre ce qui arrive.
Tu aurais moyen de refaire un résumé complet de la nouvelle situation ? Les logs, ...
Peut-être des nodes stats pour comprendre ?
Voici le résumé :
Les CPU de mon serveur ELS plafonnent à 100%, et la mémoire arrive rapidement à saturation entrainant forcément des GC.
J'ai constaté ça même avec 16 Go de Heap (et 80 Go de RAM accessible), 0 swap.
Le mapping utilisé : http://pastebin.com/aUETpBbQ
La volumétrie : 8 Millions de documents
A priori le problème se siturait lors de l'utilisation des "phonetic analyser" lors de l'insertion. En les enlevant je n'ai pas le problème des CPU qui s'excitent, qui bloquent la suite des traitements et qui bouffent toute la mémoire.
Avez-vous déjà rencontré ce pb ?
Blured.
Premier nodestat après constatation du blocage :
http://pastebin.com/0yELNqKy
Au niveau top j'ai
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
19322 elasticsearch 239 52 0 17799M 3490M uwait 9 7:23 112.30% java
Je vais rattacher les nodes stats suivant à ce fil de discussion
2eme nodestat
http://pastebin.com/9ZMDwdM8
top
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
19322 elasticsearch 235 20 0 17799M 4626M uwait 19 14:42 114.06% java
3eme nodestat
http://pastebin.com/yvBPfLzn
top
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
19322 elasticsearch 235 20 0 17799M 5877M uwait 19 31:27 119.92% java
En local sous windows avec la même version de ELS + Jdk 1.7 de chez Oracle tout se passe correctement. C'est vraiement bizarre.
La mise à niveau de l'OpenJDK 1.7 --> 1.8 sur la machine FreeBsd n'a rien changé
Je viens d'isoler plus précisément le problème. Il s'agit des langues != french utilisant l'encoder beider_morse. Ca passe très bien sous windows mais sous freebsd ça fait flipper le GC. Bizzarre. Bon en tout cas je mets tout en double_metaphone et c'est beaucoup mieux 
Très intéressant. Je pense que ça vaudrait le coup de signaler cette différence de comportement à Lucene (ou elasticsearch) sous forme d'issue. Ça cache peut-être quelque chose d'important ???
Ouaip je fais affiner le pb avant. Parce que ce n'est pas le cas de tous les languageset de beidermorse à priori.