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, ...)