NoSQL panorama - Jean Seiler Softeam

Faites de votre projet un succès
© SOFTEAM Cadextan
PANORAMA
NOSQL
Jean Seiler
jean.seiler@softeam.fr

Jean-Seiler 28/11/2015 Nosql© SOFTEAM Cadextan
INTRODUCTION
2
Constat
│Avènement de grosses plateformes/application Web
• Google, twitter, Amazon…
• Alternative au SGBD relationnel classique
│Données hétérogènes
• Rigidité du modèle de données
│Limites des SGBD traditionnels
│Scalabilité verticale nécessite des couts important sur le hardware
Besoin de nouvelles approches
│Meilleure scalabilité dans des contextes distribués
│Gestion d’objet hétérogène ne répondant pas nécéssairement à un schéma défini

NOSQL
3
C’est quoi ???
Terme créé en 1998 pour nommer une base sans interface SQL (Carlo Strozzi).
Terme proposé par Eric Evans lors de la rencontre qui a lancé le mouvement en
2009.
Historiquement, initiative Google ‘Big Table’ / Amazon ‘Dynamo’
│Google : indexer le web en temps réel
│Amazon : un magasin toujours ouvert, avec toujours plus de clients

NOSQL
4
 Non relationnelle, Volumetrie, Distribuée, scalable horizontalement…
Caractéristiques type
│Schema-free
│Distribué
│Support pour une réplication facile
│API simple
│Volume de données important
│BASE (Basically Available, Soft State, Eventually consistent)
Commodity hardware
│Machine modeste
│Hétérogénéité

THEOREME DE CAP ( THÉORÈME DE BREWER)
Cohérence:
Tous les nœuds du système voient la même donnée simultanément
Haute disponibilité:
Répondre à toutes les requêtes (MAJ)
Tolérance au partitionnement:
Aucune panne réseau ne doit empêcher le système de répondre
« 2 des 3 »
6
CConsitency
AAvailability
PPartition Tolerance

ACID VS BASE
7
Basicaly Available
│ Le système garantit la disponibilité des données
Soft State
│ L’état peut être modifié avec le temps, même sans input des utilisateurs (modèle de cohérence)
Eventualy consistent
│ Deux observateurs pourront éventuellement voir la même version de la donnée, si durant un certain laps de temps aucune
autre modification n’a lieu sur la donnée
ACID BASE
Priorité Cohérence / focus on commit
Disponibilité en second
Point de vue pessimiste
Mécanismes complexes
Priorité disponibilité
Cohérence « finale »
Point de vue optimiste
Simple et efficace / Best effort

NOSQL – CONCEPTS CLÉS
8
Mécanisme de partitionnement horizontal
│Données stockées sur des nœuds différents en fonction d’une clé
Facteur de Réplication
│Afin d’assurer la disponibilité des données, les outils NoSQL permettent de
spécifier un facteur de réplication
Consistency level
│Niveau de lecture ou d’écriture souhaité en fonction du nombre de nœuds
participants et du facteur de réplication
Faible latence / risque intégrité Forte latence / données protégées
ZERO ANY ONE QUORUM ALL
QUORUM = (N/2)+1,
où N = facteur de
réplication

Hbase Cassandra Hypertable Accumulo Amazon SimpleDB SciDB Stratosphere flare
Cloudata BigTable QD Technology SmartFocus KDI Alterian Cloudera C-Store
Vertica Qbase–MetaCarta OpenNeptune HPCC Mongo DB CouchDB Clusterpoint
ServerTerrastore
Jackrabbit OrientDB Perservere CoudKit Djondb SchemaFreeDB SDB JasDB
RaptorDB ThruDB RavenDB DynamoDB Azure Table Storage Couchbase Server Riak
LevelDB Chordless GenieDB Scalaris Tokyo Kyoto Cabinet Tyrant Scalien
Berkeley DB Voldemort Dynomite KAI MemcacheDB Faircom C-Tree HamsterDB STSdb
Tarantool/BoxMaxtable Pincaster RaptorDB TIBCO Active Spaces allegro-C nessDBHyperDex
Mnesia LightCloud Hibari BangDB OpenLDAP/MDB/Lightning Scality Redis
KaTree TomP2P Kumofs TreapDB NMDB luxio actord Keyspace
schema-free RAMCloud SubRecord Mo8onDb Dovetaildb JDBM Neo4 InfiniteGraph
Sones InfoGrid HyperGraphDBDEX GraphBase Trinity AllegroGraph BrightstarDB
Bigdata Meronymy OpenLink Virtuoso VertexDB FlockDB Execom IOG Java Univ
Netwrk/Graph Framework
OpenRDF/Sesame Filament OWLim NetworkX iGraph Jena SPARQL
OrientDb
ArangoDB AlchemyDB Soft NoSQL Systems Db4o Versant Objectivity Starcounter
ZODB Magma NEO PicoList siaqodb Sterling Morantex EyeDB
HSS Database FramerD Ninja Database Pro StupidDB KiokuDB Perl solution Durus
GigaSpaces Infinispan Queplix Hazelcast GridGain Galaxy SpaceBase JoafipCoherence
eXtremeScale MarkLogic Server EMC Documentum xDB eXist Sedna BaseX Qizx
Berkeley DB XML Xindice Tamino Globals Intersystems Cache GT.M EGTM
U2 OpenInsight Reality OpenQM ESENT jBASE MultiValue Lotus/Domino
eXtremeDB RDM Embedded ISIS Family Prevayler Yserial Vmware vFabric GemFire Btrieve
KirbyBase Tokutek Recutils FileDB Armadillo illuminate Correlation Database FluidDB
Fleet DB Twisted Storage Rindo Sherpa tin Dryad SkyNet Disco
MUMPS Adabas XAP In-Memory Grid eXtreme ScaleMckoiDDB Mckoi SQL Database
Oracle Big Data Appliance Innostore FleetDB No-List KDI Perst IODB
QUELLE SOLUTION CHOISIR???
9NoSQL
Neo4J
SimpleDB
CouchDB
voldemort
OrientDB

