Manipulations Multibases et Distribuées Partie 3

1. Manipulations Multibases et DistribuéesPartie 3 Witold Litwin Witold.Litwin@dauphine.fr

2. SQL Server 2008 • Architecture MBD générale similaire à celle de MsAccess, en plus puissante • passerelles vers Oracle, DB2 • ODBC et donc MsAccess • Le langage Transac-SQL supporte plusieurs fonctions de MSQL • Est le dialecte MBD le moins procédural de l'industrie

3. SQL Server 2008 • Requêtes élémentaires • Aux BDsd'un même site USE B ;select * from T whereB1.S.T1.a = T.a ; • S signifie schéma • En général, S est un nom d’usager • Une seule base par USE • Quelques restrictions au niveau de requêtes interbases

4. SQL Server 2008Autres Possibilités Multibases • Commandes CREATE TABLE ou VIEW • Déclencheurs (triggers) • CREATE TRIGGER ... • Ces derniers réalisent les dépendances MDB • Notamment, la clause CONSTRAINT n’est pas multibase • Les déclarations usuelles de contraintes d’intégrité réf. par cette clause ne peuvent être que monobases

5. SQL Server 2008Autres Possibilités Multibases • Les procédures stockées • Les bases peuvent être sur des nœuds (SGBDs) différents • Sur différentes machines réelles ou virtuelles • Les noms des bases externes / USE doivent être précédées alors par les chemins d’accès et les noms de nœuds. • Sous forme N.B.S.T

6. SQL Server 2008 Autres Possibilités Multibases • Les nœuds doivent alors être liés • « Linkednodes » • Un lien permet de déclarer l’URL, le nom d’usager, mot de passe de connexion… • On peut créer les liens par • Une procédure stockée • Interface de commande • SQL Server Management Studio • Interface Interactive

7. Exécution de Requêtes Multibases • Bases sur le même nœud • Mêmes règles que pour une requête monobase • Bases distribuées • On minimise le temps/volume réseau • Sélections, projections jointures monobases sur les bases sources dès que possible • Jointures multibases sur la base cible • Agrégations finales aussi

8. Exécution de Requêtes Multibases • Exemple générique • Use B0 • Select R.A, X.B • From R, B1.R1 X • Where • R.C = V1 and X.D = V2 and R.E = X.E

9. Exécution de Requêtes Multibases • Plan d’exécutiontypique • Q1: Use B1 • Select X.B, X.E Into B0.T • From B1.R1 X • Where X.D = V2 • Q2: Use B0 • Select R.A, T.B • From R, T • Where T.D = R.D and A = V1

10. Exécution de Requêtes Multibases • La clause INTO T peut être réalisée sous forme: • Open Cursor… • Fetch… • En utilisant les commandes ODBC • Le plan typique peut être amendé • Par semi-jointures (Ph. Berstein, MSR) • Ou pour TOP k…. • Voir aussi l’article de Sonia & al dans le matériel de support

11. Exécution de Requêtes Multibases • Semi-jointure • La base B1 doit recevoir une table T2 de la base B2 sur un autre nœud, pour l’équijointure interne avec une table T1 sur l’attribut X • B1 envoie à B2 d’abord la projection de T1 sur X seul • B2 fait la jointure et renvoie à B1 les tuples pertinents • A fini la jointure avec les autres attributs sélectionnés de T1 • Le tout peut diminuer le coût de la jointure MBD par rapport à la stratégie typique

12. Exécution de Requêtes Multiples • Les requêtes résultantes sont en général parallèles • On peut afficher la progression • Le Choose (Top k) est poussé vers les bases sources • La construction de la multitable est sur le nœud cible • Y compris l’exécution de MDistinct • Sur URL notamment

13. Exécution de Requêtes Multibases • D’une manière générale, les règles d’optimisation pratique de requêtes MBD restent primaire • On peut faire bien mieux • On en parlera dans le cours de directions de recherche

14. Multibases & BDPs SQL Server • Sous SQL Server une base peut être parallèle (BDP) et être dans une multibase • Supporter donc les manipulations multibases • La base parallèle utilise des vues partitionnées distribuées • Ces vues peuvent même être rendu scalables • On parlera + dans le cours de directions de recherche

15. Base de Données Scalable • La nombre de sites serveurs de la BDS croît dynamiquement avec sa taille • Les tables se repartitionnent d’une manière transparente pour les applications • Pas besoin d’arrêter l’exploitation pour ajouter un nœud et reconfigurer • Souvent un casse-tête pour le DBA • En utilisant les ressources cumulées • TOs de RAM, POs de disques…

16. Base de Données Scalable • Peut s’étendre sur des milliers de sites (PCs & WSs) en utilisant les ressources en commun • Peut être du type P2P • Google parle de 10M de sites bientôt • Projet Spanner • Les sites sont dits « grid » or « cloud » • Voir + loin pour le jargon commercial • Le sites de « cloud » sont en général virtuels

17. Base de Données Scalable • Il s’agit de machines virtuelles créées à la demande dans un « Data Center » • Les sites physiques (CPU & mémoires, dites « Blades » ) sont alloués dans des Data Centers par conteneurs • 1500 à 2500 « blades » par conteneur

18. Base de Données Scalable • L’offre commerciale pointe son nez depuis 2009 • SQL Azur • BD de 10 GO max (2010) • Sur une seule machine virtuelle MS (2010) • Une plaisanterie pour l’instant

19. Base de Données Scalable • Plusieurs SGBDs utilisant Hadoop & MapReduce • En fonctions externes • AsterData • Crée par les étudiants de Stanford • GreenPlum • Transfuges de Sun • ParAcell • Sun/Oracle

