ELAS­TIC RÉVÉLLE L'ES­SENCE DE VOS DON­NÉES

Alors que tout le monde parle de Big Da­ta, du be­soin de trou­ver « ce que les don­nées ont à dire », les so­lu­tions de bases de don­nées tra­di­tion­nelles n’ont pas pu ré­pondre à tous les scé­na­rios. Avec flexi­bi­li­té, évo­lu­ti­vi­té, ra­pi­di­té et sim­pli­ci­té, Elas­tic

L'Informaticien - - ELASTIC SEARCH - « Nous créons

Elas­ticSearch a ré­cem­ment dé­pas­sé les 40 mil­lions de té­lé­char­ge­ments, et conti­nue sur un rythme très sou­te­nu, com­pris gé­né­ra­le­ment entre 700 000 et 800 000 nou­veaux té­lé­char­ge­ments chaque mois, voire plus. For­cé­ment, de telles sta­tis­tiques mettent la puce à l’oreille… Si cer­taines tech­no­lo­gies n’ont pas ren­con­tré le suc­cès faute d’avoir su s’im­po­ser au bon en­droit au bon mo­ment, ce n’est ab­so­lu­ment pas le cas d’Elas­ticSearch. Et c’est aus­si ce qui fait sa force. Pe­tit pré­cis qui a son im­por­tance : Elas­tic, c’est l’en­tre­prise, Elas­ticSearch l’ou­til de re­cherche open source dans les don­nées et Ki­ba­na – is­su du ra­chat de l’en­tre­prise du même nom –, l’ou­til de vi­sua­li­sa­tion qui lui est as­so­cié. Pour l’anec­dote, il faut aus­si par exemple dis­tin­guer Do­cker, le pro­jet, de Do­cker, l’en­tre­prise ! Bref, il est im­por­tant de com­prendre cette dis­tinc­tion car ce­la peut être ra­pi­de­ment confus, d’au­tant que des offres tierces, comme Ama­zon Elas­ticsearch Ser­vice ou le Mi­cro­soft Azure cloud plu­gin for Elas­ticSearch, ont vu le jour ces der­niers mois. Les bases sont je­tées. Pour­quoi pen­ser qu’Elas­tic et ses ou­tils se­ront les grands vain­queurs des so­lu­tions de re­cherche ? C’est parce qu’au­cun autre pro­jet n’est aus­si avan­cé, pour com­men­cer. De plus, dès la créa­tion de l’en­tre­prise, en 2012, son créa­teur Shay Ban­non a tout fait pour rendre la tech­no­lo­gie la plus ac­ces­sible pos­sible. Ba­sé sur le pro­jet open source Lu­cene – comme d’autres –, Elas­ticSearch a pour vo­ca­tion de rendre toutes les don­nées libres. Pour ce­la, outre la sim­pli­fi­ca­tion de l’uti­li­sa­tion, l’ou­til peut ac­cé­der à toutes les don­nées, sous toutes les formes, mais il mise éga­le­ment et sur­tout sur la « sca­la­bi­li­té » – l’évo­lu­ti­vi­té en quelques sortes – en per­met­tant l’ajout fa­cile de noeuds sup­plé­men­taires avec une ap­proche API REST.

dE la rE­chErchE « full tExt » tEmps réEl

Elas­ticSearch vient donc en confron­ta­tion qua­si di­recte avec les sys­tèmes de re­cherche dans des bases de don­nées tra­di­tion­nelles. Dans ces der­nières, la don­née est sto­ckée en co­lonne sous forme d’in­dex ; un sys­tème qui at­teint vite ses li­mites et qui in­flue for­te­ment sur les per­for­mances d’un sys­tème en lui­même. Il est donc théo­ri­que­ment im­pos­sible de faire de la re­cherche sur toutes les co­lonnes et même si c’était le cas, l’autre li­mite se­rait de pou­voir le faire sur un clus­ter. D’au­tant plus qu’avec l’évo­lu­tion de la struc­ture des don­nées, il est de plus en plus com­plexe et coû­teux de faire évo­luer les sys­tèmes tra­di­tion­nels. C’est à ces pro­blé­ma­tiques que ré­pond prin­ci­pa­le­ment Elas­ticSearch : en pro­po­sant une in­dexa­tion des logs.

