07 big data sgbd

1. Big Data
BASES DE DONNÉES

2. Des données
 Une mesure
 Un modèle => c’est-à-dire une représentation de la réalité physique
 Une donnée => on stocke, range le tout
2

3. Sommaire
 Les bases relationnelles
 Le grand classique
 Les base orientées documents
 On stocke des documents, en vrac
 Les bases colonnes
 On historise
 Les bases graphe
 On s’intéresse aux relations entre des données
 Les bases temporelles
 Des valeurs en fonction du temps
 Bases sémantiques
 Web sémantiques, données RDF
3

4. Un exemple
 Pierre
 une personne
 une entité
 Des propriétés
 Prends l’avion à 15h00
 une action
 une relation
 Une propriété
 Pour Paris
 Un lieu
 Une entité
 Des propriétés
4

5. The table
Personne (nom) Moyen Heure Destination
Pierre Avion 15 Paris
Paul Train 12 Marseille
Jacques Voiture 11 Rome
5

6. Bases relationnelles
 P.ex. Oracle, MariaDb, MySQL
 Ce sont des bases
 Relationnelles : on peut établir des relations entre entités et les requêter ensuite
 Transactionnelles : on assure la cohérence des données écrites au sein d’une
transaction, en cas de souci, tout est rejeté
 Elles disposent d’un langage de requêtage : Standard Query Langage (SQL)
très largement répandu
 Réplication maitre-esclave
6

7. Bases relationnelles 7
SELECT p.nom, m.nom, m.heure, d.destination
FROM Personne p
JOIN moyen_de_transport ON p.personneId=m.PersonID
JOIN destination d ON d.destinationID=m.destinationID
p.nom m.nom m.heure d.destination
Pierre avion 15 paris

8. 8

9. Force des SGBD classiques
 Le modèle est indépendant du stockage disque
 Requêtes pouvant être complexes ( parcours sup p.ex.)
 Optimisation des requêtes par des index
 Stables, mur, interfaces disponibles
 Contraintes d’intégrité (un prix doit être >0)
 Gestion efficace de gros volumes de données
 Transactions :
 Gère les accès concurrents
 Reprise sur panne
9

10. ACID
 Atomicité : l’ensemble des opérations est réalisé en bloc, annulée en bloc
 Cohérence : les transactions respectent les contraintes du modèle créé par
l’utilisateur
 Isolation : Deux exécutions concurrentes renvoie le même résultat que
deux exécutions à la suite
 Durabilité : une fois la transaction terminée, les données sont pérennes
10

11. Inconvénients des SGBD classiques
 Ne permettent pas de gérer des TRES gros volumes de données (To)
 Limitée par la vitesse des accès disque (ou SSD plus chers)
 Le modèle relationnel n’est pas adapté aux données
 Peu structurées
 Pas structurées
 Hiérarchiques
 Les propriétés ACID :
 Consomment des ressources
 Diminuent les performances
11

12. Bases NoSql
 Not Only SQL
 Certains compromis sont différents de ceux des bases SQL
 Modèles de données spécialisés dans certaines taches
 Souvent les propriété ACID sont abandonnées
 Quelques exemples :
 XML : données hiérarchiques
 Objet : données complexes avec données et méthodes
 Graphes : graphes avec nœuds, arrêtes, propriétés
 Triplets : Triplets RDF du WEB sémantique
 Clef-valeur : une valeur associée à un identifiant
12

13. Bases orientées documents
 Elles sont efficaces pour gérer de grands nombres de documents
 Pas de contraintes sur le format du document
 On retrouve un document pas son identifiant
 Pb : trouver le bon identifiant
 Par exemple MongoDb
 Souvent les documents sont écrits en json ou XML
 Requêtes très simples : PUT, GET
 De fait s’utilise souvent avec un moteur de recherche, qui indexe les
documents pour retrouver ensuite leur Id (SolR, ElasticSearch)
13

14. Bases orientées documents 14
Db.voyages.save({
_id :abb72107-2d4f-40b1-ba09-095b8d1fcf2f,
Nom: pierre,
moyen_de_transport: {
Nom: avion,
Heure : 15
},
Destination : paris
})
Db.voyages.find({
Nom: Pierre
})
{" Nom " : " pierre "," Destination" : "paris " , "
moyen_de_transport " : {" nom " : " avion " , " heure « : 15 }}

15. Base orientée colonnes
 Au lieu de stocker les données lignes par lignes, on les stocke colonne par
colonne
 Modèle plus riche que clef-valeur
 Rend très efficace l’agrégation sur une colonne
 Rend difficile la mise à jour (UPDATE) d’un document
 Passage en mode distribué très très simple
15

16. Structure d’enregistrement 16

17. Base graphe 17
CREATE (p:Personne {nom:Pierre})
-[u:UTILISE_POUR_ALLER{nom:avion, heure:15}]
->(d:Destination (Destination:Paris)}
MATCH (p:Personne)-[u:UTILISE_POUR_ALLER]-(d:destination)
RETURN p,u,d

18. Graphe plus complexe 18

19. Comparatif structures 19
Personne (nom) Moyen Heure Destination
Pierre Avion 15 Paris
Paul Train 12 Marseille
Jacques Voiture 11 Rome

20. Base de séries temporelles
 Le but est de stocker et de requêter facilement des séries temporelles
 L’exemple choisi n’est pas pertinent ici, il faut quelque chose du genre
 1447160880026027773 ns370781.ip-91-121-193.eu ping.ovh.net 4.346
 Une date (timestamp) et des champs de données
 Il est facile de de gérer ce type de données, et en particulier la durée de rétention
(paramétrée à la création de la table
 Une piste : InfluxDb (de la stack TICK)
20

21. TICK 21

22. Dans quels cas choisir un SGBD non classique
 Quand les besoins de débit ou de latence sont prépondérants
 Quand les volumes de données sont énormes
 Quand le modèle relationnel ne fonctionne plus (c’est rare)
 Quand on a besoin de performances plus élevées
 Quand le cout d’un SGDB performant devient prohibitif pour le besoin
 Ne pas oublier ce que l’on perd (ACID) même s’il y a des parades
 Attention à ne pas surestimer le besoin NoSQL
 Il y a des architectes dans les entreprises, c’est leur métier de faire ce genre
de choix
22