Transcript MBD3-10

Manipulations Multibases et
Distribuées
Partie 3
Witold Litwin
[email protected]
1
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
2
SQL Server 2008
Requêtes
élémentaires
– Aux BDs d'un même site
USE B ;
select * from T where B1.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
3
SQL Server 2008
Autres 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
4
– Les déclarations usuelles de contraintes
d’intégrité réf. par cette clause ne peuvent
être que monobases
SQL Server 2008
Autres 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
5
SQL Server 2008
Autres Possibilités Multibases

Les nœuds doivent alors être liés
– « Linked nodes »
 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
6
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
7
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

8
Exécution de Requêtes Multibases
 Plan
d’exécution typique
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
9
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
10
Exécution de Requêtes Multibases
 Semi-jointure
 La base B1
11
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
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

12
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

13
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
14
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…
15
15
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
16
16
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
17
17
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
18
18
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
19
– Sun/Oracle
19
Base de Données Scalable
• Jargon Commercial:
» P2P, « Grid Hosting», «Cloud Computing», « Elastic
Computing », « Data Fabrics», Database as Service, SaaS…
 GemFire
(Gemstone)
 Amazon EC
 Blue Cloud (IBM)
 SQL Azure et Windows Azure (MS)
 Enomaly http://www.enomalism.com/
 Google Apps
 Yahoo Pipes
20  3Tera http://www.dnseurope.net/
20
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)
21
21
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
– Scans et peut-être Map/Reduce
Voir
22
les cours sur les SDDSs
22
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
23
23
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 Soror Sahri (2006)
» MdC à Paris 6
24
24
SD-SQL Server
1er SGBD Scalable Distribué
25
SD-SQL Server Démo par Soror
25
Transactions
 C o n trô le d e co n cu rren ce et d e co n sisten ce:
 E n p résen ce d 'au to n o m ie
 E n ab sen ce d e co n trô le cen tralisé (g lo b al)
26
Transactions
 C o n trô le d e co n cu rren ce et d e co n sisten ce:
 E n p résen ce d 'au to n o m ie
 E n ab sen ce d e co n trô le cen tralisé (g lo b al)
27
Transactions ACID
 Opérations
atomiques inexprimables avec
une requête relationnelle.
– Exécutées entièrement ou pas du tout
 Préservant
la consistance de la BD
 comme si l'usager était isolé sur la BD
 A effet durable sur la BD, une fois
terminées comme prévu
28
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;
29
COMMIT
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é
30
– En premier: en utilisant les verrous
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)
31
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
32
Cas MBD
Architecture de référence
A pp
M DB
TM
A pps
locales
A pps
locales
TM
33
TM
TM
Cas MBD
Architecture de référence
A pp
M DB
Transaction
TM
A pps
locales
A pps
locales
SousTM
transact.
34
SousTM
transact.
SousTM
transact.
Cas MBD
Architecture de référence
A pp
M DB
Coordinateur
TM
A pps
locales
A pps
locales
Participant
TM
35
Participant
TM
TM
Participant
Quelles transactions ??
 C ritères d e réferen ce :
S érialisab ilité ?
A C ID ?
Tem p s glob al ?

• 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 ?
36
Quelles transactions ??
 Réponse industrie de BDs relationnelles
 Pas correcte
 Il faut le modèle ACID
 Solutions techniques
 Vérouillage à deux phases (2-phase
locking)
 Committement à deux phases (2-phase
commit)
 Base de temps global (DCE)
37
Verrouillage à deux phases (2PL)
 1-ère phase : tous les verrouillages
 Partagés ou exclusifs
 2-ème phase : tous les déverrouillages
 2-ème phase est le +souvent après le
commit (strict 2-PL). Pourquoi ?
 Problème:
 Verrou mortel (2-PL)
 Mal adapté aux transactions longues
38
2-PC
 L e coord in ateu r en voie les N sou stran saction s et atten d N m essages E O T s
(en d -of-tran saction )
 A lors, il en voie N m essages V ote
 C h aq u e p articip an t jou rn alise sa sou stran saction et si tou t est O K , alors
en voie le m essage R T C (read y-tocom m it)
 S i N m essages R T C son t reçu s, alors le
