27 aprile 2005

Trovato: c'era

Ecco la pagina originale del manuale di mysql di cui vi parlavo ieri.
Vediamo insieme qualche punto:

  • La query cache: effettivamente non sembra presente in postgres, mentre per esperienza posso dire che è molto utile in mysql; credo che il db sfutti maggiormente la cache su disco e la shared memory. Comunque mi piacerebbe vederla implementata anche in postgres.
  • Vacuum: postgres ha bisogno di fare ogni tanto pulizia dello spazio allocato su disco (un altro punto a favore di Oracle e i suoi tablespace). Diciamo che il vantaggio è la grande velocità che si ottiene risparmiando la manutenzione del filesystem (in genere lento), favorendo le transazioni.
  • Test suite: sono solo indicative, un db in produzione è sempre un'altra cosa!
  • Alter table più sofisticato: ma anche meno comprensibile per chi è abituato ai concetti "naturali" di Oracle, dove gli indici e le tabelle sono oggetti distinti tra loro.
  • Heap tables: qui il discorso si fa un po' complesso, perchè postgres ha un processo di checkpoint come Oracle, quindi per come la vedo io scrive su disco quando gli pare e quello che gli pare; se una tabella viene modificata spesso, non è detto che le sue modifiche finiscano su disco alla stessa velocità con cui vendono eseguite (ma il log sì).
  • Molteplicità di tipi di tabella: uno transazionale (InnoDB) e uno no. Provate ad usare InnoDB, io non mi sono trovato molto bene.
  • Multithreading: vale quello che è già stato detto in precedenza nel post sul numero di processori...
  • Aggiornamenti senza problemi: da controllare.
  • Estensione con funzioni: beh, questa è veramente grossa, spero che sia riferita solo alla versione 7 di postgres.
  • multi-table update/delete: interessante feature di mysql, bisogna vedere se è aderente agli standard, l'ho trovata utile in qualche occasione. Ovviamente, avendo le transazioni, è possibile usare la "select ... for update" di postgres.

Ciliegina sulla torta, leggetevi i commenti degli utenti.
Chissà perchè questo capitolo non esiste più nel manuale originale.

26 aprile 2005

Google e la memoria storica

Possiedo una stampa del manuale di mysql scaricato ai tempi della 4.0.12.
Ricordavo un paragrafo in cui si comparavano le caratteristiche di mysql con altri db, in particolare postgresql.
Guarda caso, la pagina non è più recuperabile nel manuale online di mysql. Che strano.
Meno male che Google ne ha una copia cache, peccato che sia in francese. Potete consultare la versione tradotta dallo stesso Google.
Interessante anche la pagina di comparazione dei db, da leggere attentamente.
Domani cercherò di quotare i passi più interessanti del testo dalla mia versione stampata; ricordo infatti alcune perle, che alla luce delle nuove esperienze si sono evidenziate.

21 aprile 2005

Linguaggi procedurali

La prova di PostgreSQL procede con i linguaggi procedurali.
A parte alcune originalità nella gestione delle transazioni all'interno delle procedure plpgsql (somigliano molto a quelle PL/SQL di Oracle), come l'impossibilità di usare savepoint, rollback ecc., e la mancanza di una gestione descrittiva degli errori, per il resto il linguaggio nativo è molto molto flessibile, come il resto del db! :-)
Per la produzione usiamo molto Python, un linguaggio di scripting relativamente semplice e potentissimo; in postgres è possibile usarlo come linguaggio per scrivere le funzioni.
Durante le prove siamo già arrivati a fare mostrare la corda a Python: abbiamo generato, non volontariamente, un bel SIGSEV (segnale 11 sotto Linux) in una sessione.
Molto interessante il comportamento di PostgreSQL in questi casi: il processo padre di quello andato in segmentation fault, accortosi della situazione critica, obbliga tutti gli altri processi ad un rollback collettivo, quindi fa un reset a caldo in pochi istanti (penso meno di un secondo).
Questo può sembrare un comportamento strano, ma è perfettamente giustificabile: il processo padre, non potendo sapere nulla dello stato della transazione del processo bombato, per mantenere la consistenza dei dati obbliga tutti ad abbandonare le modifiche in corso; diversamente sarebbe stato se, invece di ritornare con un segnale 11, il processo figlio avesse generato un errore, del tipo di un 'eccezione Python: sarebbe avvenuto solo un rollback della transazione corrente e nessuno si sarebbe accorto di nulla, come abbiamo provato successivamente.
Il discorso per mysql è molto diverso: reset del server, con chiusura totale, probabilmente senza flush dei dati verso il disco; non essendoci le transazioni, l'integrità dei dati è una bella incognita.

