Le document explore les alternatives aux bases de données relationnelles, présentant le mouvement NoSQL comme une réponse aux limitations des SGBDR traditionnels. Il met en avant les avantages tels que la disponibilité, l'élasticité des infrastructures et la gestion de gros volumes de données, tout en soulignant les défis liés à la consistance et aux transactions. Enfin, il décrit différentes catégories de bases NoSQL, incluant des modèles clés/valeurs, documentaires, orientés colonnes et graphiques.

1. N(ot) o(nly) SQL
Des alternatives aux bases de données relationnelles
Olivier Mallassi
v-0.3 (09 Septembre 2010)

2. 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 »

3. 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

4. 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

5. 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

6. 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

7. 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

8. À 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

9. N(ot) o(nly) SQL
un écosystème riche
© OCTO 2010

10. 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

11. …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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. N(ot) o(nly) SQL
pour conclure…
© OCTO 2010

21. 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

22. 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

23. © OCTO 2010
23