Dan Tow, SQL Tuning, O’Reilly Media
Anche se non si tratta di una pubblicazione recentissima, consiglio questo libro a tutti coloro che intendono consolidare la propria comprensione sulle basi del funzionamento interno dei principali DB.
Solo dopo aver esposto questi meccanismi, il libro guida il lettore verso l’analisi dei vari piani di esecuzione e del loro condizionamento al fine di migliorarne efficienza e robustezza.
Gli esempi fanno riferimento a vecchie versioni di Oracle, DB2, SQL Server; tuttavia i concetti base illustrati, poichè quasi sempre non legati alle varie implementazioni, possono essere estesi facilmente a tutti i possibili DB relazionali.
ciao,
mi piacerebbe capire un po’ di più come suddivide il carico di lavoro il software di un database (in particolare mySql) spalmandolo su thread e processi.
Forse con un approccio miope da programmatore mi viene da dire che se faccio operazioni di scrittura o di modifica sui dati sono bene o male “single thread” (cioè due richieste parallele vengono praticamente serializzate) ed in particolare vengono eseguite da un unico core.
Mentre se faccio query di lettura posso avere una certa dose di parallelismo e sfruttare in maniera migliore i core attualmente disponibili su molte macchine. Però dovrei avere una memoria condivisa da più processi credo. E la cosa non so se è possibile.
Il mio problema, stringi e taglia, è come ottimizzare il funzionamento del mio software su una macchina pesantemente multicore.
Il libro affronta ancge argomenti del genere ?
E in caso negativo, sai indicarmi riferimenti. Vorrei capirci qualcosa per interpretare i numeri che sto raccogliendo sul campo.
ciao e grazie
stefano
ps. se ti interessa, siccome devo scrivere un report sugli esperimenti che sto tentando, se vuoi, ti passo i risultati cui giungerò.
ciao Stefano,
SQL Tuning non descrive come funzionano i motori dei DB ma come dalle query SQL il DB ricerca ed aggrega le informazioni da estrarre attraverso la costruzione e la risoluzione di un piano di esecuzione.
Il problema che descrivi è noto con il nome di “lettori scrittori” nell’ambito della programmazione concorrente; esiste una quantità illimitata di letteratura su tale argomento e puoi approfondirlo in qualsiasi libro di programmazione concorrente.
In un DB reale gli accessi concorrenti ai dati vengono regolati tramite dei lock molto più granulari e complessi rispetto alla tua ipotesi:
es. controllo concorrente in PostgreSQL
pertanto possono esistere molti processi che scrivono concorrentemente su oggetti diversi del DB (es. tabelle, righe, …).
Se ti interessa capire come si può costruire un motore DB, ti consiglio:
Database Systems: The Complete Book.
Per quanto riguarda l’implementazione di MySQL puoi, invece, approfondire sul mysql internals o su:
Understanding MySQL Internals.
Dopo aver costruito il tuo modello, se riuscirai ad identificare un parametro qualitativo oggettivo che vuoi minimizzare (es. tempo di esecuzione), potresti anche pensare ad un algoritmo genetico (o qualche altro algoritmo) che ricerchi la configurazione ottima del tuo problema.
Sarò curioso di conoscere i risultati della tua ricerca.