ELASTICSEARCH @SYNTHESIO

ELASTICSEARCH @SYNTHESIO
FRED DE VILLAMIL
BACKGROUND
• FRED DE VILLAMIL, 37 ANS, HEAD OF INFRASTRUCTURE
@SYNTHESIO
• LINUX / (FREE)BSD DEPUIS 1996
• CONTRIBUTEUR OPEN SOURCE DEPUIS 1998
• ELASTICSEARCH EN PRODUCTION DEPUIS LA 0.17.6
SYNTHESIO
• Leader du “social listening”
• Crawl le Web, enrichit les données avec de
l’analyse de sentiment et démographique
• Bureaux à Paris, Londres, New York et Singapour
ELASTICSEARCH CHEZ SYNTHESIO
• 3 clusters, 116 serveurs, 271 TB de stockage, 7,25TB
de RAM
• 60 milliards de documents indexés, 160TB de
données
• 1,5 milliards de nouveaux documents par mois
• Utilisé pour agréger plusieurs clusters SQL de
dizaines de TB
PHASE 1 : OFFLOADER LES MYSQL
• 1 index global, 512 shards, 5 milliard de documents
• 1000 documents / seconde en continu
• 47 serveurs en RAID0, ES 1.3.2 puis 1.3.9
• Capacité : 40TB, dont, 24TB utilisés, 2.62 TB RAM
TYPOLOGIE DU CLUSTER
• 2 QUERY NODES : VM, 8GB DE RAM
• 3 MASTER NODES : VM, 8GB DE RAM
• 42 DATA NODE : PHYSIQUE, 1TB SSD, RAID0, 64GB DE
RAM
MODÈLE DE DONNÉES
•
ROUTAGE PAR MOIS
•
INDEXATION DES DONNÉES,
PUIS DES DASHBOARDS EN
NESTED
{ "document": {
"dashboards": {
"dashboard_id": 1,
"dashboard_id": 2
}
}
}
PROBLÈMES
• DES SHARDS DE 500 À 900GB (!!!)
• IMPOSSIBLE DE MODIFIER LE MAPPING
• IMPOSSIBLE DE SUPPRIMER LES DONNÉES PÉRIMÉES SANS RÉINDEXER
TOUT UN MOIS
• 20% DE DOCUMENTS DELETED IMPOSSIBLES À SUPPRIMER
• PROBLÈMES DE GARBAGE COLLECTOR, CLUSTER QUI FLAP EN
PERMANENCE
• 3 JOURS POUR REDÉMARRER LE CLUSTER QUAND TOUT VA BIEN
LUCENE
• SEGMENTS : FICHIERS IMMUTABLES ÉCRITS PAR LUCENE
• PAS DE RÉELLE SUPPRESSION : FLAG DELETED
• MERGES POUR FAIRE UN SEUL FICHIER : BESOIN DE 2 *
L’ESPACE DISQUE
• OPTIMISATION : DELETE + MERGE
MERGE ET DELETE
SOLUTIONS
• PASSAGE DE MMAPFS À NIOFS
• PASSAGE DE CMS À G1GC
• MISE EN PLACE D’EXPIRE SUR LE FIELDDATA CACHE
MMAPFS VS NIOFS
• MMAPFS : MAPPING DES FICHIERS LUCÈNE SUR DES PAGES
MMAP.
• NIOFS : SHARED LOCK SUR LES FICHIERS + UTILISATION DU
CACHE DU FS
TUNING G1GC
JAVA_OPTS="$JAVA_OPTS -XX:MAXGCPAUSEMILLIS=200"
JAVA_OPTS="$JAVA_OPTS -XX:+USEG1GC "
JAVA_OPTS="$JAVA_OPTS XX:GCPAUSEINTERVALMILLIS=1000"
JAVA_OPTS="$JAVA_OPTS XX:INITIATINGHEAPOCCUPANCYPERCENT=35"
TUNING FIELD DATA
FIELDDATA:
BREAKER:
LIMIT:
80%
CACHE:
SIZE:
30%
EXPIRE: 1M
EXPIRE DE CACHE
• FORMELLEMENT DÉCONSEILLÉ PAR LA DOC ES
• FORCE LE VIDAGE DES CACHES INTERNES À ES
• OVERLAP DU GARBAGE COLLECTOR
• PROBLÈME : PERTE DE PERFORMANCES
PHASE 2 : PLUS VITE, PLUS HAUT, PLUS FORT
• 8200 indexes, 10 milliards de documents
• 15000 documents / seconde en continu
• 70 serveurs, es 1.7.5
• Capacité : 60TB, dont, 50TB utilisés, 3,75 TB RAM
TYPOLOGIE DES CLUSTERS
• 2 CLUSTERS ISO
• 2 QUERY NODES : VM, 64GB DE RAM
• 3 MASTER NODES : PHYSIQUE, 64GB DE RAM
• 30 DATA NODE : PHYSIQUE, 1TB SSD, RAID0, 64GB
DE RAM
NOUVELLE ORIENTATION PRODUIT
• 1 INDICE PAR DASHBOARD, 1 SHARD / 5 MILLIONS DE DOCS
• VERSION DU MAPPING
• PLUSIEURS VERSIONS D’UN MÊME MAPPING EN PARALLÈLE
• SWITCH DE MAPPING SANS INTERRUPTION
• BALDUR…
BALDUR
PROBLÈMES
• DES MILLIERS DE SEGMENTS LUCÈNE SUR CHAQUE
MACHINE
• 75% DE LA HEAP UTILISÉE POUR GÉRER LES SEGMENTS
• ON CRÉE PLUS DE SEGMENTS QU’ON ARRIVE À MERGER
• REDÉMARRAGE / MISE À JOUR DE LA CONFIGURATION
FRÉQUENTS ET COMPLIQUÉS
SOLUTIONS
• OPTIMISATION EN CONTINU QUAND DELETED
•
NETTOYAGE EN CONTINU DES VIEUX INDEXES
•
RACK AWARENESS : REDÉMARRAGE D’UN CLUSTER DE
NOEUDS EN
30 MINUTES
60
RACK AWARENESS
BLACKHOLE
• 70 SERVEURS, 36 INDEXES, 50 MILLIARDS DE DOCUMENTS,
120TB DE DONNÉES, 160TB DE CAPACITÉ
•
REQUÊTES TRANSVERSES SUR L’ENSEMBLE DES DONNÉES
• 1 INDEX PAR MOIS DE DONNÉES, 30 SHARDS, PAS DE
ROUTAGE
TYPOLOGIE DU CLUSTER
• 2 QUERY NODES : VM, 31GB DE RAM
• 3 MASTER NODES : VM, 31GB DE RAM
• 62 DATA NODE : PHYSIQUE, 3,2TB SSD, RAID0, 64GB DE
RAM, XEON D
INDEXATION
• MERGE DE 3 CLUSTERS GALERA ET UN CLUSTER ES DANS
UNE QUEUE KAFKA : 30.000 DOCUMENTS / SECONDE
• INJECTION DES DONNÉES DE KAFKA DIRECTEMENT DANS LES
DATA NODES: 60.000 DOCUMENTS / SECONDE DE
MOYENNE SUR 3 SEMAINES
CPU BOUND
ARCHITECTURE D'INDEXATION
PROBLÈMES
• ES TENTE DE METTRE LES DONNÉES EN CACHE
• DES REQUÊTES SUR 3 ANS DE DONNÉES SANS LIMITE DE
DATE PASSENT, AVEC UNE LIMITE, PERTE DE LA MOITIÉ DES
NOEUDS
• LENTEUR DES REQUÊTES LES PLUS GROSSES
SOLUTIONS
• DÉSACTIVER LES CACHES D’ES
• PARALLELISATION DES REQUÊTES PAR INDEX
NOUVEAUX DOCUMENTS : QUI VA OÙ ?
• PROBLÈME : COMMENT SAVOIR DANS QUELS DASHBOARD VA
UN NOUVEAU DOCUMENT ?
• NE PLUS DÉPENDRE DE MYSQL
• 50 MILLIONS DE DOCUMENTS / JOUR
SOLUTION : LA PERCOLATION
• SYSTÈME D'ANNUAIRE INVERSÉ:
•
STOCKAGE DES REQUÊTES ET NON DES DOCUMENTS
• POUR CHAQUE DOCUMENT, TEST DE CHAQUE REQUÊTE
JUSQU’À TROUVER LA CORRESPONDANCE
PROBLÈMES DE LA PERCOLATION
• ESSAIE CHAQUE REQUÊTE STOCKÉE
• 35000 REQUÊTES À TESTER, EN CROISSANCE
• 1.750.000.000.000 REQUÊTES À PASSER PAR JOUR
• CPU GREEDY
SOLUTIONS
• ROUTAGE À PARTIR DE LA LANGUE DES DOCUMENTS
• HASH SUR LES LANGUES ACCEPTÉES PAR LES
DASHBOARDS
• FILTRAGE ENSUITE SUR LES TERMES DE LA REQUÊTE
• RÉSULTAT : PERMET DE TRAITER JUSQU’À 100.000
REQUÊTES / SECONDE
QUESTIONS ?
CVS :
[email protected]