NoSQL panorama - Jean Seiler Softeam

Faites de votre projet un succès

© SOFTEAM Cadextan

PANORAMA

NOSQL

Jean Seiler

[email protected]

mailto:[email protected]

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

C Consitency

A Availability

P Partition 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/Box Maxtable 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 HyperGraphDB DEX 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 Scale MckoiDDB Mckoi SQL Database

Oracle Big Data Appliance Innostore FleetDB No-List KDI Perst IODB

QUELLE SOLUTION CHOISIR???

9 NoSQL

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

https://twitter.com/TechConfQuiz

https://twitter.com/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.


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

http://docs.mongodb.org/manual/

http://www.datastax.com/documentation/cassandra/2.1/index.html

https://academy.datastax.com/

http://www.datastax.com/documentation/cql/3.1/cql/cql_intro_c.html


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

http://info.mongodb.com/rs/mongodb/images/MongoDB_Operations_Best_Practices.pdf

http://info.mongodb.com/rs/mongodb/images/MongoDB_Operations_Best_Practices.pdf

http://www.datastax.com/wp-content/uploads/2014/04/WP-DataStax-Enterprise-Best-Practices.pdf













Questions???

MERCI

33

NoSQL panorama - Jean Seiler Softeam

Internet

Transcript of NoSQL panorama - Jean Seiler Softeam