1 / 102

Manipulations Multibases et Distribuées Partie 3

Manipulations Multibases et Distribuées Partie 3. Witold Litwin Witold.Litwin@dauphine.fr. SQL Serve r 2008. Architecture MBD générale similaire à celle de MsAccess , en plus puissante passerelles vers Oracle, DB2 ODBC et donc MsAccess

pepper
Télécharger la présentation

Manipulations Multibases et Distribuées Partie 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

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

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

  42. Solutions

  43. 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 ?)

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

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

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

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

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

More Related