Cerca nel blog

Loading

21 gennaio 2013

Laboratorio 1 - Database 2

Vi avevo avvertiti di restare sintonizzati perché sarei tornato presto a dirvi come era stato il nostro approccio al mondo del database. Il momento era maturo anche se forse avremmo dovuto aspettare una settimana in cui potevamo dedicarci maggior tempo e non solo qualche ritaglio qua e là.

Avrete già capito che sto cercando qualche piccola scusa per indorare la pillola, perché il primo impatto è stato equivalente ad una sconfitta. L'idea, ve la ripeto, è che il nostro software prenda tutte le informazioni di configurazione da un database e sempre verso lo stesso database ritorni le misure effettuate dagli strumenti per renderle accessibili a tutti gli interessati. Il piano è di usare una piattaforma seria e performante come Oracle, così ci ha suggerito il nostro esperto DBA, ma prima di affrontare il mostro ci ha anche suggerito di iniziare la progettazione delle tabelle usando qualcosa di più semplice, come Access, senza per questo perdere di generalità.


E così ci mettiamo ad armeggiare e come spesso accade iniziamo subito all'arrembaggio e solo quando arriviamo all'intervallo sotto di un gol, decidiamo di prendere una pausa, di recuperare la lavagna e di chiarirci le idee con qualche disegno.

Alla fine la partita terminerà con 2 gol per il database e uno solo per noi segnato in extremis perché effettivamente l'accesso al database attraverso LabVIEW è effettivamente banale. Abbiamo però molto da lavorare sulla struttura, in modo da affrontare la prossima gara preparati.

Sul web si trovano tanti mini-tutorial che spiegano cosa fare e quali siano i principi base dietro un buon design di database. Per permetterti di giocare con tabelle, attributi, chiavi primarie, relazioni e simili, ho trovato uno strumento software molto interessante. Si chiama DeZign for Databases e permette di disegnare il proprio modello di dati, stabilire le relazioni, identificare le chiavi primarie ed esterne e così via. Il tutto può essere fatto mantenendo il modello indipendente da un'implementazione specifica di un database (Oracle, MySQL, Access eccetera) e alla fine si può costruire il database (in una specifica implementazione) partendo dal modello originale.

Anzi, ancora meglio. E' possibile collegarsi ad un database esistente, fare le necessarie modifiche alla struttura e poi ricaricare la nuova versione aggiornandone sia il modello sia i dati veri e propri.

Ne esiste una versione di prova utilizzabile per 30 giorni che sembra fatta apposta per noi per imparare le basi e tornare in campo convinti delle nostre potenzialità!

Chiunque può lasciare commenti su questo blog, ammesso che vengano rispettate due regole fondamentali: la buona educazione e il rispetto per gli altri.

Per commentare potete utilizzare diversi modi di autenticazione, da Google a Facebook e Twitter se non volete farvi un account su Disqus che resta sempre la nostra scelta consigliata.

Potete utilizzare tag HTML <b>, <i> e <a> per mettere in grassetto, in corsivo il testo ed inserire link ipertestuali come spiegato in questo tutorial. Per aggiungere un'immagine potete trascinarla dal vostro pc sopra lo spazio commenti.

A questo indirizzo trovate indicazioni su come ricevere notifiche via email sui nuovi commenti pubblicati.

