[Php-it] scelte prestazionali

[Domenico L.]

Luca 'Ziabice' Gambetta ha scritto:
> On Thursday 28 September 2006 16:19, Emiliano Gabrielli (aka AlberT) wrote:
>   
> Tempo fa sono stato costretto a far fare tutte le operazioni su un db a php 
> perché semplicemente il db server si coricava. Lo scenario era una tabella 
> mysql (invero normalizzata molto male) con circa 1 milione di record di cui 
> ovviamente ne prendevo una parte (tra i 20 e i 100 mila record, a seconda dei 
> casi) e che dovevo incrociare con altre tabelle per eseguire delle 
> sincronizzazioni.

I dbms non sono in grado di sostituire il progettista.

Mi sembra di capire che nel tuo caso specifico con qualsiasi dbms 
avresti dovuto fare dei giri, al più avresti potuto creare delle stored 
procedure (soluzione più veloce e pulita).

Nel computo delle performance bisogna sempre tener conto non tanto del 
numero di record ma del numero di blocchi che si leggono.

Se la tabella cui ti riferivi aveva molti attributi e i record sono 
molto sparsi rispetto al criterio di estrazione, significa che per ogni 
query devi farti delle full table scan.

A questo punto per qualsiasi dbms la soluzione migliore è quella di 
popolare una tabella temporanea con solo gli attributi che ti 
interessano (magari solo le chiavi primarie) magari utilizzando una 
struttura ordinata in struttura primaria (in oracle si chiamano IOT) o 
di una hash table (detti anche cluster), queste sono le finezze che 
incontri quando parli di dbms seri, ma la sostanza di utilizzare una 
tabella di appoggio resta la stessa.

Preciso che naturalmente procedendo con una insert su una tabella dei 
soli attributi necessari otterremo una tabella con blocchi molto densi 
quindi pochi accessi al disco, ciò non di meno è cmq consigliabili 
definire degli indici ad hoc su questa tabella, perché mica sempre si 
accederà in FTS

Per capire che è meglio far fare a mysql il lavoro di mysql e non a php 
basta pensare che un record estratto da php viene messo in un array 
(simile agli hashmap di java) dove (non sono sicuro che sia esattamente 
così ma è verosimile) per ogni accesso è richiesto di calcolare una 
funzione per capire dove si trova la struttura, struttura che ovviamente 
non è tipizzata e non ha delle lunghezze prefissate per cui bisogna 
leggere campo per campo (e stiamo parlando di un altro array, di 
un'altra funzione di hashing...) la sua dimensione.

Tutto questo overhead mysql non l'ha, oltre che ricordarsi che php non è 
ottimizzato, non è compilato (è compilato on demand ma non è la stessa 
cosa) e non ha i controlli di tipi, questo vuol dire che la gestione 
degli errori di tipo di solito effettuato in tempo di compilazione passa 
in run time...


Ciao

-- 
Domenico L.

per stupire mezz'ora basta un libro di storia,
io cercai di imparare la Treccani a memoria... [F.d.A.]