Newsgroup: it.comp.software.database
Titolo: [MySql] - File su piu' dischi

Qualcuno mi sà dire se è possibile con MySQL fare questo:
1. Installare i file dei dati su un disco;
2. Mettere i file degli indici su altri dischi;
Volevo fare questo, xchè potrebbe migliorare le prestazioni: scrivo i dati
su un disco e mi aggiorna le chiavi su un altro.
Se si, come si fà?
--
Fabio

 ha scritto nel messaggio
news:al9p5o$2vpk$1...@newsreader1.mclink.it...


 Ora faro' delle prove.
Infinita gratitudine a te se ci farai sapere le prove come sono andate!
Intanto la pagina del manuale a riguardo e' cosa gradita!:-)
Saluti.
Luciano

 Intanto la pagina del manuale a riguardo e' cosa gradita!:-)
suppongo:
http://www.mysql.com/doc/en/Windows_symbolic_links.html
per linux il problema non sussiste!
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.ruby-lang.org/en/

 ha scritto nel messaggio
news:al9t4f$1nq57j$1...@ID-86073.news.dfncis.de...


 :-((( FABIO
:-(
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/philosophy/free-sw.it.html

 gli indici su un altro host.
E cosa cambia? La cpu che sgobba e' la stessa....sbaglio?
Saluti.
Luciano

 Saluti.
guai!!
il tempo di CPU effettivo ciucciato da un db sarà sempre meno di 1/10 del 
tempo di I/O!!
a meno che non entrino in gioco meccanismi + complessi di caching e di 
shared pools (vedi oracle et similar).
si può riassumere in 'percorso minimo da far effettuare alle testine del 
disco'. su tempi infinitesimali è quello che conta: basta vedere quando il 
pc inizia a swappare!!!!
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/philosophy/selling.it.html


la seconda kai detto !
basta solo pensare che, mentre la testina degli indici procura i dati
la testina dei dati può posizionarsi sugli stessi, dovrebbe chiamarsi
tempo di seek ?
più meccaniche sono coinvolte, minore è il tempo che occorre per
posizionare le testine.
in linea di massima :
il sistema su un disco
gli indici su un altro
i dati su un altro ancora
e il resto dipende dai soldi che si hanno.
--------------------------------
Inviato via 
http://usenet.libero.it

 pc inizia a swappare!!!!
Hem....io mi riferivo alla sua ipotesi di usare due host diversi. La cpu che
legge dovrebbe essere la stessa, no? Senza contare che la velocita' di un
bus e' sicuramente minore di una lan. Insomma, fermo restando che 2 dischi
sono piu' veloci di uno (su questo non ci piove), il dubbio da sciogliere
e': e' piu veloce 1 computer con 2 dischi o 2 computer con 1 ciascuno?
Saluti.
Luciano

 tempo di I/O!!
Aggiungo che quando faccio ricerche di stringhe di testo mysqld (winnt) si
ciuccia il 100% di cpu. E' chiaro che la velocita' di lettura del disaco e'
fondamentale, ma sembra che la ricerca delle occorrenze dia un carico
mostruoso anche alla cpu.
Saluti.
Luciano

 bus e' sicuramente minore di una lan.
Ovviamente intendevo dire l'opposto...
Saluti.
Luciano

| Aggiungo che quando faccio ricerche di stringhe di testo mysqld (winnt) si
| ciuccia il 100% di cpu. E' chiaro che la velocita' di lettura del disaco
e'
e che gli fai cercare? Il testo integrale della divina commedia dentro
il database della treccani? ;)
/G

 ha scritto nel messaggio


 ha scritto nel messaggio
news:EP_d9.7894$%z1.1...@twister1.libero.it...


 ha scritto nel messaggio
news:EP_d9.7894$%z1.1...@twister1.libero.it...


 ORACLE. Aspetto...
o volevi + velocità nei dati bulk o avevi meno soldi da investirci...
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/philosophy/free-software-for-freedom.it.html

 ciascuno? Saluti.
effettivamente avevo frainteso.
comunque sia, anche la divisione del carico di lavoro tra + host è una 
soluzione che si pratica sovente ma a scopi differenti dall'organizzazione 
dei dati.
tantissimi server hanno N CPU che possono venire sfruttate da db avanzati 
come l'opzione Parallel Server di Oracle (ottima per DWH) ma host 
differenti con risorse CPU e di memoria separate vengono utilizzate 
principalmente come unità di calcolo dei dati. ultimamente su Linux & C. 
avevano pubblicato una serie di articoli sui clusters e sul calcolo 
parallelo, se li potete reperire è una lettura interessante.
alla fine tutto dipende dal tipo di utilizzo del db...
ciao!
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/gnu/manifesto.it.html

 Ora punkarruso mi tirerà le orecchie o mi metterà in ginocchio sui ceci?
e perché mai dovrei??
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/gnu/why-gnu-linux.it.html

 parallelo, se li potete reperire è una lettura interessante.
E con mysql se po' fa?:-)
Mi riferisco sia alla multi cpu che alla multi host.
E gia che ci siamo, sperando di non abusare della tua disponibulita', c'e'
incremento notevole di prestazioni usando + dischi con un raid?
Saluti.
Luciano

 incremento notevole di prestazioni usando + dischi con un raid?
incremento forse si. notevole non saprei proprio.
ma hai dei problemi di performances con mysql?
al 99,9% dei casi i problemi di lentezza stanno nella scarsa ottimizzazione 
di indici/queries, indipendentemente dal rdbms...
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/philosophy/motivation.it.html

 di indici/queries, indipendentemente dal rdbms...
Mah, ho circa 1 milione di testi di qualche decina di Kb su cui fare
ricerche di stringhe, combinate con altri parametri quali autore, data, ecc.
Il manuale delle gioavani marmotte informatiche dice che hai 4 strade:
1) cerchi la stringa in tablescan (testo like '%pippo%')
2) ti crei una tabella di tutte le parole ed una di incrocio  (inner
join.....where parola = 'pippo'..)
3) ti crei una tabella di tutte le parole con una campo stringa con gli id
dei testi che la contengono (where idtesto IN (x.....n))
4) usi il fulltext index di MySQL
Beh, ho fatto una prova con 500.000 testi, generando una tabella di circa
600.000 parole ed una di incroci con 35 milioni di record e i risultati sono
stati:
1) Un cesso (ofcourse!)
2) Un missile se cerco una parola, un pianto se ne cerco due, un dramma se
aggiungo altri parametri.
3) Come sopra con l'aggavante di ritrovarsi con una stringa sql di 1 o 2 Mb
4) Un cesso (basta leggere i commenti sul sito MySQL.
Ora, io non saro' il principe dell'indice e della query, ma le ho provate un
po' tutte, soprattutto lavorando con EXPLAIN per capire dove non usava
l'indice, ma non ho ottenuto nulla di decente.
Mi hanno parlato qualche giorno fa su it.lavoro.professioni.webmaster della
teroria di Hash, di creare una tabella per ogni parola, ma non ho avuto
ancora modo di approfondire.Ogni suggerimento e' gradito!:-)
Saluti.
Luciano

ricerche di stringhe, combinate con altri parametri quali autore, data, ecc.
Mi pippo 75 cl di vodka e partorisco la seguente topata (date la colpa all'
alcool, io sono innocente, non c'ero e se c'ero ero in coma etilico):
- codifichi *tutte* le parole creando una prima tabella
	idParola	serial bigint
	parola		varchar
- ogni parola sara' contenuta in diciamo 10-100000 testi - e quindi ti crei
  una tabella di localizzazione
	idParola	bigint
	idTesto		bigint
- a questo punto, in MySQL, una query del tipo
	"I testi di Dijkstra fra il 1950 e il 2050 contenenti le parole
	 <proletariato> e <dialettica>"
  la puoi fare col seguente metodo topesco:
	id1 = SELECT idParola FROM vocab WHERE parola = 'proletariato';
	id2 = ...
	SELECT idTesto INTO TEMPORARY testi FROM loc WHERE idParola = id1;
	INSERT INTO testi SELECT idTesto FROM loc WHERE idParola = id[n];
	SELECT DISTINCT idTesto INTO TEMPORARY tab1 FROM testi;
	SELECT * FROM biblio JOIN tab1 USING (idTesto)
		WHERE idAuthor = idDjkstra
		AND data >= 1950 AND data <= 2050
		;
Leonardo che si versa un'altra mezza pinta. Prosit.
-- 
".signature": bad command or file name

 idTesto               bigint
non l'ho esaminata a fondo ma mi sembra buona.
farei però anche una tabella di parole ignorate (per esempio tutte le 
preposizioni, congiunzioni, articoli ecc.) un po' come su google che ti 
dice 'la parola 'a' è comune e sarà ignorata).
così ti snellisci un po' tutto.
comunque, lavorando un po' sull'architettura e creando all'occorrenza N 
tabelle di appoggio, ti eviti di spendere soldi per un supercluster di 
calcolo...
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://ethology.intercult.su.se/freescience/

 Leonardo che si versa un'altra mezza pinta. Prosit.
Passa a destra....:-)
Saluti.
Luciano

 calcolo...