16 commenti:

  1. Suggerirei di cercare un libro di testo sul design dei database relazionali, più che dei "mini tutorial": il design relazionale è matematica degli insiemi e non è tanto improvvisabile.
    Soprattutto per chi ha già competenze e dimestichezza con la matematica, l'approccio "serio" è decisamente raccomandabile :-)
    Per altro, Oracle sarà performantissimo ma in genere la mia esperienza è che il budget finisce molto prima di incontrare problemi di performance con altri database :-D

    RispondiElimina
  2. @RobertoMaurizzi:disqus ti prego dammi un libro di testo! Adoro l'approccio serio!



    Parliamo invece di budget. Di preciso cosa intendi? I soldi per le licenze, o per l'hardware su cui far girare il db? Noi non abbiamo scelto Oracle, ci è più o meno stato imposto dicendo che tanto abbiamo già una licenza di sito per cui non aveva costi (?!?)

    RispondiElimina
  3. Piccoli consigli:
    -il DB va studiato e strutturato in funzione delle operazioni piu' complesse che devono poi essere realizzate. Quindi cercare di capire a livello di DB qual'è il tipo di select piu' complessa, e partite da li nella realizzazione della struttura.


    -i software sono utili per realizzare la documentazione, cioè quando ormai si è scelta la struttura e la logica, si prende il software e si mette in bella il risultato, per renderlo comprensibile a terzi (o a noi stessi dopo un paio di anni)


    -se siete già in possesso di licenze ok per oracle, in alternativa MySql è sicuramente piu' che sufficiente (dipende dal tipo di estrazioni e dalla quantità di dati, ma a grandi linee offre già moltissimi strumenti)

    RispondiElimina
  4. Grazie Barney09 sapevo che avrei potuto contare sui vostri consigli.

    Nella lotta contro i database, in realtà, non siamo soli. Abbiamo un esperto DBA che ci farà la valutazione del modello, ma prima di tenerlo occupato per giorni inutilmente volevamo buttare giù noi qualcosa.

    La quantità di dati sarà bella grossa... speriamo di starci dietro!

    RispondiElimina
  5. Per darti un idea, su un server di fascia alta di 5 o 6 anni fa, una query su un campo numerico indicizzato su una tabella da 20.000.000 di record con mysql siamo sui 0,01 secondi. Se i dati sono ben strutturati, le tabelle ben normalizzate, e organizzate in modo da ottimizzare le select non dovresti avere problemi anche trafficando con grandi numeri. Poi una macchina recente, magari con dei dischi allo stato solido ti puo' aiutare ulteriormente. Se hai bisogno chiedi pure...

    RispondiElimina
  6. Non ho niente di pronto e purtroppo da una rapida ricerca noto che l'approccio serio s'è parecchio perso... oggi è un proliferare di corsi di SQL, disegnini di schemi ER o peggio ancora sistemi ORM di belle speranze (tipo "sperare che si possano progettare oggetti a caso e avere i vantaggi di un design relazionale").

    Io imparai l'approccio matematico alle superiori (taaaanti anni fa ;D) e ancora oggi mi vien da pensare che con query language della set theory "si fa prima" che con l'SQL che trovo troppo prolisso.

    Da una rapida ricerca, si trova questo post con un po' di consigli che, dai commenti, sembrano decenti http://programmers.stackexchange.com/questions/30035/what-are-some-good-books-on-relational-database-design (e Google, cercando relational database design books, suggerisce di aggiungere 'pdf', chissà perché ^_^; )

    Per il budget, so per esperienza diretta che Oracle è parecchio traditore con le licenze. Si hai la site licence ma quante istanze? A che condizioni? Con che opzioni? c'è il GIS? Per quanti processori? Quando c'è il rinnovo della licenza ti chiederanno un prezzo simile o moltiplicheranno per 2, come è capitato a gente che conosco?

    Come dice anche barney09, la performance sull'hardware moderno è stellare per praticamente tutti i RDBMS (se non fai vaccate tipo dimenticare un indice sulla foreign key principale di una tabella da 4 milioni di record, come mi è capitato di trovare di recente).

    Se servono prestazioni ulteriori un disco allo stato solido serio costa in genere meno di una licenza Oracle per un processore aggiuntivo/più potente :-)

    Io alla fine preferisco cose Open Source per vari motivi, i principali dei quali sono:

    - viene fatta molta ricerca su come usarli e sfruttarli al meglio, con risultati e test disponibili (se vuoi ho una presentazione di 160 slide su come una compagnia di giochi giapponese regge mi pare 20 milioni di utenti con un cluster di mysql e qualche scelta intelligente sull'organizzazione di tabelle, dischi e hardware :-) )
    - sono molto più disposti a esser clusterizzati su hardware 'cheap' di quanto sia Oracle (dove in genere visto quanto paghi di licenze per un cluster di database si preferisce investire sul ferro - sempre che pure quello non moltiplichi il prezzo della licenza) [nota bene: sono 3 anni che non ho a che fare col loro licensing, magari sono diventati un po' meno esosi]
    - non hai a che fare coi commerciali e col tuo reparto procurement :-P

    Detto questo se Oracle l'avete già 'a regime' e non prevedete sorprese antipatiche col rinnovo licenze ;-) vi conviene usare quello e soprattutto l'esperienza su di esso che già avete in casa.

    RispondiElimina
  7. Grazie mille! Adesso vedo cosa ha google da consigliarmi.


    per quanto riguarda open-source versus oracle, anch'io avrei la tendenza a preferire l'open, ma se il nostro DBA che è un utente linux ci ha detto Oracle, è perché con le licenze dovremmo essere tutto a posto.


    studio un po' e speriamo di tornare vincitori!

    RispondiElimina
  8. Quel tempo è per una query su un solo campo (indicizzato) che ritorna un solo record?
    @toto_unicolab:disqus , a occhio e croce ORACLE è sovradimensionato per i tuoi scopi, a meno che non prevedi moli davvero enormi, tipo dover gestire per intero 20 milioni di record al giorno con join su parecchie tabelle.

    Poi, se lo avete già a disposizione OK, altrimenti prenderlo apposta, valutate bene.

    Io ho qualcosa riguardo ll'impostazione e la creazione dei DB, è il supporto di un corso ORACLE di tempo fa, ma non saprei come mandarti il materiale..

    RispondiElimina
  9. guarda pensiamo di accumulare qualcosa tipo un record ogni 3 secondi circa. e questi sono solo gli INSERT dal lato acquisizione dei dati non volatili. Poi ci sono un circa 30 UPDATE di record per le acquisizioni volatili (quelle che non ho interesse a mantenere e che quindi genereranno traffico sul DB ma senza incrementarne la dimensione).

    e poi ci sono tutte le SELECT per la visualizzazione dei dati archiviati volatili e non volatili che però al momento ci è difficile quantificare.



    l'oggetto per intero è piuttosto grosso... ve l'avevo detto che era un progetto ambizioso!

    RispondiElimina
  10. sono circa 864000 insert al mese, considerando un funzionamento H24.
    Non è tanto, poi magari metti anche in atto strategie di backup del DB o di partizionamento delle tabelle.
    MySQL dovrebbe andare più che bene, poi deciderà il vostro DBA...

    RispondiElimina
  11. il funzionamento è ovviamente 24/7 anche se nel fuoriorario potrebbe essere differente la frequenza degli insert, ma non il numero totale facendo appoggio sui database interni dei vari strumenti che lo permettono.


    l'idea del DBA è chiara: avendo la ferrari già pagata (benzina inclusa) in garage, perché dovrei usare una mercedes?

    RispondiElimina
  12. Sono comunque numeri gestibili senza grandi difficoltà. Un'altra cosa importante da tenere in considerazione è la dimensione del record.
    Piu' informazioni (colonne) ha, piu' tendenzialmente sarà lento e pesante.
    Una corretta normalizzazione dei dati è la prima cosa da tenere in considerazione


    Qui c'è una spiegazione di cosa si intende per normalizzazione, magari sai già di cosa sto parlando, ma te lo posto comunque: http://it.wikipedia.org/wiki/Normalizzazione_(informatica)

    In questi casi, si possono usare strategie di archiviazione dei dati, ad esempio, creare dei conteggi giornalieri, con le sommatorie dei dati già calcolate relative a quel giorno. Un altra tabella con i conteggi per settimana, un altra per mese. Se il sistema si "presta" a questo tipo di tabelle "statistiche" puoi alleggerire di molto il sistema in fase di selezione, perchè non lo fai cercare sul dato puro, ma su un dato già precedentemente "contato". Altra soluzione è archiviare giorno per giorno i tabelle diverse, in modo da avere tante piccole tabelle anzichè una grande tabella. La stessa strategia la puoi adoperare anche per mese, il tutto dipende da che lavoro devi fare sui dati.

    RispondiElimina
  13. purtroppo i campi, non di tutte le tabelle, ma di un buon numero, sono molti (una ventina) e non sono nemmeno "sommabili" o "mediabili" su scale temporali.

    si può (e si deve) avere una formula di archiviazione, ma che purtroppo non spetta a noi decidere la frequenza. Se fosse per me terrei tutti i dati per un anno, poi con l'anno successivo sfoltirei e anziché tenere i dati con una frequenza di 5 min, passerei a 10 minuti e così via.

    RispondiElimina
  14. beh, certo, se ha già tutto disponibile per ORACLE allora non si pone il problema!

    RispondiElimina
  15. 20 non sono un numero di per se proibitivo.

    Vanno possibilmente ottimizzate le dimensioni, cercando di limitare al massimo lo spazio occupato da ogni singola informazione. Preferire ove possibile tipi di dati numerici a valori testuali, e ottimizzare al massimo il tipo di dato.



    Comunque se hai la possibilità di un consulto con un DBA, sicuramente di suggerira' le soluzioni piu' appropriate.

    RispondiElimina
  16. @toto_unicolab:disqus

    In un certo senso è normale, in genere nei DB ragioni per "quante cifre vuoi conservare".

    Parliamo di ORACLE, che probabilmente è quello che userai.

    In realtà tutti i numeri sono conservati internamente in notazione scientifica, ovvero hai una precisione e una scala. Esempio: NUMBER(5,2) ti permette di conservare qualcosa tipo 123.45, ma non 10000 (che avrebbe 7 cifre significative, 10000.00!). E prende 4 byte, per la cronaca.

    La relazione fra precisione e spazio occupato in byte non è banalissima (ma non complicata), ti mando una cosa che ti sarà probabilmente utile :
    http://fredericktang.wordpress.com/2008/07/10/size-of-number/

    Per i caratteri (VARCHAR2), lo spazio occupato è quello effettivamente del valore inserito in byte. Per esempio, se dichiari VARCHAR2(2000) e ci

    metti "10", lo spazio occupato sarà 2 byte.

    Un DATE prende 7 bytes fissi.

    http://www.dbforums.com/oracle/988495-size-date-datatype-oracle.html

    Voilà, hai qualche nozione in più.

    RispondiElimina

Chiunque può lasciare commenti su questo blog, ammesso che vengano rispettate due regole fondamentali: la buona educazione e il rispetto per gli altri.

Per commentare potete utilizzare diversi modi di autenticazione, da Google a Facebook e Twitter se non volete farvi un account su Disqus che resta sempre la nostra scelta consigliata.

Potete utilizzare tag HTML <b>, <i> e <a> per mettere in grassetto, in corsivo il testo ed inserire link ipertestuali come spiegato in questo tutorial. Per aggiungere un'immagine potete trascinarla dal vostro pc sopra lo spazio commenti.

A questo indirizzo trovate indicazioni su come ricevere notifiche via email sui nuovi commenti pubblicati.

Related Posts Plugin for WordPress, Blogger...