Transcript Philosophie NoSQL “Colonnes”

Premières analyses / impressions
sur les sytèmes base de données
NoSQL
Thomas Lacroix, MIG
Contexte
3 tables de notre bdd PostgreSQL Origami grossissent
proportionnellement au carré du nombre d'élements
(nombre de comparaisons croisées)
- Actuellement : 860 éléments→740 milles cc
- En cours : 2900 éléments→8.4 millions cc
Estimation par extrapolation
Tables
Homologies
Alignment_
pairs
Alignments
Disk
Nbre
Usage
tuples
table +
(Milliard)
indexes
Tps
Dont tps
Parsing +
psql
Insertion
insertion
dans bdd
17
3.2 TB
+ 3.4 TB
~2 mois
~3J
1.89
345 GB +
357 GB
??
~8H
1.35
245 GB +
254 GB
??
~5H
Suppression table origami
1 / 1000
...
...
Pour les 2 autres tables :
Navigation en eau connue
Tables
Alignment_
pairs
Alignments
Nbre
tuples
(Milliard)
Disk
Usage
table +
indexes
Tps
Dont tps
Parsing +
psql
Insertion
insertion
dans bdd
1.89
345 GB +
357 GB
??
~8H
1.35
245 GB +
254 GB
??
~5H
Notre table homologies actuel (860 éléments) fait 1.5
milliard de tuples / 285 GB + 300 GB
~ même ordre de grandeur que estimation pour tables
alignments et alignment_pairs
Mais si pas possible supprimer table
homologies...
→Avantages des systèmes NoSQL
- Extensibilité données
- Haute disponibilité (Réplication /
Partionnement)
Les familles de systèmes de base de
données
(Ex : Neo4J)
(Ex : Postgresql)
(Ex : MongoDB)
(Ex : Cassandra)
Les systèmes NoSQL type “Colonnes”
(ex Cassandra)
Philosophie NoSQL “Colonnes”
Pas de "join", "foreign keys" ou sous-requêtes. "GROUP BY"
limité.
→Inhérent au NoSQL "colonne" pour privilegier la performance et
l'extensibilité des données.
2 solutions si problème :
- Simulation multiples requêtes et "join" dans
l'application client →perte de l'aspect performance
- Dénormaliser (recommandé) : 1 table pour chaque
type de requête qui contient toutes les infos
nécessaires (duplication partielle des données)
Schéma NoSQL “colonnes” dénormalisé
SQL Relationnelle
Syntenies
Syntenies
_genes
Genes
NoSQL “colonne” dénormalisé
Syntenies
Genes
Les différentes tables ne se “parlent” pas, mais répète
les informations. Par ex, table “Syntenies” répète infos
“genes”, “organisms”,...
Comparaison PostreSQL - Cassandra
Nbre tuples
Tps insertion DB
Disk usage table
Postresql
~1.5 M ~11 M
Cassandra
~1.5 M ~11 Million
27.5
12.8 s 1.5 min
3.20 H
min
564 MB 2.3 GB ->
289MB 2GB
-> ?
683 MB
Disk usage ~8 index 300MB 2.1GB
3.5MB
25 MB
Tps SELECT clé
primaire
~0.512ms *
~5 ms
Tps SELECT autre
index
~0.512ms *
~22-150 ms
* Rapide si disk pages cached dans RAM, plus long sinon...
Problèmes du NoSQL “Colonnes” pour
notre cas Origami
- Difficile d'avoir des “objets imbriqués”, par example une liste
de qualifiers pour la table gènes...
- 1 table par requête / perte de performance si requêtes non
basées sur clé primaire
→Insyght fait plusieurs requêtes légèrement
différentes sur table alignments, organismes,...
→Beaucoup de duplication de données
CCL : NoSQl “Colonnes” plus adapté pour requêtes /
applications “simples”, pas trop pour Origami / Insyght ?
Les systèmes NoSQL type
“Documents”
(ex MongoDB)
Philosophie NoSQL “Documents”
Données = Objets JSON
- Syntaxe ~ programmation orientée objets
- Soit objets imbriqués →dénormalisation
Philosophie NoSQL “Documents” (suite)
- Soit référence aux objets→normalisation
Philosophie NoSQL “Documents” (suite)
- Group by et aggregation
~ SQL, >> NoSQL “Colonnes”
- Auto-increment (clé primaire _id ajoutée
automatiquement)
~ SQL, >> NoSQL “Colonnes”
- Sans-schéma
!= SQL, ~ NoSQL “Colonnes”
- Pas de transaction / roll back ; atomicité au
niveau des tuples individuels uniquement
<< SQL, ~ NoSQL “Colonnes”
Comparaison PostgreSQL - MongoDB
Nbre tuples
Tps insertion
DB
Disk usage
table
Disk usage
~8 indexes
Tps SELECT
non chemin
index (1 fois)
Tps SELECT
avec chemin
index
Postresql
~1.5 M
~11 M
MongoDB
~1.5 M
~11 M
12.8 s
1.5 min
2.5min
17.5min
289 MB
2 GB
1 GB
7.2 GB
300 MB
2.1 GB
54.7 MB
382 MB
~0.5-12ms
*
250 ms
~0.5-12ms
*
0 ms
* Rapide si disk pages cached dans RAM, plus long sinon...
Les systèmes NoSQL type “Graphs”
(ex Néo4J)
Philosophie NoSQL “Graphs”
Relationnelle
NoSQL “Graphs”
G
S
G
G
Syntenies
Syntenies
_genes
Genes
- Les tuples (~ objets) sont éclatés
- Les liaisons entre objets (lignes jaunes) peuvent
être des entités et avoir des attributs (ex :
“contain”, “is_a”, ...)
Avantages / limites à priori des NoSQL
“Graphs”
Bon pour :
- Représentation de réseaux (Facebook,...)
- Déterminer un chemin ou patron entre des entités
(Mappy,...)
Moins bon pour :
- Retrouver un ensemble d'objets avec des
attributs définis (ex : liste des gènes
appartenant à une synthénie, ...)
- Regrouper des objets selon différents critères (ex
: somme des scores de toutes les synthénie
d'une région génomique, ...)