parlons elasticsearch - digital aquitaine ... 2017/10/04 آ  parlons elasticsearch avec groupe...

PARLONS Elasticsearch

avec

Groupe CARTÉGIE

18 octobre 2017

Vincent BOUGON

Directeur de Projets WEB

vincent.bougon@cartegie.com

Stéphane LIÉNÉRÉ

Directeur Technique et

Innovation

stephane.lienere@cartegie.com

mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com

UNE NOUVELLE VISION DE LA DATA

Les stratégies

d’entreprises se

réorganisent autour de

la DATA

Les stratégies d’entreprises sont de plus en plus « data

driven » car la Data est aujourd’hui devenue moteur

d’innovation et de nouveaux business models.

La fiabilité, l’agilité et la pertinence des données s’affirment

encore plus comme socle fondateur de toute stratégie.

Fonction support

Ressource stratégique

2010

201

7 Un changement de regard de l’entreprise

s’opère, les ETI, et grands groupes

réorganisent l’entreprise et les fonctions clés

autour de la DATA.

DATA

Le capital Data BtoB & BtoC le plus riche du marché

10,5 millions de profils entreprises

45 millions de profils consommateurs

Une fiabilité

reconnue sur le

marché grâce à une expertise en traitement et

enrichissement de la donnée (data

quality / data management)

30 ans d’historique Une base de connaissances et de

contacts sans équivalence

Des partenaires

stratégiques

exclusifs pour de la donnée à haute valeur

ajoutée

Elasticsearch Une nécessité

Constat et Virage technologique

• Collecte de données de navigation et de données non structurées

• Volume exponentiel

• Nécessité de faire cohabiter de l’information structurées et non structurées

• Ouverture des données directement vers nos clients : Mise à disposition d’API et

d’applications SaaS nécessitant des temps de réponses performants

Virage technologique nécessaire

• Le numérique (web, réseaux sociaux, objets connectés, presse économique digitale…)

génère des millions de nouvelles informations qui enrichissent considérablement les

informations historiques

Constat

Besoin d’appréhender les solutions

NoSQL

Choix d’Elasticsearch

• Rapidité d’interrogation des données quel que soit le volume : interrogation

unitaire (Full-text) ou agrégation

• Une solution éprouvée et une communauté importante

• Une scalabilité facilement mise en place, évolutive et aisé à maintenir

• Des interconnexions simples et efficaces pour construire des index provenant

de SGBD SQL

• Un moteur de recherche géographique extrêmement performant

• Un écosystème dense : Kibana / Logstash / Shield (sécurité) / Marvel

(supervision)

Elasticsearch en détail

SGBDR Elasticsearch

Database Index

Table Type

Row Document

Column Field

Elasticsearch : Moteur de recherche et d’agrégations orienté documents

• Un document utilise une structure de format JSON

 Série de Clé/Valeur

• Il accepte des types de champs complexes

 Objet

 Tableau

 Geo_point, geo_shape

 ipV4

 Multi-champs

 Parent/child

• Chaque document peut avoir une structure différentes => destructurés

{

"civilité": "Monsieur",

"prenom": "stéphane",

"nom": "Liénéré",

"Fonction": "Directeur

technique"

"location": {

"lon": -0.5825,

"lat": 44.87305

}

}

Elasticsearch

Cluster ES

Nœud => Instance Elasticsearch

Shard => partie d’Index

Architecture distribuée: (cluster, nœud (master), nœud (data), shard primaire, shard

répliqué)

Cluster ES

Nœud ES

Shard

0 (P)

Shard

1 (P)

Shard

1

(R1)

Shard

0

(R1)

Index

Cluster ES

Nœud ES

Shard

0 (P) Shard 1

(P)

Index

Cluster ES

Nœud 1 (master) Nœud 2

Shard

0 (P)

Shard

0 (R)

Shard

1 (P)

Shard

1 (R)

Index

Shard Principal

Shard secondaire

Index ES

Noeud ES

Document

Notre Architecture

• 6 Nœuds Data

• 2 Nœuds Client

• 2 Nœuds Master

• 27 index

• 194 shards

• 242 millions de

documents

• 540 GB de données

Exemple 1: Structure avec un seul document par entreprise

Avantages

• Avec une seule requête, on récupère

l’ensemble des données d’une

entreprise

• Possibilité de faire des requêtes

complexes sur les sous-documents

Inconvénients

• La mise à jour d’un champ nécessite

la ré-indexation de tout le document

• Modèle permettant plutôt de

répondre aux usages orientés

Entreprises

 problématique sur des demandes

d’extraction d’un contact

D o c E

n tr

e p ri s e

{

« siret »,

« siren »,

« raison_sociale »,

« dept »,

« libelle_dept »,

….

« contacts » : [

{

« nom »,

« prenom »,

« fonction »,

« email »

},

{ …. }

],

« bilan » : {

« date »,

« bicn »,

…..

}

}

Entreprise

Contacts

Bilan

Exemple 2: Structure avec un document par source

Doit être caller en fonction du besoin

Avantages

• Cycle de vie des différents

documents faciles à gérer

• Adapté aux différents usages de

recherches unitaires, que ce soit

pour les Entreprises, Contacts ou

Bilans

Inconvénients

• Multiplication des requêtes pour avoir

une information complète

• Impact sur les temps de réponse

D o c E

n tr

e p ri s e

{

« siret »,

« siren »,

« raison_sociale »,

« dept »,

« libelle_dept »,

….

}

Entreprise

D o c C

o n ta

c t

{

« siret »,

« nom »,

« prenom »,

« fonction »,

« email »

….

}

Contacts

D o c B

ila n

{

« siren »,

« date »,

« bicn »,

…..

}

Bilan

Exemple 3: Structure avec document contact séparé

Avantages

• Avec une seule requête, on récupère

l’ensemble des données d’une

entreprise

 Requête via lien parent/enfant

• Cycle de vie des différents

documents reste simple

• Modèle permettant de répondre aux

usages orientés Entreprises ou

Contacts

Inconvénients

• Requêtes moins performantes lors de

l’utilisation du lien parent/enfant

• Elasticsearch met en mémoire la

table de liens

D o c E

n tr

e p ri s e

{

« siret »,

« siren »,

« raison_sociale »,

« dept »,

« libelle_dept »,

….

« bilan » : {

« date »,

« bicn »,

…..

}

}

Entreprise

Bilan

D o c C

o n ta

c t

{

« nom »,

« prenom »,

« fonction »,

« email »

….

}

Contacts

parent=1234

Choix structure document

En fait, le choix de la structure du

document JSON ne doit pas être défini en

fonction de la structure des données,

mais en fonction de l’utilisation métier

attendue

• Suivant le type de recherche

• Suivant le type d’agrégations/statistiques

• Suivant les informations qui devront être

retournées/affichées

• Suivant le cycle de vie des éléments

Ne pas hésiter à dupliquer la donnée

suivant les différents usages métier

 Trouver un équilibre entre performance et

contrainte de mise à jo