Télécharger la présentation
La présentation est en train de télécharger. S'il vous plaît, attendez
Publié parClaire Landais Modifié depuis plus de 9 années
1
Premières analyses / impressions sur les sytèmes base de données NoSQL
Thomas Lacroix, MIG
2
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
3
Estimation par extrapolation
Tables Nbre tuples (Milliard) Disk Usage table + indexes Tps Parsing + Insertion dans bdd Dont tps psql insertion Homologies 17 3.2 TB TB ~2 mois ~3J Alignment_pairs 1.89 345 GB GB ?? ~8H Alignments 1.35 245 GB GB ~5H
4
Suppression table origami
1 / 1000 ...
5
Pour les 2 autres tables : Navigation en eau connue
Nbre tuples (Milliard) Disk Usage table + indexes Tps Parsing + Insertion dans bdd Dont tps psql insertion Alignment_pairs 1.89 345 GB GB ?? ~8H Alignments 1.35 245 GB GB ~5H Notre table homologies actuel (860 éléments) fait 1.5 milliard de tuples / 285 GB GB ~ même ordre de grandeur que estimation pour tables alignments et alignment_pairs
6
Mais si pas possible supprimer table homologies
Mais si pas possible supprimer table homologies... →Avantages des systèmes NoSQL - Extensibilité données - Haute disponibilité (Réplication / Partionnement)
7
Les familles de systèmes de base de données
(Ex : Neo4J) (Ex : Postgresql) (Ex : MongoDB) (Ex : Cassandra)
8
Les systèmes NoSQL type “Colonnes” (ex Cassandra)
9
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)
10
Schéma NoSQL “colonnes” dénormalisé
SQL Relationnelle NoSQL “colonne” dénormalisé Syntenies Syntenies_genes Genes 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”,...
11
Comparaison PostreSQL - Cassandra
Nbre tuples ~1.5 M ~11 M ~11 Million Tps insertion DB 12.8 s 1.5 min 27.5 min 3.20 H Disk usage table 289MB 2GB 564 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 ~ ms * Rapide si disk pages cached dans RAM, plus long sinon...
12
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 ?
13
Les systèmes NoSQL type “Documents” (ex MongoDB)
14
Philosophie NoSQL “Documents”
Données = Objets JSON - Syntaxe ~ programmation orientée objets - Soit objets imbriqués →dénormalisation
15
Philosophie NoSQL “Documents” (suite)
- Soit référence aux objets→normalisation
16
Philosophie NoSQL “Documents” (suite)
- Group by et aggregation ~ SQL, >> NoSQL “Colonnes” - Auto-increment (clé primaire _id ajoutée automatiquement) - Sans-schéma != SQL, ~ NoSQL “Colonnes” - Pas de transaction / roll back ; atomicité au niveau des tuples individuels uniquement << SQL, ~ NoSQL “Colonnes”
17
Comparaison PostgreSQL - MongoDB
Postresql MongoDB Nbre tuples ~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 ms * Rapide si disk pages cached dans RAM, plus long sinon...
18
Les systèmes NoSQL type “Graphs” (ex Néo4J)
19
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”, ...)
20
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, ...)
Présentations similaires
© 2024 SlidePlayer.fr Inc.
All rights reserved.