CRITÈRES DE CHOIX - PISTES
10
Modélisation des données
│Toute base impose une façon d’organiser les données
│Organisation structurante
│Influence les possibilités de requêtes
Flexibilité - Polyvalence
│Possibilité de lire les données d’une façon non prévue? Requètes « ad hoc »
Performance
│Capacité de la base pour monter en charge
• Nombre de requête
• Quantité de données stockés
La communauté - Pérénité
│Documentation/ exemple existant
│Outils pour faciliter l’exploitation de la solution
│Support

CLASSIFICATION DES SOLUTIONS NOSQL
11
Familles de technologies (modèle de réplication)
Maitre / Esclave
Maitre / Maitre
Modèle de données
Clé valeur
Orienté documents
Orienté colonnes
Orienté graphes
Clé Valeur
Clé
Document structuré
{
"propriété1" : "valeur1",
"propriété2" : valeur2
}
Clé
colonne1 colonne2
valeur1 valeur2
Clé
propriété1
valeur1
propriété2
valeur2
AutreClé
propriété3
valeur3
Relation

C’EST L’HEURE DU QUIZ!
Question : Qu’est ce qui défini le mieux BASE
(par rapport au théorème de C A P)?
A) Ajoute des contraintes à ACID
B) Simplement disponible,
état souple, éventuellement consistant
C) Propriétés de base des bases SQL + NoSQL
D) Quand on a un marteau, tous les problèmes
deviennent des clous!!
Répondez vite en tweetant sur @TechConfQuiz

BASE DE DONNÉES – CLÉ VALEUR
13
Base: clé valeur,
│ Gigantesque base assiciative
│ Pas de schéma – Pas de type pour la valeur
│ En général seulement les opérations CRUD
│ Souvent un TTL
│ Importance de la nomeclature du nomage des clés:
• Client.3, config.10 Clé1
Clé2
…
Clé3
valeur1
valeur2
valeur3

BASE DE DONNÉES – CLE VALEUR
14
Forces
│Modèle de données simple
│Scalabilité horizontale élevée
│Performance de lecture / écriture
Faiblesses
│Modèle de données Simple 
• limité pour les données complexes
│Fonctionnalité en général limité aux opérations CRUD
• Interrogation sur la clé uniquement
• Déporte la complexité de l’application sur le client applicatif
Type d’utilisation:
│Logs, cache, profils, préférences, …

BASE DE DONNÉES – CLE VALEUR -EXEMPLE
15
Redis
│ CAP
│ Très performant en lecture/écriture
│ Types de données riches (string, list, map).
│ Opération atomique
│ Supporte les transactions.
│ Cluster (sharding automatique)
│ Publish/Subscribe
Riak
│ CAP par défaut CAP – si besoin
│ Script en Erlang/javascript
│ Nativement MapReduce
│ Opération atomique
│ Master less.
│ Robustesse
│ Partage d’état (GOSSIP)
│Toutes les données sont en mémoire

BASE DE DONNÉES - GRAPHE
16
2 concepts:
│ Stockage de document
│ Mécanisme de description des relations entre objets.
{
}
{
"propriété1" : "valeur1bis",
"propriété3" : "valeur3"
}
{
"propriété2" : valeur2bis,
}
Arc
Propriete1:valeur
Propriete2:valeur
…
Arc
Propriete1:valeur
Propriete2:valeur
…

