Il database dimenticato e il database sottovalutato

Questo post nasce dopo aver seguito (e obiettato) alcuni talk al Java Day IV edizione.

Questo post puo' sembrare molto di parte, ma in realtà non lo è; essendo però io coinvolto nel panorama PostgreSQL non posso fare a meno di citare quest'ultimo.

Con amarezza al Java Day si è parlato molto dell'importanza dei dati, di tecniche di persistenza, di sistemi database, di RDBMS, ma i nomi che sono venuti fuori quali sono stati? Al solito: Oracle, DB2, MySQL. Sarà stata la presenza di Sun (e Oracle) e di IBM fra gli sponsor? Puo' essere, ma visto che si parla di OpenSource e soluzioni innovative, non vale la pena citare PostgreSQL? E se proprio non vi piace, potete almeno citare MariaDB (il fork di MySQL)? Possibile che dopo tutti gli sforzi della comunità PostgreSQL si debba ancora sentire parlare solo di Oracle o, quando si vuole abbondare nell'OpenSource, di MySQL?

Ma se fosse solo un problema di propaganda, questo mio post potrebbe fermarsi qui. E invece devo dire che, ancora con maggior amarezza, ho sentito cose allucinanti su queste bestie sconosciute che sono i DBMS. Ancora una volta si assiste al programmatore che pretende di saperne di piu' del DBA, e che vuole usare le proprie soluzioni per scavalcare quello che non capisce o non sa come usare al meglio. E io non sono da meno! Ma è meglio scendere in maggiori dettagli.

L'errore piu' grossolano è quello di cercare di giustificare la nascita di soluzioni e paradigmi innovativi dietro a problemi implementativi. Ad esempio ho sentito dire che un DMBS è scomodo perché se si deve aggiungere anche una sola colonna occorre riavviare il database (in piena notte, perché non lo si vuole certo fare nel momento di maggior carico!). E allora serve una soluzione che permetta al sistemista di dormire tranquillo e di non doversi alzare in piena notte per aggiungere una colonna. Per citare un famoso telefilm: "che cavolo stai dicendo Willis?". Non ho mai sentito che un database abbia bisogno di un riavvio in seguito ad una ALTER TABLE. Certo, l'alterazione della tabella potrebbe non essere immediato, a causa di concorrenza e locking, ma se non si puo' aspettare il tempo necessario alla fine delle transazioni significa che il DBMS è (molto) mission critical, e quindi si deve prevedere una qualche nottate in bianco. Altrimenti significa che il database implementa male l'ALTER TABLE, ma fino ad ora non ho ancora incontrato un database che rchiedesse un completo restart! Forse l'applicazione puo' richiedere un restart, ma questo è un altro problema (non possiamo accusare il DBMS di un meccanismo legato al class loading o al caching di un application server!).

Non è finita qui: il partizionamento verticale e orizzontale non puo' funzionare, perché non è affidabile se non in un'ottica master-slave. Ma quest'ultima a sua volta non risolve il problema delle notti insonni, poiché la caduta di un nodo richiede la riconfigurazione (sempre manuale) del sistema. Ma ancora una volta, si sta erroneamente accusando un problema implementativo (la riconfigurazione del sistema) trattandolo come problema di paradigma (la replicazione funziona).

Andando avanti si scopre che il partizionamento richiede anche maggior carico alle applicazioni: essendo le tabelle (e i relativi dati) separati fisicamente fra diversi database (o cluster), non è possibile fare i join, che quindi sono tutti a carico dell'applicazione. Ma e lo standard SQL MED? E la teoria che il database deve ritornare i dati consistenti cercando di ridurre il carico di lavoro dell'applicazione?

Conclude il tutto la classica affermazione che i dati dovrebbero essere processati localmente, e non dovrebbero quindi circolare nella rete. E cosa vuol dire questo? Facile: trigger! Certo, è vero, i trigger lavorano localmente ai dati, ma hanno uno scope limitato ad una operazione che li faccia scattare, mentre una tecnologia di codice mobile (come ad esempio gli adentimobili) potrebbe portare migliori risultati.

Ma come si risolvono tutti i problemi di cui sopra? Con il solito trucco dei programmatori: si inserisce un middleware intermedio che nasconda molti dettagli implementativi.

Not Only SQL.

E' sbagliato questo approccio? Assolutamente no, ma presentarlo e giustificarlo dietro a problemi che derivano soloda una pigrizia implementativa del vendor di database o dietro alle scarse conoscenze dei motori relazioni (alter table che richiede un restart...) è assolutamente ridicolo. Soprattutto percé si tenta di attaccare i DBMS in quanto una soluzione non adatta a tutti gli scenari, ma per farlo si usa un cappello comune e generico, che di conseguenza non puo' essere adatto per tutti gli scenari. In altre parole, io ritengo che un DBMS sia una soluzione piu' che valida per moltissimi scenari, che laddove non appare valida si debba valutare se le conoscenze sui DBMS (e il DBMS che si usa in quel contesto) siano corrette, e solo se queste non siano sufficienti (a risolvere i problemi di contesto) si debba passare ad una soluzione di piu' alto livello (un middleware ad esempio).

Per non parlare poi della base di installato di DBMS e della formazione di tutti i DBA. E se è vero che non ci si deve fossilizzare sulle conoscenze acquisite, è anche vero che è meglio implementare nuove feature nell'esistente che non creare qualcosa di completamente nuovo.

Cosa si evince da questa mia esperienza? La prima cosa è che PostgreSQL necessita di ancora molto lavoro di propaganda per essere accettato come soluzione comune ove serva un DBMS enterprise. La seconda è che non bisogna mai confondere i problemi e le limitazioni dell'implementazione con quelle che sono le problematiche e le necessità di paradigma. Sicuramente il paradigma di NoSQL è ottimoo, ma in questa occasione è stato presentato veramente male.