formation nosql

Formation NoSQL

Ceci est un extrait d’un formation NoSQL disponible sur

http://www.eisiform.com/nosql/

Avant propos : NoSQL n’est ni une évolution, ni une révolution !

C’est simplement de nouvelles opportunités.

I - Introduction au NoSQL

[…] Des slides sont sautés

4. Stocker les données en fonction des intentions d’usage

I-4. Penser usage

Quels objectifs ?

- Comprendre la notion d’usage de la donnée

- Avoir une première vision de la modélisation des données en fonction de l’usage

I-4. Penser usage

- Quelles sont les conséquences d’une mauvaise modélisation de la donnée

La chocolaterie

I-4. Penser usage

La chocolaterie

?I-4. Penser usage

Le relationnel dans la réalité

Mon article de blog

Commentaires

Table articles

Table commentairesTable utilisateurs

I-4. Penser usage

Mon article de blog

Commentaires

Le NoSQL dans la réalité

I-4. Penser usage

Stockage de donnée déjà packagées

Titre : Mon article de blog

Contenu :

Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ]

Une modélisation loupée

Contenu :Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ]

Comment récupérer les 10 derniers commentaires postés sur le blog ?

Contenu :Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … }]

A retenir

Le NoSQL demande de penser usage

Impossible de créer le schéma de la donnée sans connaitre l’expérience utilisateur finale.

NoSQL est très performant pour un usage précis

En packageant toutes les données relatives à un usage précis, NoSQL ne requête qu’un emplacement au lieu de « n » emplacements.

I-4. Penser usage

Le modèle relationnel est plus flexible

Dans le modèle relationnel, la donnée peut être assemblée à souhait quelque soit la demande.

En NoSQL, un besoin non anticipé peut coûter très très cher en temps et donc en performance.

5. Différence entre le NoSQL et le Big Data

I-5. NoSQL et BigData

Pourquoi s’intéresser au Big data ?

- Comprendre en quoi NoSQL est un outil de choix pour le Big Data

- Savoir distinguer la limite entre Big Data et NoSQL

- Saisir l’étendu du Big Data

Qu’est ce que le Big Data ?

Manipulation de très gros volumes de données provenant de sources hétérogènes.

Big data :

- Gros volume de données

PROBLEME

- Besoin de performance dans le traitement et la manipulation des données

CONSEQUENCE

- Besoin de machines en cluster

- Besoin d’un design de la donnée performant et donc pensé en fonction de l’usage plutôt que des relations

SOLUTION

- Données provenant de sources hétérogènes.

PROBLEME

- Besoin d’un design de donnée semi-structuré plutôt que structuré.

SOLUTIONNoSQL

- Données non structurée que l’on va essayer d’organiser pour pouvoir les traiter.

CONSEQUENCE

- La diversité initiale empêche de respecter un format rigide de donnée finale.

II - La scalabilité des bases de donnée

2. Le théorème de CAP

II-2. Théorème de CAP

Finalement, CAP revient à dire…

Partitionnement (tolérance aux pannes)

Disponibilité

Cohérence

Mais dans la réalité, tout est en nuance…

Disponibilité

Cohérence

Et en posant le problème autrement…

Temps de réponse

Cohérence

Temps réel

Sécurité

C’est LE problème.

D’ou vient exactement ce temps de réponse ?

Crédits: kleppmann.com II-2

C dans CAP est différent de C dans ACID

ACID Cohérence de la donnée à l’échelle d’un seul noeud.

CAP Cohérence de la donnée à l’échelle d’un cluster.

Le cluster recherche de la stabilité

• Lorsque la donnée est cohérente dans le cluster, tous les noeuds renvoient le même contenu à la lecture.

• Le problème survient lorsqu’une requête insère une nouvelle donnée et que celle-ci doit être propagée dans les réplicas.

La différence entre Relationnel et NoSQL

• Relationnel est normalisé donc les transactions sont essentielles et très fréquentes. Utilisation intensive de l’ACID.

• Or l’ACID sur un cluster est coûteux en temps

• Il scale plus ou moins facilement sur un cluster en fonction du niveau de cohérence demandé

RelationnelNoSQL

• NoSQL est pensé pour limiter le nombre de relations entre les tables donc limiter le besoin de l’ACID. Donc plus performant.

Les bases de donnée en fonction de la cohérence