en fait un dic­tion­naire dans le­quel on ré­per­to­rie tous les termes dans ce champ. Par exemple lors­qu’il s’agit de mes­sages Twit­ter : tous les termes sont ré­par­tis dans le dic­tion­naire et sont in­dexés sous forme d’ID dans un do­cu­ment, là où une base de don­nées les in­dexe dans plu­sieurs co­lonnes. Elas­ticSearch consulte constam­ment le dic­tion­naire et gère la mé­moire en deux par­ties : cer­taines en mé­moire pour des rai­sons de cache, d’autres sur le disque » , ex­plique Ba­haal­dine Azar­mi, so­lu­tion ar­chi­tect chez Elas­tic. L’avan­tage de la so­lu­tion est aus­si qu’elle se met ra­pi­de­ment en oeuvre. Il peut suf­fire d’une per­sonne qui dé­bute un pro­jet, en col­la­bo­ra­tion avec d’autres qui tra­vaillent sur les don­nées des ap­pli­ca­tions, qui savent où sont les logs, etc.

« Les gens qui uti­lisent Elas­ticSearch sont plu­tôt dans la re­cherche » , pré­cise Ba­haal­dine Azar­mi. Ce­la per­met d’être as­sez souple dans l’uti­li­sa­tion. « Avec quelques noeuds, des clients gèrent dé­jà plu­sieurs Te­ra­oc­tets de don

nées » , ajoute- t- il pré­ci­sant que cer­tains dans la fi­nance uti­lisent Elas­ticSearch pour de la dé­tec­tion de fraude. Par na­ture l’ou­til est donc des­ti­né aux en­vi­ron­ne­ments avec de gros vo­lumes de don­nées. Et de plus en plus, des offres clouds prêtes à l’emploi se dé­voilent ; Elas­tic pro­pose la sienne (« as a ser­vice ») de­puis le ra­chat de Found. De plus, Elas­ticSearch est bien en­ten­du dé­ployable sur des ser­veurs phy­siques en cloud pri­vé/pu­blic/hy­bride, sur des in­fra­struc­tures vir­tua­li­sées et/ou re­po­sant sur Do­cker. « Nous tra­vaillons ac­tuel­le­ment sur une offre on- pre­mise qui per­met­tra de dé­ployer un clus­ter Elas­ticSearch avec les mé­ca­nismes in­hé­rents au Cloud. Elle de­vrait ar­ri­ver cou­rant 2016 » , ajoute

Ba­haal­dine Azar­mi.

Sto­ckage et vi­Sua­li­Sa­tion deS don­néeS

Alors que les ser­veurs « all flash » vont se ba­na­li­ser en 2016 (cf. ar­ticle en p. XX), Elas­ticSearch peut bien en­ten­du en ti­rer par­ti mais ce n’est pas tou­jours né­ces­saire. « Même dans le cas où une en­tre­prise sou­haite faire de l’ana­lyse de don­nées, nous conseillons sou­vent de di­vi­ser les don­nées en deux to­po­lo­gies : une zone froide et une zone chaude, avec des ser­veurs à confi­gu­ra­tions dif­fé­rentes. Sur la zone chaude, nous

pré­co­ni­sons ef­fec­ti­ve­ment du SSD » , ex­plique l’in­gé­nieur. À no­ter que les don­nées re­çues sont com­pres­sées sur disque avec un ra­tio qui peut va­rier entre 0,8 et 1,2 en moyenne ; donc le poids peut être soit ré­duit, soit aug­men­té. Tout ce­ci ne se­rait pas grand- chose sans la pos­si­bi­li­té de vi­sua­li­ser les don­nées. Elas­tic a une corde de plus à son arc : Ki­ba­na. La so­lu­tion de vi­sua­li­sa­tion se bor­nait jus­qu’à la v4.1 à af­fi­cher les don­nées. De­puis la 4.2, elle a su­bi un lif­ting avec par

exemple la pos­si­bi­li­té de créer des ap­pli­ca­tions as­so­ciées à tels ou tels jeux de don­nées, l’ajout de Ti­me­lion – com­po­si­teur de don­nées dans le temps – ou en­core « une sur­couche d’Elas­ticSearch qui per­met d’agré­ger des don­nées

dans une lo­gique « graph » pour faire ap­pa­raître des su­per-connec­teurs et les connec­ter entre eux ». Cette der­nière so­lu­tion de­vrait par exemple per­mettre d’ali­men­ter des mo­teurs de re­com­man­da­tions pour les sites e-com­merce. Ki­ba­na n’a tou­te­fois pas vo­ca­tion à rem­pla­cer un ou­til de Bu­si­ness In­tel­li­gence (Qlik, Ta­bleau ou autre), même s’il existe des API pour s’y connec­ter.

Le ta­bleau de bord de Ki­ba­na en ac­tion. Il re­pré­sente ici une vi­sua­li­sa­tion

(temps réel) des in­ci­dents de tous les types de vé­hi­cules à Pa­ris.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.