BASE DE DONNÉES ORIENTÉE GRAPHE
17
Forces
│ Problèmatique liée aux réseaux:
• Cartographie
• Relations entre objet
Faiblesses
│ Sharding
Exemples
│ Neo4J
│ OrientDB

BASE DE DONNÉES ORIENTÉE COLONNES
18
Base structurées en famille de colonnes (comme les tables du modèle relationnel).
Dans une famille de colonnes, une clé identifie une ligne de colonnes, où la colonne est l’entité de base
représentant un champ de données.
Chaque colonne est définie par un couple clé/valeur, représentant le nom du champ de données et sa valeur.
Famille de colonne
Clé1
colonne1 colonne2
valeur1 valeur2
Clé2
colonne1 colonne2
valeur1bis valeur2bis
Client
18
nom prenom
12
nom naissance
Dupond 18/11/197
2
Seiler Jean

BASE DE DONNÉES ORIENTÉE COLONNES
19
Forces
│ Haute disponibilité
│ Performance en écriture sur des volumes de données importants
│ bonne mise à l'échelle à l'horizontale
│ Stocker des données qui expirent
Faiblesses
│ Pas de garantie d’intégrité des relations entre les colonnes
│ Opérations sur des multiples colonnes pas optimales
• A éviter pour des données interconnectées
Exemples
│ Cassandra,
│ Hbase,
│ Amazon SimpleDB,
│ Google Big Table

A l’origine développé par Facebook - Ecrit en java
CAP (Consistence éventuelle)
│ Ajustable
Distribué :
│ pas de maitre
│ Chaque noeud gére une plage de token
│ Gossip model
Types: String, decimal; int, blolb, map, set,…
Index secondaires
TTL
Langage d’interrogation proche de SQL (CQL)
│ Pas de joins, de requêtes imbriquées, de group by
│ Pas de transaction
• Select * FROM client
Package commercial avec datasax (outillage+support)
20
A
B
C
D

BASE DE DONNÉES ORIENTÉE DOCUMENTS
21
Base: clé valeur,
│ valeur est un document « riche »
│ Nesteed document
│ Document enregistré sur un format standard (e.g. JSON like).
│ Opérations complexes pour chercher des documents.
Clé1
{
}
Clé2
{
"propriété1" : "valeur1bis",
}
Clé3
{
"propriété2" : valeur2bis,
"propriété4" : {"propriété5":"valeur5","propriété6":"valeur6"}
}

BASE DE DONNÉES ORIENTÉE DOCUMENTS
22
Forces
│ Variété de types de données et des opérations (y compris retourner seulement une partie des valeurs)
│ Performance de lecture avec latence faible
│ Simplifier la mise à jour d’un système avec le support de champs optionnels,
• Ajout / suppression de champs sans migration de modèle de données
Faiblesses
│ Opération transactionnelle mono document
│ Pas de notion de clé étrangère. Utilisation de pointeur au sein même du document ou de dénormalisation
│ Pas de mise à jour partielle d’un document. Mode tout ou rien.
│ Pas adapté à des besoins de mise à jour fréquent sur des structures de données volumineuses
Exemples
│ CouchDB,
│ MongoDB,
│ ElasticSearch peut être considéré comme une base de données orientée document mais ne le revendique pas.

Jean-Seiler 28/11/2015 Nosql© SOFTEAM Cadextan 23
C++
CAP
Caractéristique
│ Stockage des documents en BSON (moteur de stockage configurable)
│ Interrogation en json
│ Réplication maître esclave asynchrone
│ Partitionnement des données possible pour augmenter la disponibilité en écriture
Richesse fonctionnelle
│ Type classique : Stirng, integer, boolean, date, array…
│ CRUD
│ De nombreux operateur
│ Moteur map reduce + framework d’aggregation
{
"_id" : ObjectId("5143ddf3bcf1bf4ab37d9c6f"),
"author" : "machine",
"title" : "Declaration of Independence",
"tags" : [
"study",
"network",
"risk",
"knight",
"department",
"buffet"
],
"date" : ISODate("2013-03-16T02:50:27.878Z")
}

Jean-Seiler 28/11/2015 Nosql
ZOOM CASSENDRA - MONGODB
24