Disponibilité

Tolérant aux pannesCohérence

CouchDb Cassandra

RiakMysql

PostgreSQL

CouchBase Mongodb

HBaseII-2. Théorème de CAP

4. Architecturer le cluster : Distribution et duplication des

données

II-4. Sharding et replication

Duplication : Replica-set

Master

READREAD

WRITEWRITE

SlaveSlave

Slave SlaveREADREAD

Slave MasterREADREAD

Distribution : Sharding

product facture, order users

productfacture, order users product facture, orderusers

Distribution : Sharding

Minimum pour 75 Go sur 3 shards25 Go 25 Go 25 Go

25 Go 25 Go 25 Go

- 6 serveurs pour les données - 3 serveurs arbitres

III - Développer avec NoSQL

III-2. Points communs

2. Points communs entre les bases NoSQL

Quel points communs à toutes les bases NoSQL ?

Aucun.

Quel points communs à la plupart des bases NoSQL ?

- Un schéma implicite

- L’absence de relations

- L’absence du language SQL

- L’open source

III-3. Modélisation

3. Modélisation de la donnée

Rappel : Fonctionnement des bases relationnelles

- Support de l’ACID (transactions)

- Aucune redondance des données

- Des entités décrites par des métadonnée fortement typées

- Utilisation de jointures

- Les entités sont liées par des relations

- Les métadonnées ne sont pas dupliquée à chaque ligne

Rappel : Distribution et duplication en NoSQL

- Distribution de la donnée

Factures Clients Produits

Produits FacturesClients

- Replication de la donnée

Serveur 1 Serveur 2 Serveur 3

Factures Clients Produits

Produits FacturesClients

Serveur 1 Serveur 2 Serveur 3

Problème : Partitionnement des données

Dans ce cas de figure les jointures ne sont pas performantes

Solution apportée par le NoSQL

La donnée contient l’intégralité des informations nécessaires pour une requête.

agrégat

La notion d’agrégat

- Une unité d’information complexe et isolée (semi-structurée)

- Identifiée par un élément racine (id)

- Traité / Stocké / Echangé de manière atomique

- On y accède uniquement par la racine

L’agrégat en NoSQL

- Rapide car pas d’agrégat à construire lors de la requêteAVANTAGES

INCONVENIENT

- Entraine la duplication des données

- Plus besoin de transaction car l’agrégat est atomique avec lui même

- Des données à mettre à jours à plusieurs endroits

- L’agrégat est désignée pour un usage précis et peu flexible

L’agrégation via les requêtes SQL

- Extrême flexibilité dans le requêtage des donnéesAVANTAGES

INCONVENIENT

- Besoin de transactions pour modifier les différentes tables en « simultané »

- Aucune redondance de la donnée, ni des métadonnées

- Lenteur de l’exécution de la requête du à la formation de l’agrégat

- Difficulté pour distribuer la donnée sur le cluster, dû aux dépendances entre les tables

III-4. Inconvénients

4. De nouvelles problématiques de développement

Problématique 1 : Schéma implicite

{ name: "Franck", age: 20 }

{ name: "Franck" }

{ name: "Franck", age: "20" }

{ book: "Colère de l’ombre", publication: 2005 }

Problématique 2 : Requêtage propriétaire

db.collection.find( {} )

MATCH (all) RETURN all

GET /collection

DESCRIBE keyspaces;

MongoDb

CouchDB

Cassandra

Problématique 3 : Plus de normalisation

- Des données peuvent être dupliquées

- Les update / insert / delete doivent être réalisé à plusieurs endroits

- Des scripts batch peuvent vérifier l’état de la donnée ou la corriger

Problématique 4 : Gestions des transactions ACID

Problématique 5 : Gestions des modifications concurrentes

IV - Les différents types de bases

IV-1. Clé-valeur

1. Bases clé-valeur

IV-1. Clé-valeur

RAM : Hash map sessionSession 1 -> JérémieSession 2 -> FrédéricSession 3 -> John

Request -> Session 3

Le besoin : Mémoire partagée

IV-1. Clé-valeur

S3Load

rRequest -> Session 3

Session 1 -> JérémieSession 2 -> Frédéric

Session 3 -> JohnSession 4 -> Franck

Session 5 -> JohnSession 6 -> Franck ?

RAM : Hash map session

Le besoin : Mémoire partagée

