Workstation per il database management

[davideleo]

Questa non è una richiesta per una build specifica, ma non saprei in quale altra sezione postarla. Cercando in rete configurazioni da workstation, trovo bene o male sempre le stesse tipologie di lavoro: animazione e modellazione; video e photo editing; produzione musicale; calcoli scientifici; programmazione e VR. Non trovo nulla che assomigli a una workstation finalizzata al database management. Quando si parla di database, la configurazione server-client è data per scontata e non capisco se questo è dovuto solo al fatto che generalmente i database sono multi-utente o se ci sono dei vantaggi anche prestazionali nel differenziare l'hardware di front-end e back-end.
Quello che intendo con workstation per il database management è una macchina ottimizzata per le query (in particolare definizione e manipolazione) di grandi recordset. In pratica mi riferisco a tutte quelle procedure di acquisizione, controllo e manutenzione dei dati che seguono la programmazione e precedono la messa in rete del database. Non so se ha senso definire l'hardware in funzione di questo tipo di prestazioni o se è assimilabile ad una delle tipologie di workstation elencate sopra. In rete tutt'al più trovo indicazioni sui requisiti per un database server, mentre a me interessano quelli per una macchina mono utente, senza tutte le preoccupazioni che derivano dalla condivisione del database.

 

[rctimelines]

Le query vengono eseguite in memoria, per un database grande serve tanta memoria... se per uso locale monoutente una qualsiasi discreta CPU con IPC elevato è sufficiente... diciamo che quella che viene definita "workstation" è eccessiva, basta un comune PC per avere prestazioni più che sufficienti.

Se si tratta di un server in condivisione di rete con molti accessi serve molta più memoria e soprattutto più threads (cores).

Inviato dal mio Nexus 5 utilizzando Tapatalk

 

[davideleo]

Le query vengono eseguite in memoria, per un database grande serve tanta memoria...

Il database è di media grandezza (circa un milione di record), ma è in rapida e continua espansione. Le prestazioni di I/O quanto incidono? Ho visto che alcuni database server utilizzano GPU come acceleratori hardware, oltre a RAID vari o addirittura storage all-flash.

se per uso locale monoutente una qualsiasi discreta CPU con IPC elevato è sufficiente...

Sì, per uso locale. Per CPU discreta intendi qualcosa come un i5 o anche un pentium di ultima generazione è adeguato?
Mi pare di capire che che non ritieni importante il numero di core, mentre vedo che nei database server utilizzano CPU a basso IPC, ma con molti core. Ne deduco che un alto numero di core è utile solo in ambiente multi-utente, ma non incide sulla velocità di esecuzione delle query. Ho capito bene?

 

[rctimelines]

Si, ma in dimensioni? Un database da un milione di record può essere da una decina di Mb in su, in ogni caso entra comodamente in RAM.. le operazioni di i/o incidono tantissimo, non c'è SSD che tenga!!!
Si, basta una CPU quad core, i calcoli non hanno elevato parallelismo... dell'uso della GPU non sapevo.

Il multicore serve nei server che devono gestire molti accessi, in tal caso non è tanto l'IPC basso, ma la frequenza, ma per ragioni energetiche, di affidabilità e di gestione del calore. Se sei monoutente un clock elevato insieme ad alto IPC ti permette prestazioni superiori.

Inviato dal mio Nexus 5 utilizzando Tapatalk

 

[davideleo]

Si, ma in dimensioni? Un database da un milione di record può essere da una decina di Mb in su, in ogni caso entra comodamente in RAM..

Faccio fatica a dirlo perché è un database multimediale. L'insieme dei file occupa qualche terabyte, ma i metadati, così a naso, non dovrebbero superare i 5 GB.

le operazioni di i/o incidono tantissimo, non c'è SSD che tenga!!!

Scusa, ma voglio essere sicuro di aver capito: stai dicendo che rimpiazzare gli HDD con SSD sarebbe un investimento sensato o il contrario?

Si, basta una CPU quad core, i calcoli non hanno elevato parallelismo... dell'uso della GPU non sapevo.

Il multicore serve nei server che devono gestire molti accessi, in tal caso non è tanto l'IPC basso, ma la frequenza, ma per ragioni energetiche, di affidabilità e di gestione del calore. Se sei monoutente un clock elevato insieme ad alto IPC ti permette prestazioni superiori.

Mi rendo conto solo adesso che non so che cosa sia l'IPC. Davo per scontato che fosse la velocità di clock. Come faccio a sapere quali sono i processori con un IPC alto?

 

[rctimelines]

Dico che le operazioni su disco sono da evitare il più possibile, anche un SSD veloce sarebbe una palla al piede.. serve memoria RAM e non disco.. comunque l'esecuzione di una query prevede delle ottimizzazioni per essere più efficiente.

IPC sono il numero di istruzioni che la CPU esegue per ogni ciclo di clock, quindi IPC + frequenza elevata sono l'optimus. IPC rappresenta l'efficienza reale di una CPU, attenzione che è un valore che si riferisce alle caratteristiche superscalari del singolo core, quindi aumentare il numero di cores non aumenta l'IPC della CPU

Inviato dal mio Nexus 5 utilizzando Tapatalk

 

[davideleo]

Ok, ti ringrazio dei chiarimenti. Riassumendo, sul lato hardware fondamentalmente conviene investire quanto più possibile in RAM. A questo proposito, considerato che molte delle query manipolano i dati, può essere utile la memoria ECC?

 

[rctimelines]

La RAM ECC è un po' più lenta e costa di più e comunque dipende dalla sensibilità dei dati (tra l'altro tu non devi garantire un servizio verso terzi, per cui un eventuale errore potrebbe non essere così grave.. inoltre l'integrità dei dati viene salvaguardata dal software).
Le probabilità che si verifichi un errore sono molto remote, se consideri che come mono utente il numero complessivo di operazioni è anche enormemente inferiore a quello che viene eseguito da un server condiviso..
Direi che la memoria ECC non sia un requisito importante.

Inviato dal mio Nexus 5 utilizzando Tapatalk

 

[davideleo]

Dico che le operazioni su disco sono da evitare il più possibile, anche un SSD veloce sarebbe una palla al piede.. serve memoria RAM e non disco..

Ho potuto fare una prova su una porzione di database corrispondente a una decina di gygabyte di file multimediali. La stessa query di aggiornamento ha impiegato quasi 2 minuti con i dati su HDD (sata II) e meno di 10 secondi con i dati su SSD (sempre sata II). Forse aumentando la RAM la differenza si riduce, ma mi sembra comunque un confronto impari. Suppongo che l'incidenza del disco sulle prestazioni sia dovuta non tanto all'esecuzione della query, ma a quello dei tag ID3 nei file multimediali che ne consegue.