Informatique

Salut les loulous,

Quelqu’un a-t-il/elle déjà utilisé ElasticSearch ? https://www.elastic.co/fr/products/elasticsearch

Je travaille en ce moment sur une petite WebApp qui pourrait avoir à gérer un certain nombre d’éléments à la fois, et je me dis que ce doit être bien plus efficace/fiable qu’une petite API faite main…

Parmi les questions auxquelles je n'ai pas trouvé de réponse :

• Est-ce que les données peuvent être appelées comme n’importe quelle requête ? Ou bien faut-t-il nécessairement utiliser les méthodes Elastic (et donc l'installer sur l’app client comme une dépendance) ?
• Sous quel format doivent être stockées les infos servies ? BDD ?

Des retours ? Merci !

PS: @lisarael, je t'ai envoyé un p’tit mail, j‘sais pas si tu l’as vu ; hésite pas à me dire si réponse négative :D Mais sinon, pas de pression, surtout ! Danke !

Pour simplifier très fort, Elastic Search est une base de données, optimisée pour la redondance et la recherche textuelle. Tu peux l'interroger comme n'importe quelle db, avec sa propre syntaxe (et une lib client dédiée - ou un langage serveur qui fera l'interface entre ton client et elastic).
Pour le format, la spécialité d'Elastic, c'est de gérer du texte, des données relativement brutes, sans relations. À part pour un schéma très, très simple, tu utilises rarement Elastic tout seul.

PS: j'ai bien vu ton mail, là je passais vaguement en coup de vent ; j'essaie d'y répondre courant du week-end, là c'est un peu le bordel.

J’ai du mal à jauger si ça correspond à mon besoin ; j’ai l'impression que c'est vachement overkill quand même… Il y aura peut-être des milliers d’entrées, mais ça semble conçu pour de bien plus gros systèmes.

Merci pour ton avis.

(Ok pour le mail, merci ! Te presse pas, c'était juste pour vérifier qu’il était pas arrivé dans tes spams).

Pour compléter ce que dit lisarael, au delà de la librairie fournie il me semble qu'on peut tout bêtement interroger Elastic via cUrl.

Pour quelques milliers d'entrées ça me paraît un peu fou de se former là-dessus. Si tu n'as jamais fait d'indexation ça risque de te faire perdre un temps précieux, pour peu de gains au final. Autant fonctionner comme d'habitude, ou alors innover avec des technologies plus proches de tes besoins.

Yep, de fait, tu peux interroger Elastic via une API REST intégrée.
Mais à la base, Elastic, ça a été construit pour faire de la recherche et de l'analyse de logs, donc des données potentiellement monstrueuses (et ça fonctionne super bien).

De là à dire que c'est overkill pour une petite structure… oui et non. J'ai eu à faire il y a quelques années un site qui indexait des articles et publications scientifiques. Peu de données, mais un schéma très structuré, avec pas mal de relations, un truc solide et justifié. Le problème, c'est que même avec des bons index, la recherche textuelle dans ces documents n'était pas tip-top. C'était pas catastrophique, mais franchement, ça ramait un peu.
Du coup, autant pour le fun que pour l'expérience, j'ai construit deux shard elastic au-dessus de ces données, que j'ai utilisé pour la recherche. Les perfs n'avaient plus rien à voir.

Après... bah ouais, c'est un peu overkill. Mais si t'as déjà creusé un peu tout ce que tu voulais et que tu veux te pencher dessus, c'est chouette. Ceci dit, si tu veux de la perf, tu peux aussi jouer avec Redis, y a moyen de bien rigoler aussi.
Je pense qu'un projet doit toujours être un prétexte pour découvrir un nouvel outil ou méthode, sortir de sa zone de confort. Faut juste éviter de trop en faire : garder une base solide sur laquelle tu vas pouvoir te reposer (et donc éviter de te lancer sur un socle entièrement nouveau, par exemple).

Ah ouais, je pensais pas que c’était aussi "gros" comme bestiau quand on me l’a présenté. Effectivement, je suis d’accord pour sortir de ma zone de confort (c'est même totalement ce que je fais, parce que je ne suis absolument pas un developpeur back, ni même d’app…), mais là c’est peut-être beaucoup.

En fait, j'ai du mal à définir quel outil utiliser, parce que je ne sais pas encore comment traiter les données. Mes seules « vraies » expériences de back remontant à plusieurs années en PHP, j'ai tout naturellement pensé "BDD", avec un chouïa de relationnel (il y a trois tables : les spots, les teams, et les photos, tout étant lié aux spots). Mais je me suis dit aussi que je pouvais peut-être réfléchir ça façon « cms flat files », avec un dossier par team, contenant un dossier par spot, lui-même contenant un fichier pour les infos du spot (yaml ou autre) et les photos en relation ; mais là, c'est sur la flexibilité et les perfs que je me suis interrogé…

Je vais voir Redis, ne serait-ce que pour la science.

Merci pour vos avis !

J'ai répondu à ton mail.

Je vais essayer d'éviter de diluer plus l'information en répondant d'autres trucs ici aussi, ceci dit, je veux réagir sur un truc : les flat file, c'est bien pour un blog (et encore), mais niveau perf, c'est bof. Ça se prête bien à un CMS pour un site avec une structure simple, mais si tu veux tenir la charge, le truc doit construire une représentation des données en mémoire pour éviter trop d'accès disque gourmands et coûteux… et donc lorgner du côté de Redis, par exemple.
Mais le flat file, pour moi, c'est pour des trucs relativement léger, où, sur une page, tu ne vas pas avoir besoin d'ouvrir plus de deux ou trois fichiers, grand max.

Et concernant Elastic Search, c'est pas "gros", c'est littéralement monstrueux. C'est construit pour encaisser, traiter et chercher. J'veux absolument pas que ça ait l'air méchant (parce que tu sais que je ne le suis pas), mais Elastic Search fait partie de ces outils dont tu as besoin quand tu sais que tu en as besoin. Le genre d'outils sur lesquels tu te penches quand ce que tu as déjà n'es plus capable de suivre, ou que tu sais que tu vas avoir à gérer un truc vraiment méchant.
Dans ton contexte, tu gagneras beaucoup plus d'XP utile à apprendre Redis qu'Elastic, par exemple.

Ouep, c’est bien ce que j'ai conclu pour le flat file, et pour Elastic. :D

Je plussoie de ouf lisarael. J'aurais bien ajouté Mongodb dans les potentielles solutions (coté stockage). Pour avoir un peu joué avec sur un projet avec Drupal 8 (donc PHP, désolé les mecs :D ), c'est assez sympa même si tout n'est pas parfait (genre la recherche fulltext un peu limitée amha). Mais sur de l'indexation (eg: id), ça marche bien et c'est rapide…un bout d'api par dessus, c'pas compliqué et long à faire).