E' esattamente quello che vorrei fare...ma mi sembra di essere ancora molto
lontano da una soluzione decente!:-)
Saluti.
Luciano

(idmsg, idparola) sono indicizzati.
Mumble. Se
SELECT idTesto INTO TEMPORARY testi FROM loc WHERE idParola = id1;
ci mette 30 secondi, significa che o deve leggersi uno zilione di dati
oppure che TROVA uno zilione di dati.
Per alleggerire almeno il caso (1), si puo' suddividere 'loc' in tante
sotto-tabelle
	idParola	bigint
	idTesto		bigint
loc0, loc1, locN-1
dove in ogni tabella loc_K ci sono solo gli id t.c. id mod N = K.
Al limite, usando N talmente grande da essere pari a max(idParola), ti
ritrovi con una tabella per ogni parola, contenente tutti i testi dove
quella parola e' presente.
Questo naturalmente non ci aiuta nel caso che una di quelle tabelle si
ritrovi ad avere dimensioni pazzesche. Pero' consente di stimare anche
la bonta' della query. Mi spiego: alla grossa, se io amplio la tabella
di traduzione
	idParola, Parola, numOccorrenze
assumendo che le parole siano scorrelate (il che non e'!), se ND e' il
numero di documenti, mi aspetto che la query ritorni
	(NumDoc sodd. query su data e autore)
	*
	PROD (i=0, Q)( numOccorrenze(i)/ND )
...questo conto lo posso fare senza lanciarmi in query sperticate e di
fronte a un risultato molto massiccio posso rifiutarmi di proseguire.
Inoltre posso proseguire per query accumulate:
	-- Query che si spera rapida
	SELECT idTesto INTO stage_0 FROM library WHERE
		data = ... AND autore ...;
	id1 = SELECT idParola FROM vocab WHERE testo='marxismo';
	tb1 = id1 % MaxID;
	-- Questo è un incrocio fra una query da 0.3 secondi e
	-- un numero di volumi che si spera ridotto (salvo che
	-- nel caso dell'opera omnia di Nicolas Bourbaki)
	SELECT INTO TEMPORARY stage_N
		DISTINCT X.idTesto
	FROM tb1 AS X, stage_(N-1) AS Y
	WHERE X.idTesto = Y.idTesto AND X.idParola = id1;
	DROP TEMPORARY TABLE stage_(N-1);
	if (SELECT COUNT(*) FROM stage_N) = 0 THEN
		Query fallita
	end if
	-- Si ripete il ciclo per N+1
Leonardo