19 aprile 2005

L'installazione e la configurazione di PostgreSQL continuano.
I tablespace in postgres sono in realtà niente più di directory in cui vengono scritti i file delle tabelle; nulla a che vedere con quelli di Oracle, completamente configurabili.
Ottime le funzioni di WAL (write ahead logs, sono come i redo-logs di Oracle), la funzione di archiviazione (semplice e molto efficace). Mi resta da comprendere bene l'uso delle timeline e l'allocazione della memoria.
Il log del postmaster è ben configurabile, con molte opzioni e livelli di dettaglio.
una volta finito con la configurazione passerò al monitoring.
Per inciso, sono riuscito a installare PostegreSQL (8.0.2) anche su Mac OS-X con l'ultimo aggiornamento (10.3.9).

14 aprile 2005

Amministrazione PostgreSQL

Sto continuando a leggere il manuale di Postgres, intanto ho installato pgadmin3, l'ottimo gestore di database postgresql nativo.
È un po' difficoltoso da installare (io l'ho compilato da sorgente, non è proprio facilissimo), ma ha molte funzionalità
Intanto ho installato anche Python come linguaggio delle procedure di postgresql, con l'utility createlang. Python è "untrusted" come linguaggio, e per ciò utilizzabile solo dall'amministratore. Per aggirare il problema bisogna creare il linguaggio nel db con l'opzione -e di createlang, poi dropparlo con drop language, e poi ricrearlo con l'output di createlang -e, che è alla fine lo script SQL che in realtà viene eseguito dallo stesso createlang; bisogna ovviamente inserire la keyword "trusted" dopo "create" :-)

13 aprile 2005

Transazioni e multiprocessing

