No Sql - Olivier Mallassi - September 2010
Upcoming SlideShare
Loading in...5
×
 

No Sql - Olivier Mallassi - September 2010

on

  • 429 views

No Sql - Olivier Mallassi - September 2010

No Sql - Olivier Mallassi - September 2010

Statistics

Views

Total Views
429
Views on SlideShare
429
Embed Views
0

Actions

Likes
0
Downloads
13
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

No Sql - Olivier Mallassi - September 2010 No Sql - Olivier Mallassi - September 2010 Presentation Transcript

  • N(ot) o(nly) SQL Des alternatives aux bases de données relationnelles Olivier Mallassi v-0.3 (09 Septembre 2010)
  • Pour démarrer Quelques idées reçues…   NoSQL n’est pas un remplacement des SGBDR   NoSQL reste un domaine d’innovation…   …même s’il existe de nombreux déploiement en production dans des systèmes hautement sollicités   NoSQL est un écosystème riche   Le reste ne la présentation ne se veut pas exhaustive   « Le diable est dans le détail »
  • Malgré tout, ces technologies sont intéressantes pour nos systèmes   Vers plus de disponibilité   Vers plus de souplesse dans la gestion des schémas/ structures   Vers plus d’élasticité de l’infrastructure   Un volume croissant de données stockées © OCTO 2010 3
  • Au commencement étaient… Systèmes relationnels Modélisation & normalisation de la données Modèle centralisé, un référentiel unique Système de backup Structuration forte de la donnée Systèmes relationnels Moteur et Langage SQL  Un référentiel unique de données structurées et couplées  Un système centralisé  Une donnée unique (structure, valeur, consistance…) pour toutes les utilisations  On modélise les données puis on développe des applications © OCTO 2010 4
  • Puis vinrent…   Des cas d’usage différents mais des enjeux communs         Performance Disponibilité (>99,99%) Résilience Scalabilité horizontale • Un moteur de recherche mondial • La boutique en ligne mondiale • Développements spécifiques : BigTable + Algorithmes Map/ Reduce • Développements spécifiques : Dynamo • Permet l’agrégation de gros volumes de données © OCTO 2010 • Permet d’obtenir de gros débit en écriture et d’assurer la disponibilité • Dernier incidents majeurs : 2004 • <40 minutes d’indisponibilité par an 5
  • Qui ont imposé des « trade-offs »   Disponibilité et Volumes de données manipulés et stockés   Réplication/partitionnement (ie. pas de backup ?)   Organisation physique des données optimisés pour les traitements (BigTable)   Performance / débit en écriture  Le « two phase commit » permet de respecter les propriétés ACID en environnement distribué mais au détriment des temps de réponse et gère mal l’indisponibilité de systèmes de stockage   Le sharding de systèmes relationnels reste complexe   L’élasticité et la gestion native du « fail-over » n’offre aucune garantie sur l’emplacement physique des données à un instant t   Difficile d’avoir un comportement transactionnel déterministe   Difficile de gérer des relations entre entités Trade-off : « we forfeit ‘C’ and ‘I’ for availibility, graceful degradation and performance » • Un spectre qui va de forte consistance, isolation, transactions à consistance faible, disponibilité prime, transactions optimistes • De ACID vers BASE © OCTO 2010 Source : « Towards Robust Distributed Systems » Dr. Eric A. Brewer http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf 6
  • NoSQL : des gênes différents Des systèmes distribués de stockage de données faiblement structurées Les alternatives aux systèmes relationnels ont été bâties pour assurer - La disponibilité (distribution & prise en compte du « fail-over », réplication multi-DC…) - Une faible structuration de la donnée (stockage de structures diverses, évolutivité des schémas…) - Elasticité des infrastructures (ajouts/pertes de serveur…) - Elasticité de la structure - Performance, débit en écriture (optimisation des accès disque, stockage des données en colonnes, Master/Master…) - Manipulation de gros volume de données (Partitionnement…) - Modélisation impossible ou difficilement exploitable dans le modèle relationnel  Des systèmes nativement décentralisés  Les applications sont écrites et influent la modélisation de la donnée. La donnée est stockée telle qu’utilisée par l’application (déjà vrai suivant l’utilisation que l’on fait d’un ORM)  Des systèmes distribués et optimisés pour les structures de données qu’ils manipulent © OCTO 2010 7
  • À l’origine du mouvement NoSQL Le Cloud démocratise ces solutions spécifiques hautement scalables • Google App Engine permet de développer sur le Google Data Store • Amazon offre des services de stockage : SimpleDB, S3 Certains acteurs « open-sourcent » leurs solutions (pas uniquement dans le domaine NoSQL) • LinkedIn et Voldemort, Facebook et Cassandra… La plupart des « grands du web » d’aujourd’hui migrent vers ces solutions Un marché de niche permettant une modélisation plus facile des données (par rapport à la modélisation relationnelle) • Les graphes, les documents… Le sens de l’histoire : 40 années de suprématie des RDBMS enfin « challengée » © OCTO 2010 8
  • N(ot) o(nly) SQL un écosystème riche © OCTO 2010
  • Un foisonnement de solutions… Key/Value Document     Graph Column Oriented Un marché « Open Source Pro » :       Les développeurs Redis rachetés par VMWare Cassandra, MongoDB, Riak, Neo4j ont des structures pouvant assurer le support, la formation… .. Un marché « As a Service »   © OCTO 2010 Amazon, vmWare… 10
  • …Organisées en grandes catégories basées sur la modélisation de la donnée Key/Value {attr1, …} Document Column Oriented Graph Flat file, Géographique, XML, Object… © OCTO 2010 11
  • Les bases « graph » Objectifs • Modéliser simplement des graphes de données • Des nœuds (et leur propriétés) • Des relations entre les nœuds et des propriétés sur les relations • Proposer un langage et un moteur de requête optimisé pour le parcours de graphes A noter • Evolutivité du schéma • Propriétés des nœuds et surtout des relations • Mode Master/Slave • Réplication asynchrone (eventually consistent) • Les solutions tendent vers l’implémentation de fonctionnalité de partitionnement • Respect d’ACID Cas d’utilisation • Recommandations / éléments liés (e-commerce…) • Construction de meta-datas (issues d’analyse des comportements utilisateurs, permettant de corréler des données diverses…) • … © OCTO 2010 12
  • Les bases « graph » en termes d’API Neo4j Transaction tx = myDb.beginTx(); try { Node architect = myDb.createNode(); Node smith = myDb.createNode(); smith.setProperty(« version », « 1.0 »); Relationship relation = smith.createRelationshipTo(architect, … relatoin.setProperty… tx.success(); } finally tx.finish(); © OCTO 2010 13
  • Les espaces de stockage « Key/value » Objectifs •  Assurer Disponibilité/Performances des systèmes en W/R et en TP •  Permettre le stockage de gros volume de données A noter •  Une donnée est identifiable pour sa clé uniquement •  La valeur n’est pas nécessairement structurée •  Requêtage : put / get / delete •  Mode Master/Master •  Partitionnement suivant la clé •  Gestion fine de la consistance : en fonction de la donnée, le niveau de réplication et de consistance que l’on souhaite •  Suivant les outils : Versionning des structures de données Neo Age:29 Name : Thomas Anderson … Trinity YXpnYXplZw== YXpnYXpl Zw== Cas d’usage •  Traitements TP (enjeux de début en écriture, disponibilité) •  Volumétrie de données © OCTO 2010 14
  • Stockage « Key/Value » en termes d’API Voldemort StoreClientFactory factory = new SocketStoreClientFactory(numThreads, numThreads, maxQueuedRequests, maxConnectionsPerNode, maxTotalConnections, bootstrapUrl); try { StoreClient<String, Object> client = factory.getStoreClient("author"); Map<String, Object> authorMap = new HashMap<String, Object>(); authorMap.put("key", "key" + i); authorMap.put("firstName", "firstName" + i); authorMap.put("lastName", "lastName" + i); client.put("key" + i, authorMap); © OCTO 2010 15
  • Les espaces de stockage « Column Oriented » Objectifs •  Permettre le stockage de gros volume de données •  Permettre l’analyse de gros volume de données •  Permettre la manipulation de colonnes uniquement •  Suivant les outils : Assurer Disponibilité/ Performances des systèmes en W/R Neo Age 29 Timestamp#1 name Thomas Anderson Timestamp#2 A noter •  Un modèle Key/Value où la valeur est a elle-même une représentation « Key/Value » •  Column oriented = optimisation du stockage physique de la donnée par colonne •  Suivant les outils : un mode Master/Master Cas d’usage •  Business Intelligence de façon générale © OCTO 2010 16
  • Stockage « Column-oriented » en termes d’API Cassandra TTransport tr = new TSocket("192.168.216.128", 9160); TProtocol proto = new TBinaryProtocol(tr); tr.open(); Cassandra.Client cassandraClient = new Cassandra.Client(proto); Map<String, List<ColumnOrSuperColumn>> insertClientDataMap = new HashMap<String, List<ColumnOrSuperColumn>>(); List<ColumnOrSuperColumn> clientRowData = new ArrayList<ColumnOrSuperColumn>(); ColumnOrSuperColumn columnOrSuperColumn = new ColumnOrSuperColumn(); columnOrSuperColumn.setColumn(new Column("fullName".getBytes(UTF8), aCustomer.getName().getBytes(UTF8), timestamp)); clientRowData.add(columnOrSuperColumn); insertClientDataMap.put("customers", clientRowData); cassandraClient.batch_insert("myBank", aCustomer.getName(),insertClientDataMap, ConsistencyLevel.DCQUORUM); © OCTO 2010 17
  • Et Hbase?   Un clone de Google Big Table   Utilise HDFS pour la réplication   Master/Slave JDBC Thrift … Hive (DSL SQL-like) Pig (DSL Hadoop : « framework » Map/Reduce HBase Hadoop Distributed File System © OCTO 2010 18
  • Les bases « Document » Objectifs •  Stocker de la donnée structurée permettant une interrogation plus complexe qu’un « Key/Value » Neo {« Age »: 29, « Name » : « Thomas Anderson » « knows »:[{« name »: « Trinity » … A noter •  S’apparente à une « Key/Value » dont la valeur est structurée •  Gestion des types des attributs (utf-8 string, integer, date…) •  Requêtage : insert, update, findBy •  Rajouts possibles d’index sur les attributs de la valeur •  Requête de type find(…), comparateur (<, ==…) •  Mode Master/Slave (même si les solutions tendent à offrir des fonctionnalités de partitionnement) •  Finalement assez proche des bases XML Cas d’usage •  Stockage de contenu (CMS, Blog, Mail…) © OCTO 2010 19
  • N(ot) o(nly) SQL pour conclure… © OCTO 2010
  • Des systèmes de stockage qui repoussent les limites et changent les règles établies   Performance, débit en écriture   Stockage et Manipulation de gros volume de données Au niveau des développements •  •  •  •  Relâchement d’ACID & faible modélisation de la donnée Gestion de stale state et résolution de conflits Pas (peu…) de systèmes de requêtes La gestion de certaines problématiques remontent au niveau de l’espace applicatif (Gestion de l’intégrité transactionnelle, jointures, filtres…) Au niveau de l’exploitation   Disponibilité et « Design for failure » •  Changement de l’outilage (JMX…) •  Quid de la gestion des backups (à relativiser par la réplication sur plusieurs nœuds) Au niveau de la sécurité •  Pas (peu…) de contrôles d’accès Pas de standardisation (à la différence de SQL qui normalise les API, le protocole d’accès…) Quid de l’intégration de ces systèmes dans le reste du SI   Elasticité des infrastructure •  Attentes en terme de reporting (ad-hoc, scheduled…) •  Partage des données entre plusieurs systèmes •  … de stockage   Souplesse de modélisation © OCTO 2010 21
  • Au-delà du buzz…   NoSQL nous rappelle qu’il est important de travailler sur l’utilisation qui est faite de la donnée   Toutes les données n’ont pas besoin d’être consistantes dans tous les contextes d’utilisation   NoSQL parle de collaboration : stockage « polyglote »   NoSQL parle d’alternatives et challenge 40 années de suprématie des bases relationnelles… © OCTO 2010 22
  • © OCTO 2010 23