coord in ateu r en voie le m essage C om m it
39
 Avantages
 Atomicité garantie
 Simplicité
 Problèmes
 Blocage (tout participant attend
indéfiniment un message)
 A quel moment ?
 Nombre de messages échangés
 Protocole de terminaison
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
41
 Weikum & Scheck.
Solutions
•Compensations
•A; Silbershatz (U. Yale) & Korth (?)
• Sagas
•Hector Garcia Molina (U. Stanford)
•Transactions Flexibles
•Litwin & Rusinkiewicz (Telcordia)
42
Solutions
 Dates de valeur
 Litwin & Tirri (Nokia Res. Cntr, Palo Alto)
 Toute transaction T est munie d'une date de valeur V
unique (par l'application ou le système)
 quand la date V arrive, la transaction doit être terminée
 sinon elle est avortée par le système
 Règle de priorité basique
43
 toute T estampille toute donnée D utilisée avec V.
 dans le cas d'un conflit d'accès à D, la priorité va à T
avec V minimal.
 si une transaction T2 avec V2 > V avait déjà
estampillé D, alors T2 est localement avortée
et attend la fin de T.
 Sinon, T attend la fin de T2
 Ou fait une action »App. Dependent »
 Propriétés intéressantes:
 Jamais de verrou mortel
 Possibilité de commitement implicite, sans
blocage, et sans messages, à la date de valeur
 Approche bien adapté également au BDs
temps-réel (G. Molina)
44
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 ?)
45
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
46
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
47
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 de 100€ par T (V2 = 17h30)
» Celui de 200€ par T (V2 = 18h30)
48
Site 1
Site 2
T28
T31
20
W31(C)
W28 (A)
28
31
t
49
W31 (B)
Site 1
Site 2
T28
T31
20
W31(C)
W31(A)
28
31
t
50
W28 (A)
W31 (B)
Site 1
Site 2
T28
T31
20
W31(C)
W31(A)
28
C28
C31
31
t
51
W28 (A)
W31 (B)
Site 1
Site 2
T28
T31
20
W31(C)
W31(A)
W28 (A)
W31 (B)
W28 (B)
28
C28
C31
31
t
52
Site 1
Site 2
T28
T31
20
W31(C)
W31(A)
W28 (A)
W31 (B)
A31
28
C28
C31
31
t
53
W28 (B)
C28
C31
 La pratique sur le Web (2010)
 Les transactions courantes en général utilisent des
dates de valeurs, les sagas et les compensations
 Banques, Réservations, Achats, Ventes aux
Enchères…
 Protocoles de gestion de conflits sont divers
54
Protocoles & standards
d'intéroperabilité MBD
 La
seule voie pour la coopération des SGBD
 ODBC (Open Database Connectivity) standard
interface, & protocole
– bits et octets encodent :
»
»
»
»
ordres SQL & tables résultats de ceux-ci
ordre de gestion de connections et d'exécution répartie
Locking & 1PC
API à 2 niveaux, jusque-là
"Middleware" supporté par pratiquement tous
les producteurs de SGBD ou de "front-ends"
55
Autres Règles de Priorité
Le
retrait de 150€ à 17h20
– Donnera lieu au calcul d’intérêt sur
-50€ si V3 =17h21
– Pas de pénalité si V3 > 18h
Mais
56
la réservation d’une place
d’avions parmi les 11 dispo,
laisserait seulement 10 places
dispo avant V, d’habitude
Protocoles & standards MBD
Industriels autres que ODBC
 Data
Access Language (DAL)
– Disponible sur Apples depuis 1989
» un dialecte de SQL
 Distributed
Relational Database Access
(DRDA)
– IBM, une partie de System Application Arch.
(SAA)
 EDA-SQL
(du passé)
– Inf. Builders ; un dialecte de SQL et une API
57
ODBC
Origines
ISO - RDA
Intl. Standard Org. Remote
Database Access Protocol
commencé vers 1988
Draft Intl. Standard depuis
1991
58
ODBC
SQL - Access Group
Consortium Privé de
40 Comp.
Crée sous l'impulsion
de J. Gray en 1989
Origines
SQL-Access
ISO - RDA
59
ODBC
Origines
Microsoft
coup de poing
sur la table
ODBC
SQL-Access
ISO - RDA
60
ODBC Architecture
Programme d'application
Interface ODBC
Gestionnaire de Drivers
Driver Driver
Driver Driver
Single Tier
Driver
Btrieve
Passerelle
Multiple Tier
Driver
Excell
DB2
Sybase
Passerelle
MicroDécision
Systems
61
ODBC : quelques drivers
 HP
