L'équipe d'ingénieurs de Voxpopme a tenu sa promesse d'améliorer les performances de 1 000 % lors du passage d'Amazon Elasticsearch Search à Elastic Cloud.

Voxpopme est l'une des premières plateformes d'études en vidéo au monde. Créée en 2013, l'entreprise a été fondée sur le principe simple que la vidéo est le moyen le plus puissant de permettre à des centaines et des milliers de personnes de s'exprimer en même temps. Notre logiciel unique ingère les vidéos enregistrées par les consommateurs et le contenu de longue durée (par exemple, les groupes de discussion) auprès de divers partenaires de sondages, et fournit des données commerciales précieuses sous la forme de graphes, de thèmes à parcourir et de bandes démo personnalisables. Depuis notre lancement, nous avons passé quatre&nbsp;ans à optimiser et à automatiser les informations que l'on peut obtenir grâce à la vidéo, afin d'éliminer les obstacles qui empêchent une connexion véritable entre les marques et les clients. Pour améliorer l'expérience des clients, nous utilisons les derniers outils de NLP (Natural Language Processing, traitement automatique du langage) d'IBM&nbsp;Watson pour identifier et rassembler l'opinion des participants aux sondages. Nous avons également un partenariat exclusif avec Affectiva pour analyser les expressions faciales émotionnelles. En 2017, nous avons ajouté Elasticsearch à notre arsenal d'outils pour offrir la meilleure expérience possible à nos clients.
<h2>Au-delà de notre infrastructure existante</h2>Chez Voxpopme, notre pile technologique a connu des changements importants au cours des douze derniers mois. En 2017, notre plateforme a traité un demi-million de sondages vidéo&nbsp;: autant que l'ensemble des quatre&nbsp;années précédentes. Et ce chiffre devrait doubler en 2018. Nous avons été confrontés à des problèmes de montée en charge. Ce problème était un bon signe, mais un problème tout de même.
Les problèmes provenaient de notre système existant, qui se composait d'une application PHP monolithique, qui interagissait avec un certain nombre de bases de données différentes pour les fonctionnalités de base. À l'origine, la logique sur laquelle reposait cette séparation des données faisait sens&nbsp;:
<ul>
	<li>La plupart de nos données étaient stockées dans une base de données MySQL. Cela comprenait les utilisateurs, les réponses vidéo individuelles, et autres données similaires – des données relationnelles structurées, reliées entre elles par des clés étrangères, et qui étaient créées, lues, mises à jour et supprimées à l'aide d'une API RESTful&nbsp;;</li>
	<li>Les données des clients étaient stockées dans un cluster MongoDB, que nous avions accepté tel qu'il nous avait été fourni. Cela permettait aux utilisateurs d'ajouter des balises, des annotations et des filtres à leurs vidéos selon leur propre terminologie&nbsp;;</li>
	<li>Nous stockions les transcriptions des vidéos de nos participants dans un petit cluster Elasticsearch, que nous utilisions pour les recherches en texte intégral.</li>
