Premières analyses / impressions sur les sytèmes base de données NoSQL

1. Premières analyses / impressionssur 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

4. Suppression table origami 1 / 1000 ... ...

5. 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

6. 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 Genes Syntenies 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 * 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) ~ SQL, >> NoSQL “Colonnes” - 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 * 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, ...)