Bonjour Amandine,
J'ai justement un talk (mon talk favori à vrai dire) qui parle de ce sujet. En voici un résumé sous forme de blog post: https://david.pilato.fr/blog/2015-05-09-advanced-search-for-your-legacy-application/
Quelques commentaires et réponses:
Est-ce une manière correcte d'utiliser Logstash et Elasticsearch ?
On dit Elasticsearch et non ElasticSearch 
Oui. C'est correct.
Mais ce n'est pas ma méthode préférée. Je préfère de loin modifier l'application si cela est possible pour indexer directement dans elasticsearch dès qu'une entité métier est créée/mise à jour/supprimée dans la base de données.
Autre possibilité, écrire dans un système de messagerie asynchrone genre RabbitMQ, Kafka, Redis et faire consommer ça par un LS par exemple.
Mon projet de démo est ici:
Comment faire, pour appliquer des modifications sur les configurations de templates et/ou mapping de nos index, sans perdre de données ? Les modifications étant à appliquer sur une application qui reste utilisable lors des livraisons.
Vaste sujet (que ce soit avec Logstash ou pas d'ailleurs). Idéalement, quand tu as des changements de schéma de ton application, tu peux:
- Soit laisser elasticsearch créer les nouveaux champs automatiquement. Avec un nommage propre des champs, tu peux utiliser des index templates avec du dynamic mapping pour faire ça de façon propre.
- Soit créer un nouvel index systématiquement, réindexer toutes les données (soit par relecture de la base, soit en utilisant l'API reindex - mais je suppose inutile dans ce cas car les nouveaux champs n'existaient pas dans elasticsearch précédemment). Puis en utilisant un alias, switcher l'alias du vieil index vers le nouveau quand l'opération est finie. Puis détruire le vieil index.
- Soit un mix des deux, suivant le cas.
D'une manière générale, je conseille de mettre systématiquement un alias pour ton/tes index.
Si l'index est supprimé puis recréé, la réindexation des données via Java est-elle plus lourde et plus longue que via Logstash ?
En général, ce c'est pas la question essentielle. D'abord la lenteur vient en général de la lecture de la base de données source. Ensuite les données sont souvent bien complexes et sont dispersées dans plusieurs tables. Faire des joins dans tous les sens pour ramener un objet métier complexe est assez difficile à mon avis à faire avec Logstash (bien que le nouveau jdbc filter pourrait aider maintenant). Si tu as déjà des objets métiers capables d'être générés à partir d'une base de données, il est assez simple de les transformer en JSON et de les envoyer vers elasticsearch.
Je préfère donc, sauf cas simple, l'approche pure Java. Qui du coup, comme plus optimisée car exactement faite à façon sera peut-être plus rapide...
Enfin, si tu utilises Hibernate, sache que Hibernate Search propose une intégration assez sympa avec Elasticsearch.
En espérant que ça t'aide.