</ul>Cette approche a très bien fonctionné pendant longtemps, mais il y avait un problème évident.
<h2>La puissance de calcul n'est ni gratuite ni infinie</h2>Une recherche sur notre plateforme pouvait être extrêmement simple ou très complexe. Dans les instances plus simples, nous laissions les utilisateurs rechercher par clé principale d'une réponse vidéo. C'est facile, et il suffit d'une simple requête dans la base de données MySQL indexée.
Mais comment faire pour les requêtes dans lesquelles un utilisateur veut filtrer à l'aide d'un entier indexé, certaines de ses données en texte libre, et limiter les résultats à tous les participants mentionnant un sujet en particulier&nbsp;? Par exemple&nbsp;:
Trouver tous les enregistrements dont la date de réponse est comprise entre le premier et le dernier jour du mois de juin, lorsque les revenus du ménage du participant sont compris entre 100&nbsp;000&nbsp;$ et 125&nbsp;000&nbsp;$, et qui comprennent l'expression "trop cher".
Voici l'approche que nous avions adoptée&nbsp;:
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0c5ee64441b10c95/5c3069bec05f480270a743a2/voxpopme-legacy-process.png" data-sys-asset-uid="blt0c5ee64441b10c95" alt="voxpopme-legacy-process.png" style="display: block; margin: auto;">
Dans notre système existant, les opérations suivantes devaient se produire&nbsp;:
<ul>
	<li>Une recherche MySQL trouvait tous les enregistrements compris dans la plage de dates&nbsp;;</li>
	<li>Une recherche MongoDB trouvait tous les enregistrements compris dans la plage de revenus (les revenus ne sont qu'un exemple&nbsp;; les clients stockent souvent des informations complètement arbitraires chez nous)&nbsp;;</li>
	<li>Une recherche Elasticsearch trouvait tous les enregistrements dont la transcription contenait l'expression correspondante&nbsp;;</li>
	<li>Une intersection des ID des trois ensembles d'enregistrements était calculée&nbsp;;</li>
	<li>Un nouvel ensemble de recherches MySQL et MongoDB était exécuté pour obtenir l'ensemble de données complet pour chaque enregistrement&nbsp;;</li>
	<li>Les enregistrements étaient triés et paginés.</li>
</ul>Un ensemble de critères de recherche simples pouvait facilement nécessiter cinq&nbsp;recherches distinctes dans des bases de données. Au début, cette opération prenait moins d'une seconde. Cependant, avec cinq&nbsp;ans de données et le fait que le PHP fonctionne avec un seul thread, les recherches dans la base de données devaient être effectuées l'une après l'autre et pouvaient facilement prendre 30&nbsp;secondes.
Ce modèle nous a permis de nous installer rapidement sur le marché et il nous a bien servi pendant de nombreuses années, mais sa montée en charge n'était pas adaptée. Lorsque nous avons remarqué que l'expérience de nos utilisateurs commençait à se dégrader, nous avons décidé qu'il était temps de réécrire le mécanisme de recherche.
Nous avions déjà un peu d'expérience avec Elasticsearch dans notre pile existante. Nous avons donc contacté un responsable de ventes Elastic pour parler des problèmes auxquels nous étions confrontés pour réaliser des recherches complexes sur une plage de données stockées dans plusieurs endroits. Il était essentiel de trouver la bonne solution&nbsp;: notre produit a pour but d'afficher et d'exécuter des calculs sur nos données rapidement et efficacement. Les goulots d'étranglement lors de la récupération des données étaient inacceptables.
Nous avons également envisagé d'agrandir notre cluster MongoDB existant, mais après une courte consultation téléphonique avec Elastic, l'équipe de développement a décidé qu'Elasticsearch était la seule solution nous permettant de stocker, rechercher et manipuler facilement des données (c'est-à-dire, les agrégations).
<h2>Nos premières impressions</h2>Le cluster Elasticsearch que nous avions utilisé pour la recherche de texte était un cluster de version&nbsp;1.5 de Compose.io. Comme nous avons fortement investi dans AWS pour le reste de notre infrastructure, nous avons d'abord choisi Amazon Elasticsearch&nbsp;Service avec un cluster de version&nbsp;5.x.
Notre nouveau modèle impliquait de maintenir toutes les données disparates d'un enregistrement dans un seul document Elasticsearch, en utilisant des valeurs imbriquées et des clés connues pour les données sous forme libre plus compliquées de nos clients. Une seule recherche Elasticsearch permettait alors de gérer n'importe quelle recherche utilisateur.
Sous une semaine, nous avions une démonstration de faisabilité basique avec quelques milliers de documents. Nos premières impressions de l'exécution de recherches avec Kibana étaient suffisantes et nous avons décidé de passer à une réécriture totale de notre mécanisme de recherche en backend.
Notre nouvelle approche était la suivante&nbsp;:
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt5d43030f1ce3e792/5c3069bab7017c456eff0a23/voxpopme-new-process.png" data-sys-asset-uid="blt5d43030f1ce3e792" alt="voxpopme-new-process.png" style="display: block; margin: auto;">
(Pour le moment, nos bases de données existantes ne changeaient pas, mais l'introduction de notre nouveau cluster Elasticsearch pour les recherches complexes nous a permis de prévoir de supprimer complètement MongoDB de notre pile)
Avec notre nouvelle pile, nous avons continué à écrire des données dans MySQL et MongoDB, comme auparavant. Toutefois, chaque écriture déclenchait également un événement qui recueillait et aplatissait toutes nos données provenant des diverses sources dans un seul document JSON inséré dans Elasticsearch.
En backend, nous avons formulé un nouveau mécanisme de recherche pour construire des recherches Elasticsearch complexes à partir des recherches existantes de nos utilisateurs et nous avons complètement supprimé le code existant qui envoyait une demande à MySQL et MongoDB. En interrogeant un seul cluster Elasticsearch, nous pouvions obtenir les mêmes données en une fraction du temps nécessaire auparavant.
La structure de nos documents Elasticsearch nous a permis d'obtenir d'autres avantages. Notre API affiche des documents JSON. Nous avons donc pu structurer nos documents Elasticsearch de manière à ce qu'ils correspondent exactement à notre sortie API existante, pour gagner quelques autres secondes qui étaient préalablement requises pour combiner et restructurer les données provenant de MySQL et MongoDB.
Nous avons pu annoncer une augmentation de performance préliminaire de 1&nbsp;000&nbsp;% pour les parties principales de notre plateforme aux différents acteurs du secteur.
<h2>Ce n'est pas le fournisseur que vous recherchez</h2>Après avoir promis une augmentation de performance de 1&nbsp;000&nbsp;% à tout le monde, l'étape suivante consistait à indexer toutes nos données et espérer que les chiffres résistent à la pression.
Avec toutes nos données indexées, malheureusement, le cluster AWS ne s'en est pas bien sorti.
Si nous avions simplement indexé les données une fois pour les rechercher plusieurs fois, il en aurait peut-être été autrement. Mais notre modèle s'appuyait sur le fait de combiner et de réindexer les données chaque fois qu'elles étaient mises à jour dans MySQL ou MongoDB. Cela pouvait correspondre à des milliers de fois pendant la période pendant laquelle il était plus probable que la recherche ait lieu.
Nous avons découvert que la performance en pâtissait, et les temps de recherche atteignaient parfois plusieurs secondes. Cela avait pour conséquence un blocage potentiel de notre application PHP, ce qui pouvait laisser des connexions MySQL ouvertes et, par un terrible effet de domino, c'est toute notre pile qui pouvait cesser de répondre.
Nous avons rencontré ces problèmes lorsque <a href="/fr/elasticon">Elastic{ON}</a> est arrivé à Londres, et nous avons profité de cette occasion pour parler avec un représentant Elastic sur le stand AMA des tailles de cluster et des problèmes auxquels nous étions confrontés. Nous avons mentionné que nos meilleurs délais de recherche étaient d'environ 40&nbsp;ms. Le représentant nous a conseillé d'utiliser le service <a href="/fr/cloud">Elastic&nbsp;Cloud</a> d'Elastic au lieu d'AWS pour atteindre des temps de réponse se rapprochant de 1&nbsp;ms avec les paramètres par défaut.
La disponibilité de <a href="/fr/products/x-pack">Fonctionnalités de la Suite Elastic</a> (initialement regroupées dans X-Pack) sur Elastic Cloud représentait un avantage considérable pour nous, car nous n'avions que des systèmes de logging et de graphes limités à l'époque. Comme X-Pack est absent de l'offre Elasticsearch d'AWS, nous avons décidé de déployer un cluster Elastic Cloud pour effectuer quelques tests comparatifs. Si les performances de ce cluster étaient au moins équivalentes à celles du cluster AWS, nous savions que nous l'adopterions pour les autres avantages qu'il proposait.
L'interface utilisateur d'Elastic Cloud était très épurée et facile à utiliser. Pendant l'indexation, nous avions besoin d'augmenter l'échelle, car nous avions ajouté plus de travailleurs pour traiter les données. Nous avons été impressionnés par la simplicité avec laquelle nous pouvions gérer le cluster. Il n'y a qu'à faire glisser un curseur vers la droite ou vers la gauche et à cliquer sur "Update" (Mise à jour).
Une fois les données indexées dans le nouveau cluster, nous avons pu exécuter des recherches complexes en seulement 2&nbsp;ms, avec très peu de blocages (depuis, nous avons renforcé l'optimisation du système pour éliminer complètement les blocages). Même si l'utilisateur final ne perçoit généralement pas un délai supplémentaire de quelques millisecondes, les techniciens parmi nous étaient ravis de voir que la latence était réduite à 5&nbsp;% de sa valeur précédente.
<h2>Tirer le meilleur de nos données</h2>Nous ne voulions pas nous contenter de la vieille école et utiliser Elasticsearch comme moteur de recherche pour les utilisateurs finaux. Beaucoup des histoires de réussite que nous avions entendues sur la technologie semblaient se concentrer sur les logs, et nous avons rapidement découvert que nous ne faisions pas exception à la règle.
Nous avons configuré un cluster de logging séparé pour ingérer les logs de nos pods Kubernetes et avons désormais une meilleure visibilité sur l'état de nos serveurs, ce qui n'était pas possible auparavant, et nous pouvons réagir plus vite en cas de problème.
Nous avons également pu proposer quelque chose de similaire aux utilisateurs de notre plateforme. Grâce aux agrégations, nous avons pu fournir à nos utilisateurs une méthode de visualisation graphique des données. Cela était un excellent ajout à notre plateforme, et ce n'était qu'un effet secondaire rendu possible par la présence de nos données dans Elasticsearch.
Ces derniers mois, nous avons affiné et amélioré nos processus, et nous observons maintenant une meilleure performance de nos clusters Elasticsearch chaque semaine. Ces augmentations de la performance comprennent des gains de mémoire importants en déplaçant les champs nécessitant les fielddata de notre cluster principal dans un cluster plus petit, auquel on accède moins souvent (notre pression mémoire de référence est désormais de 25&nbsp;%, contre 75&nbsp;% auparavant). Nous avons également optimisé notre code pour écrire les nouvelles données en vrac, plutôt qu'à la demande, ce qui a rendu le cluster beaucoup plus réactif pendant les heures de pointe.
À l'avenir, nous prévoyons d'utiliser largement Elasticsearch pour analyser les données internes que nous détenons en tant qu'entreprise. Comme cette méthode a fait ses preuves au cœur de notre produit destiné aux utilisateurs finaux, nous avons déjà commencé à faire des expériences en stockant nos propres données dans les index Elasticsearch, et nous comptons utiliser la Suite Elastic pour obtenir des informations sur l'efficacité opérationnelle de notre entreprise.
<hr> <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt323dbcb4ab31a0ca/5c3069b6c599e169662411e2/voxpome-david.jpeg" data-sys-asset-uid="blt323dbcb4ab31a0ca" alt="voxpome-david.jpeg" width="100" height="105" style="background-color: initial; width: 100px; height: 105px; float: left; margin: 0px; padding-right:10px;">David&nbsp;Maidment est ingénieur logiciel en chef chez Voxpopme. Il se consacre à assurer la pérennité du codebase de la plateforme au cours de la croissance exponentielle de l'entreprise. 
 
 
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt4eaf745e2ec228f8/5c3069b225a401fc6fe4f545/voxpopme-andy.jpg" data-sys-asset-uid="blt4eaf745e2ec228f8" alt="voxpopme-andy.jpg" width="100" height="101" style="background-color: initial; width: 100px; height: 101px; float: left; margin: 0px; padding-right:10px;">Andy&nbsp;Barraclough est un cofondateur et Directeur technique de Voxpopme. Il se concentre sur la gestion de l'équipe technique et la coordination de la vision de l'entreprise sur le long terme.

voxpopme-fullbleed.png

voxpopme-small.png

Leveraging Elasticsearch for a 1,000% performance boost

Exploiter Elasticsearch pour améliorer les performances de 1 000 %

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

David Maidment

By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Communication Preferences - ONLY for /communication-preferences

En confirmant votre envoi, vous reconnaissez que vous avez lu et que vous acceptez nos <a href="/fr/legal/elastic-cloud-account-terms" target="_self">Conditions générales d'utilisation</a>, et vous acceptez de recevoir les <a href="/fr/legal/privacy-statement#how-we-use-the-information" target="_self">types de notification sélectionnés</a> à l'adresse que vous avez fournie plus haut. Pour en savoir plus ou pour revenir sur votre décision (possible à tout moment), consultez la <a href="/fr/legal/privacy-statement/" target="_self">Déclaration de confidentialité d'Elastic</a>.

By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.By submitting this form, I agree to Elastic sharing my contact information with Google Cloud. I also agree to Elastic giving my information to the vendor for the purpose of shipping my food package.

GDPR Text + Google Cloud

By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Serverless GDPR Text

En confirmant votre envoi, vous reconnaissez que vous avez lu et que vous acceptez nos <a href="/fr/legal/serverless-preview-terms" target="_self">Conditions générales d'utilisation</a>, et vous permettez à Elastic de <a href="/fr/legal/privacy-statement#how-we-use-the-information" target="_self">vous contacter</a> à propos de produits et services similaires en utilisant les informations que vous avez fournies plus haut. Pour en savoir plus ou pour revenir sur votre décision (possible à tout moment), consultez la <a href="/fr/legal/privacy-statement/" target="_self">Déclaration de confidentialité d'Elastic</a>.

By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.

Cloud Trial GDPR Text

En envoyant votre demande d'inscription, vous acceptez les <a href="/fr/agreements/global/cloud-services-monthly" rel="nofollow">conditions générales d'utilisation d'Elastic Cloud</a>. Vos données personnelles seront traitées conformément à la <a href="/fr/legal/privacy-statement">déclaration de confidentialité d'Elastic</a>.

By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Newsletter GDPR Text

En confirmant votre envoi, vous reconnaissez que vous avez lu et que vous acceptez nos <a href="/fr/legal/terms-of-use" target="_self">Conditions générales d'utilisation</a>, et vous permettez à Elastic de <a href="/fr/legal/privacy-statement#how-we-use-the-information" target="_self">vous contacter</a> à propos de produits et services similaires en utilisant les informations que vous avez fournies plus haut. Pour en savoir plus ou pour revenir sur votre décision (possible à tout moment), consultez la <a href="/fr/legal/privacy-statement/" target="_self">Déclaration de confidentialité d'Elastic</a>.

Explore similar demos

Overview

You'll also receive an email with related content.

You'll also receive an email with related content

Nous vous enverrons plus de contenu susceptible de vous intéresser.

Speakers

Close

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

Le contenu de cette page n'est pas disponible dans la langue sélectionnée. Chez Elastic, nous mettons tout en œuvre pour vous proposer du contenu dans différentes langues. En attendant, nous vous remercions de votre patience !

See more insights

Articles by

Author

Learn more

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Load More

Share on LinkedIn

Follow us on LinkedIn

Search Integrations

All Solutions

Video for

Follow us on Twitter

See when this webinar starts in my time zone

Voir à quelle heure débute le webinar dans mon fuseau horaire

Register to Watch

Register now

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

Si vous ne pouvez pas vous libérer le jour J, inscrivez-vous et nous vous enverrons l'enregistrement. Vous recevrez aussi un e-mail contenant des ressources connexes.

Small image for

On-demand webinar

Featured webinar

Register to Attend

Share on Facebook

Reset all

Upcoming webinar

View more posts

Print

Hosted by

Sign In to Attend

View next

Follow us on Facebook

Share

Highlights

Read less

Thank you for registering. We will send you a confirmation email soon.

Nous vous remercions de votre inscription. Vous allez recevoir un e-mail de confirmation.

Author

Articles by David Maidment

Exploiter Elasticsearch pour améliorer les performances de 1 000 %

Sign up for Elastic Cloud free trial