NoSQL : hype ou innovation
Transcription
NoSQL : hype ou innovation
NoSQL : hype ou innovation ? Grégory Ogonowski / Recherches Octobre 2011 Octobre 2011 Sommaire • Introduction • Théorème CAP • NoSQL (principes, mécanismes, démos,...) • Ce que nous avons constaté • Recommandations • Conclusion 2 Octobre 2011 Introduction • Bases de données relationnelles : − Solutions mûres et maîtrisées − Robustes − Ont fait leurs preuves • Pourquoi s'embêter avec autre chose ??? UID NOM Prénom UID GID GID Groupe 1 Jagger Mick 1 2 1 Beatles 2 Harrison George 2 1 2 Rolling Stones 3 Starr Ringo 3 1 3 Octobre 2011 Introduction : impact du Web 2.0 1970 1990 Primum Relationalus Adabasolite databasauris 2000 2010 Columnus NoSQLausis KeyValueraptor IBM LOTUS Dominosaurus Armageddon NoSQLausis 2.0 Graphosis NoSQLausis Documentaris !!! N'ont pas disparu et NoSQLausis ne disparaîtront pas !!! Smalsopithecus 4 Octobre 2011 Introduction : impact du Web 2.0 • Énorme masse d'utilisateurs • Gros volumes de données à gérer (hype Big Data) • Contraintes différentes : − Scalabilité > Consistance − Disponibilité > Consistance 5 Octobre 2011 Introduction : impact du Web 2.0 • Facebook: − Pic de 13 000 000 req db/sec − 690 milliards de pages vues/mois − 300 To de données… en cache mémoire − 25 To de logs par jour − 1 ingénieur/1,1 millions d’utilisateurs 6 Octobre 2011 Théorème CAP • Consistency, Availability, Partition tolerant • Conjecture, démontrée en 1992 pour les systèmes distribués CA asynchrones Choisissez-en deux C A AP CP P 7 Octobre 2011 Théorème CAP : Consistency Tous les utilisateurs ont toujours la même vue sur toutes les données 8 Octobre 2011 Théorème CAP : Availability Est-il toujours possible de lire des données et d'en écrire ? 9 Octobre 2011 Théorème CAP : Partition tolerant L'application peutelle survivre à un partitionnement du réseau ? ? 10 Octobre 2011 Théorème CAP C : OK A – P : Redondants ? CAP theorem =?= CRAP theorem 11 Octobre 2011 Théorème CAP Autre approche : PACELC "if there is a partition (P) how does the system tradeoff between availability and consistency (A and C); else (E) when the system is running as normal in the absence of partitions, how does the system tradeoff between latency (L) and consistency (C) ? " Ex : PA/EL 12 Octobre 2011 Théorème CAP VS PACELC CAP VS Simple Flou PACELC Complexe Clair © http://buzzworld.fr/ Deux manières différentes pour exprimer la même chose. 13 Octobre 2011 NoSQL : C’est quoi ? • Catégorie de Bases de Données • NoSQL = No SQL Not only SQL (Structured Query Language) Ex : SELECT champ1, champ2 FROM table; 14 Octobre 2011 NoSQL : C’est quoi ? • Souvent − très scalables − non-relationnelles − très spécifiques − sans schéma 15 Octobre 2011 NoSQL : ACID VS BASE CAP = On ne peut pas tout avoir • ACID • BASE − Atomicity − Basically Available − Consistency − Soft state − Isolation − Eventual consistency − Durability Souvent choisi pour NoSQL 16 Octobre 2011 NoSQL : Qui utilise ça ??? • Facebook, Twitter, Google, bit.ly, Springer, Amazon, digg, IBM, LinkedIn, Rackspace, sourceforge, … • Globalement : des sites à très forte consultation • Mais aussi de nombreux sites Web en tant que cache ! 17 Octobre 2011 NoSQL : Et ça marche ? • Oui mais… 18 Octobre 2011 NoSQL : Et ça marche ? • Oui mais… • … pas une solution miracle • Plusieurs mécanismes (souvent simples) pour améliorer la scalabilité et/ou la haute disponibilité 19 Octobre 2011 NoSQL : Quelques mécanismes Partitionnement Réplication (+ Quorum) 20 Octobre 2011 NoSQL : Quelques mécanismes Partitionnement • Découpage des données en vue de les distribuer • Pas nouveau • Mais… différentes manières de procéder 21 Octobre 2011 NoSQL : Quelques mécanismes Réplication • Au moins deux instances de chaque donnée • Pas nouveau • Mais… différentes manières de procéder 22 Octobre 2011 NoSQL : Quelques mécanismes Partitionnement • Traditionnellement : un "simple" modulo sur la clé pour déterminer l'emplacement d'une donnée • Chaque nœud sait où se trouve chaque donnée 127 127 % 4 = 3 Serveur 0 Serveur 1 Serveur 2 Serveur 3 23 Octobre 2011 NoSQL : Quelques mécanismes Partitionnement • En cas d'ajout ou de retrait d'un serveur, besoin de tout recalculer pas évident à rendre scalable Modulo 4 Serveur 0 Serveur 1 Serveur 2 Serveur 3 352 Modulo 3 - 934 - 327, 395, 471 Serveur 0 Serveur 1 Serveur 2 327, 471 Modulo 5 - - 352, 934 - 395 Serveur 0 Serveur 1 Serveur 2 Serveur 3 Serveur 4 395 - 471 - 327, 352 - - 934 24 Octobre 2011 NoSQL : Quelques mécanismes Partitionnement • Consistent hashing N1-1 C A N2-1 B 25 Octobre 2011 NoSQL : Quelques mécanismes Partitionnement • Ajout d’un noeud : ajustements minimes N81 N11 N91 N21 N71 N31 N61 N51 N41 N11 N21 N81 N31 N71 N41 N61 N51 26 Octobre 2011 NoSQL : Quelques mécanismes Partitionnement • Pondération des noeuds N1-1 N1-1 C A C A N3-2 N2-1 B N2-1 B 27 Octobre 2011 NoSQL : Quelques mécanismes Partitionnement • Consistent hashing + réplication • Relativement simple • Chaque nœud sait où se trouve N4-1 chaque donnée N1-1 A G B C B F D A E G C N2-1 F E D N3-1 28 Octobre 2011 NoSQL : Quelques mécanismes Quorum (finalement consistant) • Seuils de lecture (SL) et d’écriture (SE) • Un petit exemple ? • Hypothèse : 6 copies de chaque donnée (#C = 6) Inst 1 Inst 4 • Let’s go… Inst 2 Inst 5 Inst 3 Inst 6 29 Octobre 2011 NoSQL : Quelques mécanismes Quorum (éventuellement consistant) SE = 3 SL = 2 Inst 1 Inst 2 Inst 3 Inst 4 Inst 5 Inst 6 Inst 1 Inst 2 Inst 3 Inst 4 Inst 5 Inst 6 30 Octobre 2011 NoSQL : Quelques mécanismes Quorum (finalement consistant) • Données finalement consistantes • Paramétrisation possible Si (SL + SE > #C) alors Si (SL < SE) alors données consistantes lectures rapides Sinon Sinon si (SL > SE) alors données finalement écritures rapides consistantes Sinon même vitesse pour écriture et lecture 31 Octobre 2011 NoSQL : Quelques mécanismes Quorum (finalement consistant) X SL + SE Performances Consistance SE Ecritures rapides SL Lectures rapides X 32 Octobre 2011 NoSQL : Quelques mécanismes Quorum (finalement consistant) Plus complexe en pratique Inst 1 Inst 2 Inst 3 Inst 4 Inst 5 Inst 6 Inst 1 Inst 2 Inst 3 Inst 4 Inst 5 Inst 6 Inst 1 Inst 2 Inst 3 Inst 4 Inst 5 Inst 6 33 Octobre 2011 NoSQL : Quelques mécanismes Quorum (finalement consistant) • Vector clocks • … • Laissons cela en annexe 34 Octobre 2011 NoSQL : Bases de données traditionnelles Grands tableaux avec relations FF 11 11 0A GG 44 55 7B HH 55 66 4C II 77 99 5M GG 0A FF 8Z TT 4P NN 5M 35 Octobre 2011 NoSQL : une grande famille • Clé / Valeur − (K/V) • Orientées colonnes − (COL) • Orientées documents − (DOC) • Orientées graphes − (GR) K/V COL DOC GR © http://www.paramount.com/ 36 Octobre 2011 NoSQL : caractérisation REL = RDBMS 37 Octobre 2011 NoSQL : caractérisation http://blog.nahurst.com/visual-guide-to-nosql-systems Tokyo Cabinet NEO4J MySQL Vertica Oracle Postgres K/V COL KAI Voldemort Dynamo Cassandra HypergraphDB CouchDB FlockDB Riak SimpleDB REL DOC Hbase Hypertable Terrastore GR BigTable MongoDB Berkeley DB Scalaris Redis MemcacheDB 38 Octobre 2011 NoSQL : caractérisation • CA – AP – CP • K/V – COL – DOC – GR • 12 types de DB… • … diverses architectures et modes de fonctionnement par type © http://www.paramount.com/ 39 Octobre 2011 NoSQL : caractérisation Tokyo Cabinet NEO4J MySQL Vertica Oracle Postgres K/V COL KAI Voldemort Dynamo Cassandra HypergraphDB CouchDB FlockDB Riak SimpleDB REL DOC Hbase Hypertable Terrastore GR BigTable MongoDB Berkeley DB Scalaris Redis MemcacheDB 40 Octobre 2011 NoSQL : caractérisation Tokyo Cabinet Cassandra NEO4J MemcacheDB Redis CouchDB K/V COL DOC GR Hypertable FlockDB MongoDB 41 Octobre 2011 NoSQL : Clé-Valeur Grandes tables de hachages Key Value 42 Octobre 2011 NoSQL : Clé-Valeur • Caractéristiques : − Simples − Interface pauvre (peu de commandes) − Très performantes • Remarques : − Partitionnement des données pas toujours pris en charge par la DB 43 Octobre 2011 NoSQL : Clé-Valeur • Pour que faire : − Cache d’un site web − Stockage de données élémentaires NoSQL K/V Clé A C Valeur B D RDBMS Clé A C Valeur B D 44 Octobre 2011 NoSQL : Clé-Valeur • DEMOS Tokyo Cabinet K/V COL DOC GR MemcacheDB Redis 45 Octobre 2011 NoSQL : Solutions orientées colonnes Longues listes variées K1 C1 : V C2 : V C3 : V K2 C1 : V C3 : V C6 : V K = C = Column V = Key Value C8 : V 46 Octobre 2011 NoSQL : Solutions orientées colonnes Parfois possible d'avoir un niveau de hiérarchie supplémentaire (super colonnes) K C1 : V C2 : V C3 : V C4 : V K = C = Column V = Key Value C5 : V 47 Octobre 2011 NoSQL : Solutions orientées colonnes • Caractéristiques : − Gestion d'un très grand nombre de colonnes (plusieurs millions) − Requêtes minimalistes • Remarques : − Absolument pas prévu pour le relationnel difficile à exploiter pour les gens habitués aux RDBMS 48 Octobre 2011 NoSQL : Solutions orientées colonnes • Pour que faire : − Stockage de données chronologiques (ex : log système, evolution d’un dossier médical) − Relations one-to-many (ex : gérer des droits d’accès) NoSQL Col RDBMS A E B=1 F=4 C=2 D=3 G=5 Node A E B C D F G Father NULL NULL A A A E E Value NULL NULL 1 2 3 4 5 49 Octobre 2011 NoSQL : Solutions orientées colonnes • DEMOS Cassandra K/V COL DOC GR Hypertable 50 Octobre 2011 Pause A := #persons_before_pause B := #persons_after_pause IF A > B THEN presentation_quality := bad ELSE presentation_quality := normal IF B > A THEN attenders_punctuality := bad INSERT "Coffee" INTO "Hall"; 51 Octobre 2011 NoSQL : Solutions orientées documents Documents structurés sans schémas prédéfinis F1 : V = Field V = Value K = Key F1 : V F2 : V, V, V K F F3 : V F2 : V K F3 : V, V F4 : V, V F4 : V F5 : V F5 : V F6 : V 52 Octobre 2011 NoSQL : Solutions orientées documents • Caractéristiques : − Très flexibles − Syntaxe parfois très riche − Bien adapté au monde du Web 53 Octobre 2011 NoSQL : Solutions orientées documents • Pour que faire : − Gérer des données avec des structures complexes et variables (DMFA, profils utilisateurs complexes) − Cache de données structurées (manipulation Node Father Value de formulaires) A NULL NULL NoSQL doc A B=1 C=2,D=3 H=6 F=4,G=5 I=7,J=8,K=9 L=10,M=11 B CD C D FG F G H IJK I J K LM L M A A NULL NULL CD NULL NULL A H NULL NULL NULL IJK NULL NULL 1 NULL 2 3 NULL 4 5 NULL NULL 7 8 9 NULL 10 11 RDBMS Node C D F G I J K L M MemberOf CD CD FG FG IJK IJK IJK LM LM 54 Octobre 2011 NoSQL : Solutions orientées documents • DEMOS CouchDB K/V COL DOC GR MongoDB 55 Octobre 2011 NoSQL : Solutions orientées graphes N Graphes orientés = Noeud N2 N1 N3 N5 N4 56 Octobre 2011 NoSQL : Solutions orientées graphes • Caractéristiques − Parfois optimisées pour la résolution de problèmes complexes et non pour les performances • Remarque − Peu de solutions intéressantes à ce jour 57 Octobre 2011 NoSQL : Solutions orientées graphes • Pour que faire : − Gérer des relations complexes et dynamiques (ontologies, relations entre personnes, administrations, …) NoSQL graph A H E D Src Dst A B B D C B C D D A B J C G I RDBMS Rel E G I J H F 58 Octobre 2011 NoSQL : Orientées graphes © http://www.foxmovies.com/ • DEMOS NEO4J K/V COL DOC GR FlockDB 59 Octobre 2011 NoSQL : Récapitulatif K/V Key K COL Value F1 : V F2 : V, V, V F3 : V F4 : V, V F5 : V F6 : V DOC K1 C1 : V C2 : V C3 : V N2 N1 N3 N5 N4 GR 60 Octobre 2011 NoSQL : Récapitulatif K/V Cache site Web Stockage données élémentaires Documents complexes (DMFA, profils utilisateurs, cache de données structurées ) DOC COL Données chronologiques (log système, dossier médical) Relations One-to-Many Gérer des relations complexes et dynamiques (ontologies, relations personnes/administrations) GR 61 Octobre 2011 NoSQL : Récapitulatif Tokyo Cabinet NEO4J MySQL Vertica Oracle Postgres K/V COL KAI Voldemort Dynamo Cassandra HypergraphDB CouchDB FlockDB Riak SimpleDB REL DOC Hbase Hypertable Terrastore GR BigTable MongoDB Berkeley DB Scalaris Redis MemcacheDB 62 Octobre 2011 Ce que nous avons constaté • Outils très spécifiques et efficaces dans leur domaine • Maturité très variable d’une solution à l’autre • Installation et prise en main aisées • Peu ou pas d’outils tiers (incompatible avec l’existant ?) 63 Octobre 2011 Ce que nous avons constaté • Se méfier des benchmarks : − Solutions très spécifiques − Nécessité de réaliser des benchmarks exploitant les spécificités des bases de données testées − Topologie réseau propre à chaque DB 64 Octobre 2011 Ce que nous avons constaté • Ne pas négliger la documentation • Limitations parfois inattendues : − 4Mo pour un objet MongoDB, − 1Mo pour un object Memcached − Pas de redéfinition de colonnes dans Cassandra − … 65 Octobre 2011 Ce que nous avons constaté • Réception auprès des utilisateurs • Incompréhension • Réticence 66 Octobre 2011 Recommandations • NoSQL n’est pas un objectif en soi • Ne répond pas à tous les problèmes • A utiliser uniquement si les SGBDR ne conviennent pas : − Trop lents − Données difficiles à modéliser − Données difficiles à exploiter − Format des données variable © http://www.misterandyriley.com/ 67 Octobre 2011 Recommandations • Adapter la BD au format des données et non le contraire • NE PAS PENSER RELATIONNEL (surtout lors de la définition du modèle de données) • Peut être utilisé conjointement à un RDBMS 68 Octobre 2011 Recommandations (Choix d’une solution) Tokyo Cabinet NEO4J MySQL Vertica Oracle Postgres K/V COL KAI Voldemort Dynamo Cassandra HypergraphDB CouchDB FlockDB Riak SimpleDB REL DOC Hbase Hypertable Terrastore GR BigTable MongoDB Berkeley DB Scalaris Redis MemcacheDB 69 Octobre 2011 Conclusion • Bases de données NoSQL : une alternative sérieuse au modèle relationnel ? • Alternative : non ! (permettent de résoudre des problèmes différents) • Sérieux : oui ! (même Oracle va proposer sa solution NoSQL) • A utiliser si les bases de données relationnelles se montrent inefficaces/trop complexes. 70 Octobre 2011 Conclusion • Beaucoup de solutions, mais très spécifiques • Ne pas négliger la formation et la documentation • Ne pas toujours penser relationnel • Ne pas toujours penser relationnel ! 71 Octobre 2011 Conclusion • NoSQL : hype ou innovation ? • Hype et innovation • Potentiel réel et non négligeable • Téléchargez, jouez un peu, faites-vous une idée avant d’essayer ou de dire non ;-) 72 Octobre 2011 Questions ? SELECT "Questions" FROM "Public"; DELETE FROM "Public"; 73