DataBase infinitamente grande

[starcraftworld]

Il problema non è sveltire i calcoli...

[filippo.toso]

IMHO utilizzare un database general purpose è illogico per gestire una tale mole di dati.

Per come hai descritto il progetto, il problema principale è l'archiviazione. Al mondo non credo esistano molte facility in grado di archiviare una così ampia mole di dati. Di sicuro sono molto pochè quelle accessibili a privati.

Se puoi descrivere in maggiori dettagli il progetto, magari qualche idea viene fuori. In particolare mi piacerebbe sapere come mai il DB "si può spezzare in parti a mano a mano che diventa grande". Certi dati diventano "storici" che non necessitano più per le successive elaborazioni?

[Emulman]

se ci pensi bene invece una cosa del genere servirebbe.: si potrebbe ripartire parte dei calcoli su ogni server e ogni CPU del server controlla ogni singolo server mysql, altrimenti si avrebbero enormi rallentamenti...
quello che vuoi fare tu credimi richiederebbe una cosa del genere altrimenti se metti tutto sul tuo PC non andresti molto lontano, sia come velocità che come memorizzazione...

[starcraftworld]

Esatto. Circa un milione di record sono necessari a generare il record successivo.
Di tutti quelli precedenti ne servirà solo uno ma per sapere quale avrò bisogno di conoscere l'ultimo record della tabella, una volta finita l'elaborazione.

[filippo.toso]

Originariamente inviato da Emulman
se ci pensi bene invece una cosa del genere servirebbe.: si potrebbe ripartire parte dei calcoli su ogni server e ogni CPU del server controlla ogni singolo server mysql, altrimenti si avrebbero enormi rallentamenti...quello che vuoi fare tu credimi richiederebbe una cosa del genere altrimenti se metti tutto sul tuo PC non andresti molto lontano, sia come velocità che come memorizzazione...

Non mi sembra di aver scritto "non ritengo che l'utilizzo di un cluster o di una architettura GRID" servirebbe. Ho scritto che utilizzare un database general purpose è illogico per gestire una tale mole di dati. Un formato proprietario è di gran lunga la strada migliore da percorrere. Che poi venga implementato in un ambiente distribuito o meno, è irrilevante ai fini della discussione.

[starcraftworld]

Ok, ma per formato proprietario intendi Google File System e simili?

[filippo.toso]

Originariamente inviato da starcraftworld
Esatto. Circa un milione di record sono necessari a generare il record successivo.
Di tutti quelli precedenti ne servirà solo uno ma per sapere quale avrò bisogno di conoscere l'ultimo record della tabella, una volta finita l'elaborazione.

In questo caso puoi iniziare l'implementazione anche su un singolo PC. Un milione di record sono "archiviabili" in poco più di 116 Mb di memoria. Molto probabilmente puoi gestire il tutto in RAM in modo che sia ancor più veloce l'elaborazione.

Rimane il problema di archiviare tutta la tabella per poter ricavare il valore che ti serve al termine dell'elaborazione.

Sei davvero sicuro che non si possa implementare l'algoritmo in modo da ridurre la quantità di dati necessari ad ottenere il risultato voluto?

EDIT:

Originariamente inviato da starcraftworld
Ok, ma per formato proprietario intendi Google File System e simili?

Intendo un file (od spazio in memoria) nel formato indicato in precedenza. Un record di 2 Int64 ed un CHAR di 100 byte.

[starcraftworld]

Purtroppo questo è l'unico modo

[sgraffin]

salve a tutti,

direi che ci sono databse gia fatti per la gestione di dati estremamente grandi anche se non al livello che in questo topic si evidezia.

faccio degli esempi
mysql gestisce i portali di yahoo... probabilmente parliamo di milioni di records quindi siamo ancora lontani


oracle gestisce in genere le transazioni per i sistemi di telefonia.... qui iniziamo a parlare di record nell'ordine dei miliardi.

ora bisogna capire questo progetto che finalità si propone.
di quale budget.

io inizialmente opterei per mysql.

e' possibile cmq realizzare strutture molto complesse grazie alle tecniche di replica.

ho letto che il database dovrebbe essere consultato quindi (select ) e nello stesso tempo aggiornato (insert) quindi sicuramente la soluzione ideale per le prestazioni sarebbe quella di avere un server di replica di sola lettura mentre il master si occuperebbe degli insert

[filippo.toso]

Originariamente inviato da sgraffin
io inizialmente opterei per mysql.

Per l'obiettivo ed il tipo di dati che devono essere manipolati, l'utilizzo di un database SQL (qualunque esso sia) introduce solo complessita ed overhead inutili.