Il server database: dietro le quinte di hwupgrade

Ciao Paolo,

sono contento che stai lavorando anche su articoli di questo tipo, sono di estremo interesse ad aiutano ad accrescere la cultura dei lettori, complimenti.

Ho un po' di osservazioni, invece, sulla soluzione tecnica adottata, molto semplice e con un livello di alta affidabilita' molto basso. Sono inoltre incuriosito dalla tua affermazione "abbandoremmo volontieri MySQL per SQLServer". C'e' qualche motivo particolare? Siete insoddisfatti per qualche lacuna in termini di funzionalita' o avete registrato dei malfunzionamenti? A mio avviso non avete utilizzato le feature di MySQL.

Il problema dei table lock, ad esempio, quando vbulletin scrive sul db e' dovuto al tipo di storage engine che avete utilizzato, MyISAM che supporta solo i table lock ma non i row level lock. Bastera' cambiare il tipo di storage engine in InnoDB che avere una concorrenza gestita molto meglio.
Il risvolto della medaglia e' che InnoDB non ha la search integrata. Ma qua ci viene in aiuto la replicazione di MySQL. In pratica possiamo avere un server con il db in InnoDB replicato su un altro server con lo stesso db e le stesse tabelle ma come MyISAM. In questo modo potrete utilizzare il secondo server come search server in sola lettura e l'InnoDB com server principale in lettura/scrittura.

Se poi avete bisogno di poter scalare in lettura (ovviamente immagino che il numero di letture sia molto piu' alto delle scritture), bastera' (sempre utilizzando la replica) scalare orizzontalmente e non comprando HW piu' potente. Questo e' il principio da sempre di MySQL: to scale out with commodity hw. Inoltre la replica ti permetterebbe di aumentare la disponiblita' del db, minimizzando i downtime ed accrescendo quindi l'affidabilita'.

Ah, dimenticato io lavoro in MySQL, se ti va di fare 4 chiacchiere, sai dove trovarmi!

Ben in effetti hai bisogno di un po' di spiegazioni, visto che non hai capito nulla di come funziona MySQL Cluster!!!

Ma non preoccuparti da quello che ho letto in questa discussione non sei l'unico...

Paolo, ti faccio una proposta, quand'e' che facciamo un bell'articolo su MySQL? Ho paura che la stragrande maggioranza non sappia nulla di MySQL ne' abbia capito a fondo le potenzialita'. E credo sia un vero peccato, a volte le soluzioni a problemi anche complessi sono davvero semplici...

Per quanto riguarda MySQL Cluster, non sono le letture ad essere distribuite ma i dati!! Cluster e' un in-memory db distribuito, significa che i dati sono automaticamente (e in modo trasparente per l'applicativo) partizionati sono piu' server, utilizzando di default la primary key come chiave di partizionamento.

Questo significa che le scritture scaleranno su piu' server (quasi linearmente per giunta) , mentre per le letture dipende dal tipo di query. Se sono query per primary key (o per la chiave di partizionamento utilizzata) l'accesso sara' diretto al nodo che contiene i dati, altrimenti per accessi in range scan (indice parziale o indice non univoco) occorre interrogare necessariamento tutti i nodi. Questo significa per in lettura non e' garantita la scalabilita' orizzontale lineare, dipende alle query.

Per aumentare l'affidabilita' ed evitare che alla caduta di un nodo si perda una parte del db, c'e' la possiblita' di replicare in modo SINCRONO ogni singolo nodo usando un protocollo di 2-phase commit

MySQL Cluster e' un prodotto complesso nato per il mondo delle telecommunicazioni, utilizzato ad oggi dai piu' grandi brand del settore. Non e' quindi un giocattolo da installare cosi' a tempo perso.

Se ne volete sapere di piu' sono a disposizione!

la scheda di gestione remota ti permette di caricare volumi da remoto, monitorare lo stato dell'hardware e rebootare/spegnere/accendere il server ecc...non solo uno schermo remoto e basta

Perdonami, ma non potevo non rispondere a questa boiata enorme, altrimenti poi alla fine qualcuno ci crede davvero!!

la granularita' di un lock non ha nulla a che vedere con il sistema operativo (a meno che tu non stia parlando di external lock, che sono tutt'altra faccenda).
In MySQL sono gli storage engine a dover implementare la gestione dei lock e questo funziona indipendentemente dal sistema operativo: MyISAM supporta solo i table lock, mentre InnoDB i row level lock. Falcon avra' una gestione dei lock piu' articolata, ma se ne riparlera' all'uscita del prodotto l'anno prossimo,...

Scusate, non sono un esperto di MySQL, ma ho avuto esperienza nel campo avendo scritto (in ASP e tramite ADODB connection e query SQL standard) un portale con E commerce, annunci, Knowledge base e altre cosette... Ma vBullettin non ha query normali SQL? Perchè non è possibile migrare ad altri DB? Utilizza chiamate a basso livello di MySQL per questioni di prestazioni? O utilizza un dialetto di SQL non compatibile?

In effetti e' un'ottima domanda: purtroppo ogni database implementa una sua versione di SQL...MySQL cerca di supportare appieno l'SQL 2003, ma e' difficile farlo alla perfezione, anche perche' spesso le standardizzazioni non sono complete, mancano di funzionalita' importanti.

Ora non so nel caso specifico di vBulletin, ma e' sufficiente che utilizzi la clausola LIMIT nelle select per far si che non funzioni su altri db!

volevo rinnovare i complimenti non tanto per l'articolo (in quanto li ho già fatti ) ma per la notevole disponibilità che stanno avendo Paolo e Davide a fornire ulteriori chiarimenti a noi [SIZE="1"]rompiscatole[/SIZE] del forum

GRAZIE

niente + che un serveretto
maneggio roba molto + grossa

Tipo?

E ci saranno sicuramente tecnici che gestiscono infrastrutture molto più grosse delle tue.
Detto questo, mi sfugge quale sia il contributo interessante di interventi di questo tipo per chi legge questa discussione.