Autre besoin : Queue

- Envoi d’email est très lent

- Inscription -> Email de validation

- Envoi de l’email en différé

IV-1. Clé-valeur

Cas d’utilisation

Découverte de Redis

IV-1. Clé-valeur

set "formation:the.mail.queue:state" "enable"

Commande redis

Clé respectant le standard Valeur

Découverte de Redis : Types de données

IV-1. Clé-valeur

- String (set, get, incr, incrby…)

- List (lpush, rpush, lindex, lrange…)

- Hash (hset, hmset, hget…)

- Set (sadd, sdiff, sunion…)

- Sorted set (zadd, zscore, zrange…)

VI-2. Colonnes

2. Bases colonnes

Cas d’utilisation

Fonctionnalité Ebay : Likes, Own, Want

Fonctionnalité Ebay : Exemple des likes

Crédits : Ebay Tech blog

Fonctionnalité Ebay : Performances finales

Mysql : ~ 3 ms / requête Cassandra : ~ 0.12 ms / requête

IV-3. Documents

3. Bases documents

IV-3. Documents

Les besoins

- Création d’entités classique (user, facture, produits…)

- Une majorité de requête read et peu en write

- Savoir à l’avance les requêtes que l’on va faire

+ Populaire

IV-3. Documents

Les bases du modèle de donnée

- Base de donnée -> Collection -> DocumentsBase de donnée Table Rows

- Donnée semi-structurées en JSON{ user: jeremie, hobbies: [technologie, sport]}

Construction du modèle d’un blog

- Afficher l’article sur la page article et les 10 premiers commentaires. Charger les suivants si l’utilisateur scroll.

- Afficher le résumé des 5 derniers articles sur la page d’accueil, le top 3 des articles et les 2 derniers commentaires

- Les auteurs peuvent se connecter pour rédiger des articles et ont un ou des rôles spécifiques (admin, rédacteur, correcteur…)

IV-3. Documents

- Lister les articles d’un auteur

IV-4. Graphes

4. Bases graphes

Besoin : Relations nombreuses et complexes

Relation bi-directionelle

Relation directionelle

Entité de type différent

Personne Voiture

Relation qui a plus de poids

Emprunte à

Relation nommée

Pourquoi choisir une base graphe ?

- Facilité de requêtage dans le graphe

- Haute performance sur les graphes

- ACID + Forte cohérence dans le cluster

IV-4. Graphes

V - Vers le NewSQL ?

V-3. Etat du NewSQL

1. Notion de NewSQL

Google Megastore

We believe it is better to have application programmers deal with performance problems due to overuse of

transactions as bottlenecks arise, rather than always coding around the lack of transactions.

V-1. Notion de NewSQL

Le NewSQL aujourd’hui

V-1. Notion de NewSQL

V-2. In-Memory et BigData

3. NewSQL in-memory et BigData

Usage classique de VoltDB

Un important flux de données entrantesIngère

Nécessite un traitement par évènement pour analyser les résultats en temps réel.

AnalyseDécide

Exporte les données vers une base persistence pour du stockage ou du batch ultérieur par exemple(Export)

Crédits : VoltDB

Big Data streaming architecture

VI - Elastic Search

1. Particularités de la base Elastic Search

VI-1. Spécificités Elasticsearch

Elastic Search

- Bâti autour de Apache Lucene

- Ajoute la persistence (stockage) des données à Lucene

- Simplifie la configuration et unifie / approfondit le requêtage

- Base de donnée document NoSQL ayant un index inversé

2. Expérimentations sur elastic search

VI-2. Expérimentations

Indexation, Requêtage, Filtrage, Facette, Aggrégation, géolocalisation, catégorisation…

Ceci est un extrait d’un formation NoSQL disponible sur

http://www.eisiform.com/nosql/

formation nosql

Technology

wmware nosql

nosql sharing

nosql 2000

jakarta nosql

nosql consepts

nosql orientado à documentos. apresentação nosql...

nosql basics

nosql & sql

nosql now: postgres - the nosql cake you can eat

nosql & relax with...

nosql - hypergraphdb

artigo nosql

manual cassandra nosql

bigdata - nosql

survey on nosql

nosql solutions

Велосипедостраительство в nosql,...

nosql adatbázis-kezelők

nosql sunumu

bd nosql tecnicas