20. Base de Données Scalable • Jargon Commercial: • P2P, « GridHosting», «Cloud Computing», « ElasticComputing », « Data Fabrics», Databaseas Service, SaaS… • GemFire (Gemstone) • Amazon EC • Blue Cloud (IBM) • SQL Azure et Windows Azure (MS) • Enomalyhttp://www.enomalism.com/ • Google Apps • Yahoo Pipes • 3Tera http://www.dnseurope.net/

21. Structures de Données Distribuées et Scalables (Infrastructure Cloud) • Partitionnement dynamique transparent au client • par hachage (LH*, Chord…) • par intervalles (RP*) : SDDS-2005 au B019, Google • multi-attribut (k-RP*…) • à tolérance de pannes (LH*sa)

22. Structures de Données Distribuées et Scalables (Infrastructure Cloud) • Accès par clé par le client • Peut subir des renvois entre les serveurs • Idem pour l’accès parallèle • Scanset peut-être Map/Reduce • Voir les cours sur les SDDSs

23. Structures de Données Distribuées et Scalables (Infrastructure Cloud) • Modèles de données • Fichiers clé – valeur • Hadoop, Cassandra, Mango, Voldemort, Pig… • Tables relationnelles • SD-SQL Server, Hive, HadoopDB

24. SD-SQL Server 1er SGBD Scalable Distribué • Utilise le principe des SDDS • Les tables relationnelles se répartissent automatiquement par éclatements sur autant de SD-SQL Servers qu’il faut • La répartition est invisible aux applications • Proto visible sur le site CERIA (vidéo) • Thèse Doctorat de SororSahri (2006) • MdC à Paris 6

25. SD-SQL Server 1er SGBD Scalable Distribué SD-SQL Server Démo par Soror

26. Transactions

27. Transactions

28. Transactions ACID • Opérationsatomiquesinexprimables avec unerequêterelationnelle. • Exécutéesentièrementou pas du tout • Préservant la consistance de la BD • commesil'usagerétaitisolésur la BD • A effetdurablesur la BD, unefoisterminéescommeprévu

29. Primitives de gestion de transactions • BEGIN, COMMIT, ROLLBACK BEGIN TRANSACTION UPDATE Compte1 Val = Val -100 IF SQLCODE <> 0 ROLLBACK ; EXIT ; UPDATE Compte2 Val = Val + 100 IF SQLCODE <> 0 ROLLBACK ; EXIT; COMMIT

30. Concurrence • Les BDs étant partagées, les transactions pourraient être exécutées: • l'une après l'autre • simultanément • meilleures performances • possibilités d'inconsistances dans la base • Théorie de concurrence analyse les problèmes d'accès simultané • En premier: en utilisant les verrous

31. Verrou mortel • Les transactions s'attendent mutuellement (deadlock) • Solution typique: • avorter une de transactions (la victime) • le choix est fait par le gestionnaire des verrous (lock manager)

32. Les exécutions correctes • Sérialisabilité Les exécutions concurrentes sont correctes ssi leur résultat est équivalent à celui d'une exécution sérielle • Le critère naturel et le plus populaire

33. Cas MBDArchitecture de référence

34. Cas MBDArchitecture de référence Transaction Sous- transact. Sous- transact. Sous- transact.

35. Cas MBDArchitecture de référence Coordinateur Participant Participant Participant

36. Quelles transactions ?? • Problème nouveau • Si à l'exécution d'une transaction T • - certaines sous-transactions commettent • - une ou plus avortent • alors l'exécution de T est-elle correcte ou pas ?

37. Quelles transactions ??

38. Verrouillage à deux phases (2PL)

39. 2-PC

41. Solutions • Nouveaux modèles de transactions • Non-ACID et longues en général • Pas de verrous, au moins de verrous longs • Les verrous & les loquets • Ang. Locks & latches) • Transactions imbriquées • Resende, Abbadi • Transactions imbriquées ouvertes • Weikum & Scheck. 

42. Solutions • Compensations • A; Silbershatz (U. Yale) & Korth (?) • Sagas • Hector Garcia Molina (U. Stanford) • Transactions Flexibles • Litwin & Rusinkiewicz (Telcordia)

43. Solutions

45. Problèmes Pratiques • Comment déterminer les dates de valeur • Evitement de "livelock" • Une transaction toujours avortée et relancée • Variantes • Stats sur le temps réel de transactions • Garcia – Molina & al (VLDB 91 ?)

46. Variantes • Gestion de priorités • Chaque répétition d’une transaction augmente sa priorité contre les interruptions concurrentes • Certification sans attentes • On exécute chaque transaction T jusqu’au bout sans attentes • On certifie l’exécution correcte de T

47. Variantes • L’opération teste si il n’a pas de conflit qui aurait avorté T • Si oui, on ré-exécute T • Etc • La certification est un bon choix notamment quand la plupart de transactions ne s’exécutent pas jusqu’au bout • Systèmes de réservation

48. Autres Règles de Priorité • La manipulation de donnée D est selon la sa date de valeur et celle de la transaction venante • L’intérêt de dépôt de 100€ auquel on a ajouté 100€ à 16h30 avec V1 = 18h sera calculé à 17h comme • Celui de100€ par T (V2 = 17h30) • Celui de200€ par T (V2 = 18h30)

49. Site 1 Site 2 T28 T31 20 W31(C) W28 (A) W31 (B) 28 31 t

50. Site 1 Site 2 T28 T31 20 W31(C) W28 (A) W31 (B) W31(A) 28 31 t