DISPONIBILITÉ
25
La stratégie de réplication définit le facteur de réplication
(nombre de copies de chaque donnée)
Les requêtes sont traitées selon le niveau de cohérence souhaité
(le nombre de serveurs devant répondre à la requête)
Mongo DB Cassendra
Réplication maître esclave asynchrone Réplication maître maître (synchrone ou
asynchrone selon choix par opération)
Partitionnement des données possible pour
augmenter la disponibilité en écriture (au cas
où le master tombe),
Partitionnement des données en utilisant
« consistent hashing », où chaque clé est associée
à une valeur et chaque serveur gère un intervalle
de valeurs
Possibilité de modifier les priorités des
nœuds
Réplication multidatacenter

PERFORMANCE
26
Mongo DB Cassendra
Performance des écritures pas optimale
• Un seul maître (bottleneck)
• Mise à jour « in place »
• Depuis V3 Lock d’écriture au niveau document
Très performant en écriture
Possibilité d’utiliser des indexes secondaires
(jusqu’à 31 colonnes à la fois)
Possibilité d’utiliser des indexes secondaires (une
seule colonne à la fois)
Taille limite des documents de 16Mo
• Documents plus gros sont découpés par
l’application (MongoDB recommande GridFS
uniquement pour des données binaires)
Taille limite des documents de 2Go
Performance de lecture peut être améliorée si on
permet de lire dans les nœuds esclaves
Performant en lecture

COHÉRENCE
MongoDB
│ Cohérent par défaut, un seul maître qui gère les lectures et écritures
│ Eventuellement cohérent si on permet de lire dans les nœuds esclaves
• Par défaut, les écritures sont en mode « acknowledged », le maître a bien enregistré l’opération en mémoire (mais pas les
esclaves)
• Option « journaled » et « replica acknowleged » disponible
Cassandra
│ Pa cohérent par défaut
│ Niveau de cohérence configurable par opération
27

MODÉLISATION
28
Mongo DB Cassandra
Modèle de données orienté documents,
collections de documents BSON
Modèle de données orienté colonnes
Plusieurs types de données : boolean, string,
double, integer, date, array, binary, timestamp
Plusieurs types de données : boolean,
string, double, integer, set, list, map,
tuple, binary, timestamp, counter, uuid
Un document peut contenir d’autres
documents ou avoir des références à
d’autres documents
Pas de type de données très complexe
(l’équivalent de documents dans
documents dans document)

© SOFTEAM Cadextan
OPÉRATIONS
29
Commun
│Indexes secondaires
│CRUD
│Mise à jour d’un sous ensemble de champs possible
│Suppression par TTL
│Intégration avec SOLR ou ElasticSearch pour des recherches complexes
Mongo DB Cassandra
Ajout/suppression/renommage de champs
d’une collection
Ajout/suppression/renommage de colonnes
d’une table
Recherche avec filtre (projection),
multicritères, avec regexp, avec order by,
distinct, count et limit
Recherche avec filtre (projection), multicritères,
avec order by, distinct, count, limit, in, contains
Requètage via json Requètage Thrift ou CQL

MATURITÉ
MongoDB
│Documentation claire est structurée : http://docs.mongodb.org/manual/
│Support gratuit (Google Forum) ou payant (MongoDB, Inc)
│Formation en ligne gratuite ou formation physique payante
│Solution NoSQL la plus utilisée
Cassandra
│Documentation dans http://www.datastax.com/documentation/cassandra/2.1/index.html
│Support gratuit (Forum, mailing lists) ou payant (Datastax)
│Formation en ligne gratuite : https://academy.datastax.com/ ou formations payantes
│CQL simple à utiliser : http://www.datastax.com/documentation/cql/3.1/cql/cql_intro_c.html
│Solution très mature et répandue
30

USE CASES
31
MongoDB
│Vue intégrée des données (plusieurs silos), internet of things (capteurs, etc.), applications mobiles,
analyse de données temps réel, personnalisation, catalogue de produits, portail (gestion de
contenus)
Cassandra
│Smart utilities (eau, énergie), détection de fraude, big data (CERN), messagerie/téléphonie, séries
temporelles, internet of things (capteurs, etc.), recommandation, personnalisation, catalogue de
produits, e-commerce, gestion/partage/streaming de chansons, gestion de vidéos diffusées sur
internet, cours en ligne

BEST PRACTICES
32
Pas de virtualisation, utilisation des disques locaux, de préférence SSD, RAM plus
important que CPU
MongoDB
│http://info.mongodb.com/rs/mongodb/images/MongoDB_Operations_Best_Practices.pdf
Cassandra
│ http://www.datastax.com/wp-content/uploads/2014/04/WP-DataStax-Enterprise-Best-Practices.pdf

Questions???
MERCI
33

NoSQL panorama - Jean Seiler Softeam

Contenu connexe

Tendances

Similaire à NoSQL panorama - Jean Seiler Softeam

Plus de TelecomValley

NoSQL panorama - Jean Seiler Softeam