Premières analyses / impressionssur 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
TablesNbre
tuples (Milliard)
Disk Usage table + indexes
Tps Parsing + Insertion dans bdd
Dont tps psql
insertion
Homologies 17 3.2 TB + 3.4 TB
~2 mois ~3J
Alignment_pairs 1.89
345 GB + 357 GB ?? ~8H
Alignments 1.35 245 GB + 254 GB
?? ~5H
Suppression table origami
...
...
1 / 1000
Pour les 2 autres tables :Navigation en eau connue
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
TablesNbre
tuples (Milliard)
Disk Usage table + indexes
Tps Parsing + Insertion dans bdd
Dont tps psql
insertion
Alignment_pairs 1.89
345 GB + 357 GB ?? ~8H
Alignments 1.35 245 GB + 254 GB
?? ~5H
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 GenesSyntenies_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”,...
NoSQL “colonne” dénormalisé
Syntenies Genes
Comparaison PostreSQL - Cassandra
Postresql Cassandra
Nbre tuples ~1.5 M ~11 M ~1.5 M ~11 Million
Tps insertion DB 12.8 s1.5 min
27.5 min 3.20 H
Disk usage table 289MB 2GB564 MB
-> ?2.3 GB -> 683 MB
Disk usage ~8 index 300MB 2.1GB 3.5MB 25 MB
Tps SELECT clé primaire
~0.5-12ms * ~5 ms
Tps SELECT autre index
~0.5-12ms * ~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
- 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”
Philosophie NoSQL “Documents” (suite)
Comparaison PostgreSQL - MongoDB
* Rapide si disk pages cached dans RAM, plus long sinon...
Postresql MongoDB
Nbre tuples ~1.5 M ~11 M ~1.5 M ~11 M
Tps insertion DB 12.8 s 1.5 min 2.5min 17.5min
Disk usage table 289 MB 2 GB 1 GB 7.2 GB
Disk usage ~8 indexes 300 MB 2.1 GB 54.7 MB 382 MB
Tps SELECT non chemin index (1 fois)
~0.5-12ms *
250 ms
Tps SELECT avec chemin
index
~0.5-12ms *
0 ms
Les systèmes NoSQL type “Graphs”(ex Néo4J)
Philosophie NoSQL “Graphs”Relationnelle
NoSQL “Graphs”
Syntenies GenesSyntenies_genes
S
GG
G
- 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, ...)