Newsgroup: it.comp.java
Titolo: [OT-forse] Decisione linguaggio

Ciao a tutti,
un consiglio...
scenario
3 tabelle in mysql(ahime') una da oltre 30milioni di record, una 
da oltre 14milioni e una molto piu' piccola con ~ 20mila record
ottimizzate con indici semplici e complessi per le query che devono essere
fatte.
il programma che bisogna sviluppare deve fare fondamentalmente 4 query su
queste tabelle(no join), il prototipo dello script e' gia stato scritto in
pseudocodice e ora mi trovo difronte alla scelta...in quale linguaggio
svilupparlo?
Il grosso problema, non sto a spiegare i motivi, e' il fatto che bisogna
processare la tabella da 30milioni di record a blocchi di minimo 500mila,
una volta caricati questi record scorrerli e fare da 1 a 3 query per ogni
record sulle altre tabelle per poi passare ai successivi 500mila e cosi
via.
Ho 3 possibilita', java ruby o php(anche se e' stato subito escluso).
La mia idea e' di utilizzare java e sono indeciso, nel caso dovessi
decidere per qesta strada, se utilizzare hibernate oppure no.
Logicamente la soluzione piu' veloce, a livello di esecuzione non di
sviluppo, e' quella che verra' scelta.
Voi cosa ne pensate?
Ciao,
cris

 sviluppo, e' quella che verra' scelta.
Ecco, appunto, quindi direi di lasciar perdere Hibernate, concentrarti 
sul DBMS e magari cominciare a crearti qualche stored procedure.
Ovviamente IMHO.
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://ammentos.biobytes.it
Flash tutorial: 
http://ammentos.biobytes.it/quickstart/quickstart.htm

 via.
Pole ti ha dato un ottimo suggerimento: la tua versione di MySQL è meggiore
o uguale alle 5 (ovvero, supporta le stored procedures)? 
	Vincenzo
-- 
Vincenzo Manzoni - 
www.vincenzomanzoni.com
e-mail: 
vin...@libero.it
 ICQ: 53662820


Sempre IMHO, per quello che puň valere la mia opinione, credo che Pole abbia
ragione: concentratevi sul DBMS e su *tutte* le ottimizzazioni che offre.
    Scorpio.

Innanzi tutto grazie per le risposte, ma purtroppo la versione di mysql e'
una 4.0 e non posso assulutamente permettermi di cambiarla, nel mio
messaggio citavo "mysql haime'" proprio perche non posso permettermi
stored procedure.
Purtoppo l'architettura del database mi lega un po le mani, un database
progettato oltre 4 anni fa poi cresciuto sempre piu' a causa dei continui
aggiornamenti/richieste di funzionalita' etc etc.
Sicuramente, se ne avessimo il tempo, sarebbe da riprogettare e, magari,
untilizzare un altro db, ma siamo in corsa e non possiamo quindi ci
dobbiamo adattare.
Comunque tra l'altro ieri e oggi ho fatto un po di test, in java, facendo
fare parte del lavoro all'applicativo1 e parte del lavoro all'applicativo2,
in poche parole:
ho UNO che preleva una set di record inizia a ciclare e fa determinate
operazioni su una tabella, nel momento in cui incontra determinate
condizioni chiama DUE, che e' un serverino xmlrpc che riceve soltanto, gli
passa quello cosi che UNO possa continuare senza dover aspettare la
risposta dal database(la fine della/e query).
In questo modo ho ottenuto risultati nettamente migliori piuttosto che far
fare tutto a UNO all'interno del ciclo.
Ora ci sono altre problematiche da risolvere ma la velocita' e'
accettabile.
PS per foruna settimana prox vado in vacanza cosi ci posso pensare a mente
sgombra :)
Intanto se volete mandare altri suggerimenti... io accetto tutto
Ciao
cris

untilizzare un altro db
In quel caso tieni presente PostgreSQL ;-)
Oltre a non avere i limiti dell'utilizzo commerciale di MySQL, è anche
più solido.

crx wrote:
[..]
Noi per un problema simile al tuo... (noi dovevamo fare join con tabelle 
da 60 mln di record ), con uno spavento di dati alla fine avevamo usato 
il C .... però ti parlo della 3.23 .. ed è stato un lavoro non molto 
complesso. Un'altra alternativa che secondo me puo essere valida è l'uso 
di perl e dbi .... non mi piace come sintassi ma io lo ho trovato molto 
efficiente

il C .... 
Ma che diavolo c'entra il linguaggio di programmazione da usare con la
mole dei dati su cui operare?  Usare il C o Java è irrilevante; come
altri hanno già detto, l'attenzione va focalizzata sul RDBMS, è lui
che esegue le operazioni sui dati.
Usare il C non agevola, se si ha comunque sotto un RDBMS che non è in
grado di operare efficientemente con moli di dati consistenti.

[...]

Non è sempre vero, le api native di mysql erano all'epoca molto + 
efficienti del connector java dell'epoca....ora spero sia migliorato... 
ma sul fetching di grosse moli di dati la differenza si vedeva

ma sul fetching di grosse moli di dati la differenza si vedeva
Può darsi che ci siano dei problemi legati ai connector Java, in
particolare, ma ti assicuro che nel valutare un problema come quello
dell'OP, il linguaggio di programmazione da utilizzare è l'ULTIMO dei
problemi.  Bisogna stabilire bene in che modo costruire la base dati,
cosa normalizzare, cosa no, quali stored procedure creare, se fare
delle viste, valutare le performance nei casi limiti, eseguire in
sostanza un tuning del DB accurato.
Che poi ad esso si acceda da C o Java o Paperino, poco importa.

 svilupparlo?
La quasi totalità del lavoro sui dati dovrebbe svolgerla il DB. Forse
la domanda corretta è "quale db usare"?