: ALLBASE/SQL
 CA : IDMS, DATACOM, VSAM, DL/1, TOTAL...
 CrossAccess ; IMS, VSAM, IDMS, RMS...
 IBM : DB2
 DBA ODBC driver (Siemens-Nixdorf)
– INFORMIX, ORACLE, INGRES, SESAM/SQL,
UDS/SQL...
 DDA/ODBC

62
driver (Bull)
– ORACLE, INFORMIX, INGRES, DB2, RDB...
Microsoft maintient la liste à jour
ODBC
 L'interface
– offre l'API unique aux applications
» connections
» gestion de mémoires
» ordres SQL
 Le gestionnaire de drivers
– charge le driver approprié
– passe les ordres de connexion et de SQL
– récupère les résultats en format ODBC
63
ODBC

Le driver
– traduit les ordres SQL & API vers ceux de la
source de données
64
» décompose SQL
Single-tier
» passe SQL à la source
multiple-tier
– SQL ODBC traduit
– SQL non-ODBC non-traduit ("pass
through")
ODBC

Le driver (suite)
– traduit le format de données
Ȉ l'envoi
»au retour
– traduit les codes d'erreur vers ceux
standard
65
ODBC
Niveaux de conformité
 Fonctions
offertes par un driver
– API
»Core
Tout
»Level1
»Level2
66
le driver
ODBC
Niveaux de conformité
Fonctions
offertes par un driver
– SQL
»Minimum
Tout
le driver
»Core
»Extended
– On est à V 3.1
67
ODBC
Fonctions de Core API
 Alloue
et libère
– environnement, connections et "handles"
» SQLAllocEnv, SQLAllocConnect,
SQLAllocStmt
» SQLFreeStmt, SQLFreeConnect,
SQLFreeEnv
– fonctions à executer avant toute connection
 Connecte au sources de données et déconnecte
» SQLConnect, SQLDisconnect
68
ODBC
Fonctions de Core API
 Prépare
et exécute ordres SQL
» SQLPrepare, SQLExecute, SQLExecDirect,
SQLCancel, SQLGetCursorName,
SQLSetCursorName
 Alloue
mémoire pour les paramètres et résultats
de SQL
» SQLBindCol
69
ODBC
Fonctions de Core API
 Trouve
des données dans le résultat
» SQLFetch
 Trouve
les metadonnées du résultat
» SQLRowCount, SQLNumResultsCols,
SQLDescribeCol, SQLColAttributes
 Commit
et rollback
» SQLTransact
 Gère
les codes erreur
» SQLError
70
ODBC
Fonctions Level1 API
Fonctions
de Core API avec un ordre
suppl.
»SQLBindParameter (prép. des ordres SQL)
Connections
avec les boites de dialogue
– spécifiques aux drivers
»SQLDriverConnect
71
ODBC
Fonctions Level1 API
 Requêtes
aux metadonnées de la connexion et
de l'ordre en cours
» SQLSetConnectOption, SQLGetConnectOption
» SQLSetStatementOption,
SQLGetStatementOption
 Envoie
d'une partie de paramètres de l'ordre
ou du résultat
– utile pour des données longues
» SQLPutData, SQLParamData, SQLGetData
72
ODBC
Fonctions Level1 API
 Requêtes
au catalogues des attributs,
tables et stats
» SQLColumns, SQLSpecialColumns,
SQLStatistics,SQLTables,
 Requêtes
aux metadonnées du driver et
de la source de données
73
– types de données supportés, fonctions aggr.,
niveau de conformité ODBC...
» SQLGetInfo,
SQLGetFunctions,SQLGetTypeInfo
ODBC
Fonctions Level2 API
 Level1
– "Browsing" de l'info sur la connection et les
sources disponibles
 SQLBrowseConnect,
SQLDataSources,
SQLDrivers
– Envoi des tables ("arrays") de valeurs de
paramètres
 SQLParamOptions
74
ODBC
Fonctions Level2 API
Level1
– "Browsing" de l'info sur les paramètres et
résultats
» le nombre et les param. individuels
 SQLDescribeParam, SQLNumParams,
SQLMoreResults
– Gère les curseurs "scrolable"
,
SQLSetScrollOptions, SQLSetPos,
SQLExtendFetch
75
ODBC
Fonctions Level2 API
 Laisse
passer un dialecte de SQL
– ordres spécifiques de la source de données
» SQLNativeSql
 Requêtes aux catalogues SQL
– privilèges, clés, procédures...
» SQLForeignKeys, SQLPrimaryKeys,
SQLProcedureColumns,SQLProcedures,
SQLTablePriviledges

76
Appel du traducteur DLL
» SQLDriverToDataSource,
SQLDataSourceToDriver
ODBC
SQL : Niveau Grammaire Minimale
 CREATE
TABLE, DROP TABLE
 Simple SELECT, INSERT, UPDATE
SEARCHED, DELETE SEARCHED
 Expressions simples
– (A > B+C)
 Types
de données
– CHAR, VARCHAR, LONG VARCHAR
77
ODBC
SQL : Niveau Grammaire Core
 Grammaire
Minimale
 DDL
– ALTER TABLE, CREATE INDEX, DROP
INDEX, CREATE VIEW, DROP VIEW,
GRANT & REVOKE
 DML
– SELECT entier
» sous-requêtes et fonctions agrégats de SQL Access
 Types
78
de données
– DECIMAL, NUMERIC, SMALLINT, INTEGER,
REAL, FLOAT, DOUBLE PRECISION
ODBC
SQL : Niveau Grammaire Etendue
 Grammaire
Minimale
 DML
–
–
–
–
outer joins,
UPDATE, DELETE positionnées
SELECT FOR UPDATE
Unions
 Types
de données
BIT, TINYINT, BIGINT, BINARY, VARBINARY,
LONG VARBINARY, DATE, TIME, TIMESTAMP
79
ODBC
Conception d'un driver
Les
fonctions de ODBC (API & SQL)
sont prises en charge
– par le Gestionnaire
– par le driver
»surtout la conversion de SQL et de
représentation de données
80
ODBC
Conception d'un driver
Les
drivers ne sont pas en principe
fournis par Microsoft
Plusieurs vendeurs peuvent proposer
un driver vers une même source, p.e.
Sybase
81
ODBC
Conception d'un driver
Les drivers vers une même source peuvent différer en
– niveau de conformité
– performances
 les différences en performances peuvent résulter de
– stratégie de réception de tuples
» sur demande ou "read-ahead"
» existence et taille du cache
pour "read-ahead" ou une copie d'une table
– optimisation locale de requêtes
» jointures internes et externes

82
ODBC
Limitations de V3.1
Une
connexion per SGBD
– mais une application peut ouvrir
plusieurs connections simultanément
Ordres
SQL-ODBC sont monobase
– sauf les "passe-through" vers un SGMB
83
ODBC
Limitations de V3.1
Requêtes
MBD doivent être
décomposées par le système local
– l'idée peu performante
»connections multiples
»jointures MBD
Absence
84
de 2PC
ODBC
Pour en savoir +

Site MSDN de
Microsoft
http://msdn.microsoft.com/


85
Pas mal d’autres sites
Plusieurs livres
Autres protocoles notables
 OLE
& DDE
– de Microsoft
– Permettent d'échanger les données entre un
SGBD et les applications externes
» tableur, traitement de texte, gestionnaire d'images
 CORBA
– tentative de standard multicompagnie
– orienté l'échange distribué des objets
86
DCE
 Distributed
Computing Environment
 Un ensemble de services supportes par les
principaux constructeurs
 Tout particulièrement
– SGF distribué
– Les serveurs de temps unique
 DCE
87
sera probablement largement appliqué
DCE
Reference Architecture
File service
Time Directory Security
service
service
service
RPC &
authentication
DCE
Threads
Host Operating system
and networking
Hardware
88
DCE
Reference Architecture
 Les
DCE services s'utilisent en interne
– Directory Service (DS) utilise RPC pour la
communication entre les serveurs
– RPC utilise DS pour connaître la destination d'un
appel
– Time Service (TS) utilise les Security Service (SS)
pour déterminer qui peut régler une horloge
– SS utilise TS pour donner les permissions à courte
terme ("short life-time tickets")
89
DCE
Reference Architecture

Les machines, usagers, fichiers
et autres ressources sont
groupés en "Cells" selon
– But fonctionnel
– Sécurité
– Performance
Ordinateur
Chaussure
» Géographie
– Administration
» choix de Cell Administrator

90
Cell peut correspondre à une
multibase
Cellules organisées
par produit
DCE
Distributed Time Service
 Maintient
la synchronisation des horloges
 Basé sur les Time Servers qui veuillent sur
– la synchronisation mutuelle des horloges
– la synchronisation avec le temps réel

Offre 33 fonctions (library calls) aux applications
 Le
modèle de temps
– temps à intervalle
» quelle heure est-il ?

entre 9:30 et 9:31
– représenté sur 64 bits
– pas d'ordre total
91
» problème pour les dates de valeur
DCE
Indic. d'imprécision
Erreur max (en sec.)
Diff. / GMT
Mois
Jour
Heure
Min.
Sec, (préc. de 1 msec.
Année
Distributed Time Format
1995 -11 -02-14:23:43.123 - 01:00 I 003.600
International Standard 8601 pour
Universal Coordinated Time (UTC)
92
DCE
Time Adjustement Algorithm
 Time
Clerks (TC)
– démons sur les machines-client
 Time
Servers (TS)
– démons en charge de gérer la base de UTC
» locaux (dans les Cells)
» globaux

93
avec peut-être une interface vers les sources exterieures
de UTC
– ondes hertziennes diffusées dans les pays industriels
DCE
Time Clerk Synchronization
 Contacte
tous les TS sur le
LAN ou dans la Cell
 Delete toute réponse sans
intersection avec une autre
 Calcule l'intersection max du
reste
 Prend la valeur du milieu
comme nouveau UTC
 Fait une correction graduelle
UTC1
UTC2
UTC3
UTC4
UTC
» p.e. < 5 msec. par tick d'horloge
94
UTC client
DCE
Directory Service
 Deux
types de répertoires &
services
– Cell Directory Service (CDS)
– Global Directory Service (GDS)
Cell
CDS
GDA
DNS
» schéma de nommage X500

Services auxiliaires
– Domain Name System (DNS)
» utilisé par GDS
 schéma de nommage Internet
– Global Directory Agent
» utilisé par CDS pour localiser les noms
95
Cell
GDA
CDS
GDS
DCE
File Service
 Deux
partie conceptuelles
– FMS local sur chaque noeud
» dit Episode
» une modernisation de FMS de Unix
– FMS global
» extension de AFS
» indépendance de localisation dans une Cell
» duplication possible d'un fichier entre les Cells
» nommage DCE
» notion de client et de serveur
96
DCE
Security Service
 Composantes
– Authentication Server (AS)
» donne des tickets
– Privilege Server (PS)
» issue des privilèges d'accès et
d'execution

Privilege Attribute Certificates
» exigés pour execs. RPC
– Login Server (LS)
» gère les connections et vérifie les
tickets et les privilèges
97
AS
1
PS
2
DCE
Client
3
LS
DCE
Pour en savoir +
 Tanenbaum,
A.
Distributed
Operating Systems.
Prentice Hall, 614.
$57
98
Conclusion
 Manipulations
multibases ont été parmi les
plus importantes directions R & D dans les
SGBDs
 Autres mots-clés:
–
–
–
–
99
Interopérabilité
Bases fédérées
Intégration
Bases Réparties Hétérogènes
Conclusion
La
technologie est fort présente dans
l’industrie informatique
Il y a néanmoins encore beaucoup à
apprendre et à faire
 Il y a des nouvelles tendances
– XML multibase et distribué (AquaLogic de BEA)
– Extended Web Services
– Les « nuages » p.ex. Services Azure
100

L’impact à voir bientôt
FIN