Dovete installare e configurare un database di dimensioni medio-grandi per un nuovo progetto.
Avete a disposizione una nuova e bellissima macchina multiprocessore dell'ultima generazione, con tanta RAM e componenti di qualità.
Provate con mysql, caricando un database di test e cominciando a fare prove su come il db si dovrebbe trovare ad operare in produzione.
Mysql, come tutte le applicazioni multithread, fa partire un thread per ogni connessione, che gestisce interamente tutte le query effettuate su quella connessione.
Quindi, direte voi, se ho otto processori riuscirò in modo efficiente a sfruttarne almeno sette (lasciamone uno per i processi di sistema, tra cui l'I/O dei dischi).
Ebbene, se aprite 7 connessioni al server e fate 7 query anche molto impegnative per ogni connessione, vedrete che magicamente potrete avere i risultati in 1/7 del tempo. Ma attenzione: in mysql non esistono le transazioni. Ciò ha un'importante implicazione: tutte le tabelle che coinvolgo in una query devono presentare gli stessi dati anche per tutte le altre sessioni che le utilizzano, sia quelle che le leggono solamente, tanto più quelle che cercano di aggiornarle (che non possono aggiornarle, non essendoci una transazione separata). Da ciò deriva che, per tutta la durata di una query, le altre connessioni, che cercano anche solo di leggere da una delle tabelle coinvolte nella prima query, saranno completamente bloccate.
La vostra bella macchina multiprocessore starà quindi tutto il tempo ad aspettare il risultato della prima query, che comunque occupa solo un processore, quindi solo 1/8 della potenza disponibile.

12 aprile 2005

PostgreSQL e utenti

In questo periodo sto provando per lavoro PostgreSQL, per valutare la possibilità di utilizzarlo in produzione.
Per ora sto leggendo il manuale, ma ho già fatto un'installazione approssimativa per potere almeno provare i vari esempi presenti sul manuale.
Sto affrontando l'aspetto degli utenti e dei permessi. È interessante notare come postgresql stia a metà tra Oracle e mysql sotto questo aspetto. Infatti, se per mysql esistono solo i database e gli utenti con i loro permessi, e per Oracle invece esiste la nozione di schema, corrispondente in pratica al singolo utente, per postgresql esiste la possibilità di definire un "percorso di ricerca" nello spazio dei nomi, che dà priorità ad uno schema piuttosto che ad un'altro.
In postgresql lo spazio in cui si creano le tabelle una volta connessi è di default quello pubblico ("public"), ma se si crea uno schema con lo stesso nome dell'utente, questo diventa lo spazio di default in cui vengono create le tabelle. È quindi possibile sia l'approccio di mysql, che favorisce la portabilità delle basi dati verso postgres, sia quello Oracle: è infatti possibile escludere del tutto l'accesso allo schema pubblico a tutti.

08 aprile 2005

Indici e tablespace

Prima della versione 10g e l'avvento di ASM, per Oracle era possibile "solo" definire una serie di datafile e tablespace, ognuno composto da almeno un datafile.
Per ottimizzare le prestazioni solitamente si cerca di tenere dati e indici su dischi differenti.
Nel caso di mysql, con le tabelle MyISAM, si hanno vari datafile, sempre uguali per ogni tabella, tra i quali vi sono quelli con i dati e quelli con gli indici. Ovviamente via sql è impossibile specificare la loro sistemazione, quindi virtualmente sarebbe possibile sistemarli su dischi diversi dopo la loro creazione, mettendo al loro posto dei bei link simbolici. Vi lascio immaginare che cosa voglia dire mantenere una cosa simile. Diversamente per le tabelle InnoDB è possibile solamente specificare uno spazio su disco, composto da più datafile, su cui mettere le tabelle E gli indici. Quindi, se da un lato si "guadagna" la possibilità di definire lo spazio per le tabelle tramite datafile diversi, si perde la possibilità di indicare dove debbano essere scritti i dati.
Probabilmente dovrò passare, per lavoro, una fase di test di PostgreSQL, che promette molte possibilità che si trovano solo negli RDBMS più avanzati, tipo Oracle: trigger, procedure, ecc., e in più, dall'ultima versione, anche i tablespace.
Staremo a vedere.

07 aprile 2005

Quale database?

Qui al lavoro uso un "database" MySQL di grandi dimensioni.
Grandi per quanto possa significare qualcosa che occupa qualche GB, su una macchina con 2 GB di RAM e 4 processori Xeon HT, che vengono visti come 8 processori dal'OS e dalle applicazioni.

Parleremo spesso di mysql, ma come esempio, a mia personale opinione, di tutto ciò che NON dovrebbe essere un database.
Potete consultare questa pagina, oppure questa per capire quello che intendo.

L'anno scorso ho seguito un corso di DBA Oracle 9i alla Oracle a Sesto S. Giovanni; è stata una esperienza molto istruttiva, anche se un po' noiosa in alcuni momenti.

Ho in produzione un mysql 4.0.15, vabbè un po' vecchio, ma il non-plus-ultra al momento dell'installazione, effettuata tramite gli rpm ufficiali; è in configurazione master-slave con un'altra macchina identica.

Piccolo esempio per oggi:


CREATE TABLE `rudy` (
`valore` varchar(32) default NULL,
`descrizione` varchar(64) default NULL
) TYPE=MyISAM;

mysql> select * from rudy;
+---------+----------------------------------+
| valore | descrizione |
+---------+----------------------------------+
| Abbaino | non nel senso di abbaiare adagio |
| Belin | che bella figliola! |
+---------+----------------------------------+

mysql> select substring(valore, 1, 1), substring(descrizione, 1, 1) from rudy union select 'il_valore', 'la_descrizione' from rudy;
+-------------------------+------------------------------+
| substring(valore, 1, 1) | substring(descrizione, 1, 1) |
+-------------------------+------------------------------+
| A | n |
| B | c |
| i | l |
+-------------------------+------------------------------+


Basta così o continuo?

06 aprile 2005

Blog, Oracle e altri

Proprio ieri ho trovato un bel sito da seguire per mantenersi informati sul mondo Oracle, ovvero orablogs (v. link).

Prossimamente parleremo di Oracle e dei suoi siti, e anche di qualche (?) concorrente.

Oggi mi è arrivato da risolvere un bel problemino con mysql, che però richiede l'uso delle subquery. Ma parleremo anche di questo.

Un blog sui database?

Ciao a tutti!
Non contento di non poter condividere le piccole avventure quotidiane con il prompt SQL, ho deciso di creare un blog per vedere se è possibile:

- sentire le opinioni di altri utenti
- farsi due risate con gli splendidi errori imprevisti dei database
- essere utili in qualche modo!

Vorrei che questo blog diventasse un buon pretesto per condividere le conoscenze online, a partire dagli spunti che posso fornire io... beh, se no sarebbe un forum...

A presto