1 / 83

Introduzione ai Database a Oggetti

Introduzione ai Database a Oggetti. Lucia Silvestris, INFN Bari Torino 5 Marzo 1999. Generalità sui Database e DBMS. Introduzione. Cosa e’ un Data-base? E’ una collezione di dati. Esempio1: Rubrica telefonica Esempio2: Sistema delle tasse Italiano Esempio3: Conto Corrente bancario

tyne
Télécharger la présentation

Introduzione ai Database a Oggetti

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. Introduzione ai Database a Oggetti Lucia Silvestris, INFN Bari Torino 5 Marzo 1999

  2. Generalità sui Database e DBMS

  3. Introduzione • Cosa e’ un Data-base? • E’ una collezione di dati. • Esempio1: Rubrica telefonica • Esempio2: Sistema delle tasse Italiano • Esempio3: Conto Corrente bancario Questa collezione può essere generata e gestita: • manualmente (Rubrica) • tramite l’utilizzo del computer (Rubrica o sistema delle tasse,conto corrente) L. Silvestris

  4. Introduzione • Quando si utilizza il computer la gestione può essere fatta: • utilizzando un insieme di programmi che sono stati scritti appositamente per la particolare applicazione • utilizzando un “database management system” (DBMS) (Collezione di programmi che consente all’utente di creare e mantenere un Database) L. Silvestris

  5. Caratteristiche dell’approccio Database • Il database system non e’ solo il database ma anche il suo catalogo. • Il catalogo contiene informazioni quali la struttura di ogni file, il tipo dei dati (Schema) che devono essere immagazzinati e i vari vincoli sui dati. • Il catalogo viene utilizzato dal DBMS software. Infatti il DBMS non viene scritto per ogni specifica applicazione quindi si deve riferire al catalogo per conoscere la struttura dei dati. (Questo non e’ necessario nel caso di file processing, in quanto la definizione dei dati fa’ tipicamente parte dell’applicazione stessa. Per esempio nel caso di un programma in C++ questa parte viene fatta nella definizione delle classi e nel caso del C delle “structure”) L. Silvestris

  6. Utente Database System Applicazioni DBMS Software Software per processare le queries Software per accedere e immagazzinare dati Definizione del database:catalogo e schema Databases DataBase System L. Silvestris

  7. Quali sono i vantaggi nell’utilizzare un DBMS • Controllo della duplicazione di dati e software • Storage persistente per gli oggetti presenti nelle applicazioni e per la struttura dei dati • Diverse interfacce che possono essere utilizzate dai diversi utenti • Possono essere immagazzinate relazioni complesse tra i dati • “Backup” e “recovery” • DataBase descrive automaticamente il formato dei dati L. Silvestris

  8. Quali sono le implicazioni dovute all’utilizzazione di un Database • Devono essere utilizzati degli standard per i nomi e i formati dei vari dati • Si riduce il tempo necessario per sviluppare le applicazioni • In quanto si utilizza il DBMS che costituisce un layer intermedio tra il database e l’applicazione • Aumenta la flessibilità • Nel caso in cui bisogna soddisfare un ulteriore requisito, generalmente bisogna aggiungere qualche nuovo database oppure modificare i dati in un file esistente. Questo viene gestito dal software DBMS • Disponibilità di informazioni aggiornate • Infatti tutti gli utenti hanno una visione aggiornata dei loro dati subito dopo che la transazione e’ avvenuta. L. Silvestris

  9. Quando usare un DBMS ? • Date le caratteristiche appena esposte, un DB e’ utile (se non necessario) quando si trattano dati “complessi” . Complessità dei dati • dati di per se’ semplici, ma il campione e’ molto grande(elenco fornitori di una ditta) • i dati e le applicazioni su di essi richiedono integrità e consistenza (conto corrente) • esistono complesse relazioni tra dati (eventi HEP) L. Silvestris

  10. Quale DB usare ? • La scelta e’ dettata, oltre che da fatti oggettivi quali esistenza del prodotto o precedenti esperienze, da • quantità dei dati da immagazzinare. • tipo di dati da immagazzinare. • complessità delle relazioni tra le entità da immagazzinare. Più elevata e’ la quantità o la complessità dei dati, piu’ articolato (o complesso) deve essere il DBMS. • Rubrica: carta e penna • CC Banca: DB commerciale con ottime caratteristiche’ di integrità • eventi HEP: DB (commerciale…) con ottima gestione relazioni complesse L. Silvestris

  11. Quando non e’ necessario utilizzare un DBMS • Nonostante i tutti i vantaggi descritti nelle precedenti trasparenze l’utilizzazione di un DBMS comporta un sovrapprezzo dovuto all’iniziale investimento in termini di hardware, software e training. Pertanto nelle seguenti circostanze si consiglia di non utilizzare un DBMS: • Il Database e le sue applicazioni sono molto semplici, ben definite e non si aspetta che cambino nel tempo • Non e’ richiesto un accesso da parte di più di un utente • Ci sono delle esigenze di accesso in tempo reale che non possono essere soddisfatte a causa dell’overhead dovuto ad un DBMS L. Silvestris

  12. Databases ad oggetti come Data Storage per l’HEP

  13. Event Tracker Calor. TrackList HitList Track Hit Track Hit Track Hit Track Hit Track Hit HEP “Data Models” • HEP “data models” sono complessi ! • Tipicamente centinaia di classi • Molte relazioni tra le classi • Differenti “patterns” di accesso • Gli esperimenti LHC sono basati su tecnologia OO • Le applicazioni OO utilizzano “networks” di oggetti • Puntatori (o “references”) sono utilizzati per descrivere le relazioni tra gli oggetti L. Silvestris

  14. “Data Management” a LHC • Gli esperimenti LHC dovranno immagazzinare una enorme quantità di dati • 1 PB di dati per esperimento e anno • 100 PB nell’intera vita dell’esperimento • Ambienti eterogenei e distribuiti • Alcune centinaia di istituti distribuiti nel mondo • differenti tipi di piattaforme hardware • Possibilità di avere dati nei centri regionali ? • Le soluzioni esistenti non sono in grado di scalare • Possibile soluzione suggerita dal “Working group” RD45 al CERN: • ODBMS accoppiato con un Mass Storage System L. Silvestris

  15. Caratteristiche dei DataBase ad Oggetti

  16. Quali sono i goals di un ODBMS? • Un ODBMS deve fornire proprietà simili a quelle di un DBMS convenzionale, cioè persistenza, transazioni e “queries”. • Un ODBMS deve anche supportare un accesso veloce agli oggetti che hanno relazioni molto complesse con altri oggetti • Un ODBMS deve lavorare, senza necessità di alcuna particolare interfaccia, con uno o più linguaggi Object-Oriented L. Silvestris

  17. Linguaggi di programmazione e I/O • “Loose Binding” - dati in memoria e su disco • il programmatore che deve utilizzare gli stessi dati in piu’ programmi deve gestire diverse rappresentazioni di I/O degli stessi dati • navigare nel network di oggetti in memoria • mantenere un codice specializzato per l’ I/O di ogni singola classe • “Tight Binding” - oggetti persistenti in un ODBMS • ODBMS consente di utilizzare gli oggetti persitenti direttamente come variabili di un linguaggio OO • C++, Java and Smalltalk • I/O “su richiesta”: non bisogna gestire un codice specializzato per l’ I/O L. Silvestris

  18. class Event : public ooObj {public: int event() const; • private: • int eventNr; … }; • class Event {public: int event() const; • private: • int eventNr; …}; Transiente Persistente Persistenza degli Oggetti • Persistenza • Gli oggetti e le loro relazioni sono immagazzinati nel database e persistono oltre l’esecuzione di una applicazione. Quindi possono essere acceduti e condivisi da più applicazioni. Questo meccanismo viene fornito dal ODBMS. • L’entità che viene immagazzinata è l’oggetto completo con tutti i suoi “data members” L. Silvestris

  19. “Clustering” degli Oggetti • Lo scopo è quello di trasferire solo i dati utili: • dal disco all’utente • dal nastro al disco • Gli oggetti possono essere fisicamente clusterizzati a seconda dei “patterns” principali di accesso • Clustering per tipo • per esempio agli oggetti Track si accede con i loro hits. • I principali “patterns” di accesso possono cambiare nel tempo • Le performance possono migliorare dal re-clustering • Clustering di oggetti individuali • per esempio tutti gli eventi Higgs possono essere scritti in un unico file L. Silvestris

  20. Database# Cont.# Page# Slot# Navigazione nei Database ad Oggetti • Identificatore Unico dell’oggetto (OID) • Accesso diretto per ogni oggetto nel database distribuito • Naturale estensione del concetto di puntatore • L’OID permette l’implementazione di una rete di oggetti persistenti (“associazioni”) • Cardinalità: 1:1 , 1:n, n:m • uni- o bi-direzionali • Gli OID sono utilizzati tramite gli smart-pointers L. Silvestris

  21. Come lavorano gli “smart pointer” ? • d_Ref<DetUnit> è uno “smart pointer” a un oggetto DetUnit • Il database automaticamente localizza gli oggetti quando vengono richiesti e li legge. • L’utente non deve conoscere la locazione fisica degli oggetti. • Nessuna informazione sul nome del nodo o del file deve essere contenuta nell’applicazione • Permette un buon disaccoppiamento tra modello logico e fisico . L. Silvestris

  22. Event Tracker Calor. TrackList HitList Track Hit Track Hit Track Hit Track Hit Track Hit Esempio di utilizzazione dello smart pointer Collection<Event> events; // Collezione event Collection<Event>::iterator evt; // un iteratore della collezione // loop su tutti gli eventi presenti nella collezione for(evt = events.begin(); evt != events.end(); evt++) { // accesso alla prima traccia nella lista delle tracce d_Ref<Track> aTrack; aTrack= evt->tracker->trackList[0]; // stampa la carica di tutti gli hits che appartengono a quella traccia for (int i = 0; i < aTrack->hits.size(); i++) cout << aTrack->hits[i]->charge << endl; } L. Silvestris

  23. fotone o elettrone Evento traccia adrone Modello Fisico e Modello Logico Federazione mantiene il coordinamento fisico dei diversi databases • Il modello fisico può essere cambiato per ottimizzare le performance • Le applicazioni esistenti continueranno a funzionare L. Silvestris

  24. Caratteristiche specifiche di Objectivity/DB

  25. Alcuni concetti di Objectivity/DB • Database Federato: può contenere uno o più Databases., fisicamente immagazzinato in un unico file. • Database: collezione di Containers, fisicamente rappresentato da un file su disco • Container:insieme di Pagine fisicamente raggruppate in memoria o su disco • Pagina: collezione di oggetti fisicamente raggruppati in memoria o su disco • Oggetto: unità elementare che può essere resa persistente Host 2 container network Host 1 DataBase Object Page Federazione L. Silvestris

  26. Alcuni concetti di Objectivity/DB • Federazione: Amministrazione della configurazione generale e degli accessi. Memorizzazione dello schema. Fisicamente rappresentato da un file (boot file). • Database: Divisione logica della Federazione. I databases all’interno di una Federazione possono risiedere su macchine diverse. • Container: Unità minima sulla quale vengono eseguite le operazioni di locking per la scrittura dei dati • Pagina: Unità minima caricata in memoria per ogni accesso Funzionalità L. Silvestris

  27. Database# Cont.# Page# Slot# Navigazione nei Database ad Oggetti • Identificatore Unico dell’oggetto (OID) • Accesso diretto per ogni oggetto nel database distribuito • Naturale estensione del concetto di puntatore • L’OID permette l’implementazione di una rete di oggetti persistenti (“associazioni”) • Cardinalità: 1:1 , 1:n, n:m • uni- o bi-direzionali • Gli OID sono utilizzati tramite gli smart-pointers L. Silvestris

  28. Esempio di navigazione in Objectivity/DB OID = identificatore unico dell’oggetto OID degli oggetti OID degli oggetti utilizzati nelle associazioni L. Silvestris

  29. Accessi Concorrenti in Objectivity/DB • I cambiamenti ai dati sono parte di una transazione • L’accesso è coordinato tramite un “lock server” • MROW: per ogni container più utenti possono leggere ed uno solo può scrivere (Objectivity/DB) • E’ supportata la possibilità di più utenti che scrivono contemporaneamente • cioè più streams di dati paralleli • cioè farms che consentono di fare il Filter o la ricostruzione dei dati • cioè simulazioni distribuite L. Silvestris

  30. Evoluzione dello Schema in Objectivity/DB • Modifica del modello ad oggetti durante la vita dell’esperimento • migrare i dati esistenti dopo le modifiche nello schema • minimizzare l’impatto sulle applicazioni esistenti • Operazioni supportate • aggiungere, muovere o rimuovere alcuni attributi dentro le classi • cambiare la gerarchia delle “inheritance” • Migrazione degli oggetti esistenti • immediata: tutti gli oggetti sono convertiti utilizzando un applicazione di “upgrade” • lazy: gli oggetti vengono modificati solo quando vengono richiesti L. Silvestris

  31. “Versioning” degli Oggetti in Objectivity/DB • Mantiene più versioni dello stesso oggetto L. Silvestris

  32. Server Database Centrale Bottleneck Buona granularita’ degli oggetti; cattiva performance totale Architettura: Server Centralizzato • Vantaggi: • Amministrazione centralizzata • Sharing effettivo, granularita’ degli oggetti • Svantaggi: • Il server degli oggetti e’ lento • “Server bottleneck” limita la scalabilita’ • Limitata distribuzione degli oggetti • Migliore Utilizzazione: : • Potenti computer centralie semplici terminali remoti • Struttura dei dati semplice,brevi transazioni L. Silvestris

  33. ObjectManager ObjectManager Clienti Direct Links PageServer PageServer PageServer Servers Funzioni Benefici Page Server muove i dati in pagine Performance Object Manager supporta la granularita’ Flessibilità, Funzionalità Link diretto tra clienti e servers Scalabilita’ in utenti Object Cache management libera gli oggetti non utilizzati Scalabilita’ in oggetti Architettura: Servers Distribuiti L. Silvestris

  34. Application Host Application & Disk Server Application Application Objy Client Objy Client Objy Server ObjyLock Server Objy Server HPSS Server Objy Server HPSS Client Data Server connected to HPSS Disk Server Una Federazione Distribuita L. Silvestris

  35. Migration daemon Migration (write) request DB files transfer Stage Pool UNIX FS HPSSServer DB pages transfer AMS with HPSS interface Staging (read) request HPSS e Objectivity/DB • L’integrazione tra HPSS e’ Objectivity/DB e’ fatta in AMS (page server) • poiché questa parte del codice di Objectivity e’ piccola e quindi facilita l’integrazione • poiché gestisce tutte le funzione di I/O dei files L. Silvestris

  36. Interfaccia Objectivity/HPSS • Objectivity/DB data server utilizza un piccolo numero di funzioni I/O • open(), close(), read(), write(), etc. • Per ognuna di queste, esiste un equivalente in HPSS • hpss_open(), hpss_close(), hpss_read(), hpss_write(), etc. • Objectivity ha definito un chiaro livello di interfaccia • the Objectivity/DB Open File System (OOFS) • questa interfaccia può essere “castomizzata” • utilizzando HPSS (o qualunque altro MSS) • I files potranno essere visti in maniera trasparente dall’applicazione • Ma bisogna sapere che si sta aspettando un file..e non che c’e’ un problema di timeout della rete!! L. Silvestris

  37. Concetti avanzati di Objectivity/DB • Partizione: una Federazione può essere suddivisa in Partizioni Autonome. In ogni partizione vi è una copia del boot file che consente ad ogni partizione di funzionare anche in assenza del collegamento di rete con il boot file della Federazione. • Replica: copia di un DataBase (con i medesimi oggetti e identificatori) realizzata per rendere più veloce l’accesso quando il DataBase originale si trova geograficamente lontano. L. Silvestris

  38. Site 1 Site 2 Site 3 Replicazione dei Dati • Gli oggetti di un Database replicato esistono in tutte le copie • Multiple copie fisiche dello stesso oggetto • la sincronizzazione tra le copie viene gestita dal database • Aumento in “perfomance” • Gli utenti possono accedere alla copia locale dei dati • Aumenta la disponibilità dei dati • Database disconnessi possono continuare a lavorare sulla replica locale dei dati Wide Area Network L. Silvestris

  39. Strumenti per il Database Administrator • Strumenti connessi ai Database Federati (FD) • Creazione di un nuovo FD oonewfd • Cambiare gli attributi di un FD oochange • Copiare un FD oocopyfd • Cancellare un FD oodeletefd • Lista di tutti I files contenuti in un FD oodumpcatalog • Strumenti connessi ai Database (DB) • Creazione di un nuovo DB oonewdb • Cambiare gli attributi di un DB oochangedb • Copiare un DB oocopydb • Aggiungere un DB ad una Federazione ooattachdb • Cancellare un DB oodeletedb • Debugger tool per esaminare ed editare il contenuto di un FD oodebug L. Silvestris

  40. Strumenti per il Database Administrator • Controllare il lock server oolockserver, ookillls • Backup e restore dei files oobackup, oorestore • Strumenti per scoprire se ci sono problemi oolockmon e oocleanup • AMS fornisce accesso ai dati che sono localizzati su un sistema remoto oostartams L. Silvestris

  41. Lo Standard ODMG • Standardizza • “Data definition language” ODL • “Data interchange format” OIF • “Language binding” per C++, Java and Smalltalk • Scopo: Semplificare la migrazione del codice da un database ad un altro • Le API più utilizzate sono incluse nello standard ODMG 2.0. • Le “performance” e le proprietà dei differenti ODBMS sono abbastanza differenti ! • Qualunque migrazione da un database ad un altro richiede uno sforzo importante! L. Silvestris

  42. Quando dovrebbe essere utilizzato un ODBMS.. • Se stai utilizzando un linguaggio object-oriented e vuoi immagazzinare i tuoi oggetti • Se hai relazioni complesse tra gli oggetti • Se hai molti oggetti che ereditano da altri • Se hai bisogno di performance molto buone • Se vuoi immagazzinare grandi quantità di dati • Se hai bisogno di mescolare piattaforme hardware e/o linguaggi • Sei vuoi distribuire i dati L. Silvestris

  43. Altri Prodotti O(R)DBMS • Versant • Disponibile su piattaforme Unix and Windows • Scalabile, supporta architetture distribuite • Database indipendenti • O2 • Disponibile su piattaforme Unix and Windows • supporto incompleto • Recentemente acquistata da Unidata (venditore RDBMS) L. Silvestris

  44. Altri Prodotti O(R)DBMS • Objectstore - Object Design Inc. • Disponibile su piattaforme Unix and Windows • Problemi di scalabilità • ODI si è indirizzata verso applicazioni web • POET • Disponibile solo su piattaforme Windows • Utili per applicazioni semplici • Problemi di scalabilità • Quali sono i principali fornitori di Database ad oggetti relazionali? L. Silvestris

  45. Database Relazionali ad Oggetti • I dati possono essere memorizzati o come oggetti o come tabelle • Le righe delle tabelle vengono tradotte in oggetti • Nuovi tipi di dati “Row Id” permette la navigazione • DB API basati su C++ o Java • Importanti caratteristiche dei ODBMS ancora mancanti nei database relazionali ad oggetti • ereditarietà, Polimorfismo, Templates • “Clustering” di oggetti individuali L. Silvestris

  46. Progetti HEP Basati su Objectivity/DB

  47. Esperimenti futuri • ALICE: Esperimento di ioni pesanti a LHC • Studia collisioni nucleari ultra-relativistiche • Relativamente corto periodo di presa dati1 mese/anno = 1PB/anno • Rate di dati estremamente altro 1.5GB/s • ATLAS: esperimento multi-purpose a LHC • Alto rate di dati: 100MB/secondo • Grande volume di dati: 1PB/anno • In preparazione progetti di Test beam che utilizzeranno Objectivity/DB • database di calibrazione • Attesi 600GB di raw data Atlas L. Silvestris

  48. Esperimenti futuri • CMS: esperimento multi-purpose a LHC • Rate di dati di 100MB/secondo • Volume di dati di 1PB/anno • Due progetti sui test beams basati su Objectivity completati con successo. • Il Database e’ stato utilizzato un tutti gli step della catena: online, ricostruzione e analisi • LHCB: esperimento dedicato alla violazione di CP nel sistema del mesone B a LHC. • Rate di dati più bassi rispetto a gli altri esperimenti LHC. • Volume totali di dati circa 400TB/anno CMS LHCB L. Silvestris

  49. Esperimenti in Produzione BaBar • BaBar: esprimento a SLAC partenza della presa dati nel 1999 • Objectivity/DB e’ utilizzato per “storare” dati raw, simulazione, calibratione e analisi • Attesi circa 200TB/anno, sarà utilizzato HPSS come MSS • La presa dati di cosmici è partita in Ottobre • ZEUS: esperimento a DESY sul collider HERA elettrone-protone • E’ in presa dati dal 1992 • Ambiente di analisi : codice in FORTRAN basato su ADAMO • Objectivity/DB è stato utilizzato per la selezione degli eventi in fase di analisi L. Silvestris

  50. Esperimenti in Produzione • CHORUS: esperimento per la ricerca di oscillazioni di neutrino • Utilizza Objectivity/DB per lo scanning online delle emulsioni • Piani di utilizzare la stessa applicazione nei altri centri esterni • COMPASS: presa dati nel 2000 con run preliminari nel 1999. • Saranno acquisiti circa 300TB/anno • Rate di acquisizione fino 35MB/secondo. • I dati dell’analisi saranno storati su disco, circa 3-20TB di spazio disco • Circa 50 utenti concorrenti e sono previsti molti reprocessing dei dati CHORUS COMPASS L. Silvestris

More Related