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

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

Systèmes relationnels

Modélisation & normalisation de la données

Structuration forte de la donnée

Moteur et Langage SQL

Système de backup

Modèle centralisé, un

référentiel unique

Puis vinrent…

  Des cas d’usage différents mais des enjeux communs   Performance   Disponibilité (>99,99%)   Résilience   Scalabilité horizontale

© OCTO 2010 5

• Un moteur de recherche mondial

• Développements spécifiques : BigTable + Algorithmes Map/Reduce

• Permet l’agrégation de gros volumes de données

• La boutique en ligne mondiale

• Développements spécifiques : Dynamo

• Permet d’obtenir de gros débit en écriture et d’assurer la disponibilité • Dernier incidents majeurs : 2004 • <40 minutes d’indisponibilité par an

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

© OCTO 2010 6 Source : « Towards Robust Distributed Systems » Dr. Eric A. Brewer http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

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

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

NoSQL : des gênes différents Des systèmes distribués de stockage de données faiblement structurées

© OCTO 2010 7

Des systèmes distribués et optimisés pour les structures de données qu’ils manipulent

 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)

À l’origine du mouvement NoSQL

• Google App Engine permet de développer sur le Google Data Store • Amazon offre des services de stockage : SimpleDB, S3

Le Cloud démocratise ces solutions spécifiques hautement scalables

• LinkedIn et Voldemort, Facebook et Cassandra…

Certains acteurs « open-sourcent » leurs solutions (pas uniquement dans le domaine NoSQL)

La plupart des « grands du web » d’aujourd’hui migrent vers ces solutions

• Les graphes, les documents…

Un marché de niche permettant une modélisation plus facile des données (par rapport à la modélisation relationnelle)

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…

© OCTO 2010 10

Column Oriented Document

Graph

  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 »   Amazon, vmWare…

Key/Value

…Organisées en grandes catégories basées sur la modélisation de la donnée

© OCTO 2010 11

Key/Value

Document

Column Oriented

Graph

Flat file, Géographique, XML, Object…

{attr1, …}

Les bases « graph »

© OCTO 2010 12

• 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

Objectifs

• 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

A noter

• 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…)

• …

Cas d’utilisation

Les bases « graph » en termes d’API

© OCTO 2010 13

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();

Neo4j

Les espaces de stockage « Key/value »

© OCTO 2010 14

Neo Age:29 Name : Thomas Anderson …

Trinity YXpnYXplZw== YXpnYXpl Zw==

•  Assurer Disponibilité/Performances des systèmes en W/R et en TP

•  Permettre le stockage de gros volume de données

Objectifs

•  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

A noter

•  Traitements TP (enjeux de début en écriture, disponibilité)

•  Volumétrie de données

Cas d’usage

Stockage « Key/Value » en termes d’API

© OCTO 2010 15

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);

Voldemort

Les espaces de stockage « Column Oriented »

© OCTO 2010 16

29 Neo Age

name Thomas Anderson

Timestamp#1

Timestamp#2

•  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

Objectifs

• 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

A noter

•  Business Intelligence de façon générale

Cas d’usage

Stockage « Column-oriented » en termes d’API

© OCTO 2010 17

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);

Cassandra

Hadoop : « framework » Map/Reduce

Et Hbase?

  Un clone de Google Big Table   Utilise HDFS pour la réplication

  Master/Slave

© OCTO 2010 18

Hadoop Distributed File System

HBase

Hive (DSL SQL-like) Pig (DSL

JDBC Thrift …

Les bases « Document »

© OCTO 2010 19

{« Age »: 29, « Name » : « Thomas Anderson » « knows »:[{« name »: « Trinity » …

Neo •  Stocker de la donnée structurée permettant une

interrogation plus complexe qu’un « Key/Value »

Objectifs

•  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

A noter

•  Stockage de contenu (CMS, Blog, Mail…)

Cas d’usage

N(ot) o(nly) SQL pour conclure…

© OCTO 2010

Des systèmes de stockage qui repoussent les limites et changent les règles établies

•  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 des développements

•  Changement de l’outilage (JMX…) •  Quid de la gestion des backups (à relativiser par la réplication sur plusieurs nœuds)

Au niveau de l’exploitation

•  Pas (peu…) de contrôles d’accès

Au niveau de la sécurité

Pas de standardisation (à la différence de SQL qui normalise les API, le protocole d’accès…)

•  Attentes en terme de reporting (ad-hoc, scheduled…) •  Partage des données entre plusieurs systèmes •  …

Quid de l’intégration de ces systèmes dans le reste du SI

© OCTO 2010 21

  Performance, débit en écriture

  Stockage et Manipulation de gros volume de données

  Disponibilité et « Design for failure »

  Elasticité des infrastructure de stockage

  Souplesse de modélisation

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