http://blogs.sun.com/jonathan/entry/winds_of_change_are_blowing
strana notizia, dato che Sun e' (era?) il principale supporter di
PostgreSQL.
Questo potra' avere conseguenze nel settore GIS, ovviamente.
pc
--
Paolo Cavallini, see: http://www.faunalia.it/pc
Ricordo quello che avvenne quando
la stessa Sun compro' Star-Office.
Star-Office , all'epoca, era un prodotto free e open-source
lanciatissimo a diventare il possibile sostituto di Microsoft-Office.
mentre, sempre all'epoca, Open-Office era un fork "povero" di Star-Office.
Infatti aveva molto meno funzionalita' rispetto a Star-Office, ed era
anche meno stabile.
Dopo che Sun acquisto' Star-Office lo mise a pagamento (25 dollari ?).
E da quel momento la community degli sviluppatori si rivolse verso
Open-Office lavorando per potenziare tale prodotto.
Se e' vero che la storia si ripete questo vuol dire che chi oggi usa
MySQL in quanto gratuito, probabilemnte dovrebbe cominciare a
guardarsi intorno e cercare un sostituto, nell'ipotesi che MySQL
divenga un prodotto a pagamento.
Pero' non vedo che conseguenze avrebbe nel mondo GIS.
Visto che MySQL non ha niente di rilevante dal punto di vista delle
funzionalita' GIS.
Forse intendi che smettera' di sovvenzionare Postgres ?
Andrea.
Il 16/01/08, Paolo Cavallini<cavallini@faunalia.it> ha scritto:
http://blogs.sun.com/jonathan/entry/winds_of_change_are_blowing
strana notizia, dato che Sun e' (era?) il principale supporter di
PostgreSQL.
Questo potra' avere conseguenze nel settore GIS, ovviamente.
pc
--
Paolo Cavallini, see: http://www.faunalia.it/pc_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~
Andrea Peri ha scritto:
...
Pero' non vedo che conseguenze avrebbe nel mondo GIS.
Visto che MySQL non ha niente di rilevante dal punto di vista delle
funzionalita' GIS.
Beh, un po' di WMS lo puoi fare, ma certo siamo anni luce di
distanza da PostGIS. Speravo avesse prestazioni migliori, ma dai
miei ultimi test risulta che le prestazioni di mysql e postgis
sono le medesime (che delusione...)
Ciao
Andrea
se capisco quello che riporti, mysql avrebbe prestazioni uguali a
postgres + postgis ?
Non me lo sarei mai aspettato, pero' va comunque tenuto conto che il
set di funzionalita' GIS di mysql e' ridotto rispetto a quello di
postgis (o sbaglio ?)
Andrea.
Il 17/01/08, Andrea Aime<aaime@openplans.org> ha scritto:
Andrea Peri ha scritto:
...
> Pero' non vedo che conseguenze avrebbe nel mondo GIS.
> Visto che MySQL non ha niente di rilevante dal punto di vista delle
> funzionalita' GIS.Beh, un po' di WMS lo puoi fare, ma certo siamo anni luce di
distanza da PostGIS. Speravo avesse prestazioni migliori, ma dai
miei ultimi test risulta che le prestazioni di mysql e postgis
sono le medesime (che delusione...)Ciao
Andrea
--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~
Andrea Peri ha scritto:
se capisco quello che riporti, mysql avrebbe prestazioni uguali a
postgres + postgis ?
Nei test che ho fatto, si, le prestazioni sono pressoche identiche.
http://www.nabble.com/MySql-5.1…-what-a-delusion…-to14556654.html#a14556654
Non me lo sarei mai aspettato, pero' va comunque tenuto conto che il
set di funzionalita' GIS di mysql e' ridotto rispetto a quello di
postgis (o sbaglio ?)
In effetti, la conclusione che ho fatto nella mail di cui sopra
è che non vale la pena di usare le estensioni spaziali di MySql
in nessun caso... se le prestazioni fossero migliori vabbè, il
WMS ci cadrebbe a fagiolo, ma così...
Ciao
Andrea
Andrea Peri ha scritto:
Ricordo quello che avvenne quando la stessa Sun compro' Star-Office.
Star-Office , all'epoca, era un prodotto free e open-source
lanciatissimo a diventare il possibile sostituto di Microsoft-Office.
A dire il vero Star-office c'era solo per *nix, era praticamente sconosciuto, pochissimo interoperabile con il mondo M$, per niente Free e poco OS..
mentre, sempre all'epoca, Open-Office era un fork "povero" di Star-Office.
Infatti aveva molto meno funzionalita' rispetto a Star-Office, ed era
anche meno stabile.Dopo che Sun acquisto' Star-Office lo mise a pagamento (25 dollari ?).
tu hai la memoria un po' confusa..
Star-office lo usavo all'università ed era gratuito SOLO ed esclusivamente per le istituzioni educative, per tutti gli altri era a pagamento (in marchi perché lo sviluppo era di una società tedesca)
SUN comprò il codice annunciando da subito che l'avrebbe reso completamente Open (cosa che non era)
E ricordo anche che fosse lentissimo, bacatissimo e complicaterrimo da compilare
E da quel momento la community degli sviluppatori si rivolse verso
Open-Office lavorando per potenziare tale prodotto.
forse perché ebbero la certezza che il loro lavoro sarebbe stato valorizzato e che il prodotto avrebbe goduto di maggior visibilità di prima.
Se e' vero che la storia si ripete questo vuol dire che chi oggi usa
MySQL in quanto gratuito, probabilemnte dovrebbe cominciare a
guardarsi intorno e cercare un sostituto, nell'ipotesi che MySQL
divenga un prodotto a pagamento.
Io invece la vedo in maniera diammetralmente opposta.
MySQL è un ottimo prodotto, viene usato in ambienti estremi (Google e Wikipedia per citarne 2).
Ha ancora grossissime deficienze (SMP, Stored Procedures, Viste...)
Ad occhio e croce SUN concentrerà tutti gli sforzi in una riscrittura e ripulitura di MySql 6.x lasciando il ramo 5.x alla manutenzione
La versione 6.x sarà probabilmente molto più veloce delle 4 e 5, anche senza avere novità fondamentali
dalla 7.x in poi mi aspetto uno sviluppo rapidissimo e entro la 8.x potrebbe diventare un prodotto talmente completo da far davvero paura a colossi come Oracle..
Pero' non vedo che conseguenze avrebbe nel mondo GIS.
Visto che MySQL non ha niente di rilevante dal punto di vista delle
funzionalita' GIS.
Immagino che se la comuità farà operazione di lobbying da questo fronte si potranno avere moltissime sorprese.
--
Edoardo Marascalchi
ICT Consultant
website: http://www.edoardomarascalchi.it
skype: My status <skype:asca_edom?call>
On Thu, Jan 17, 2008 at 04:12:33PM +0100, Edoardo Marascalchi wrote:
Andrea Peri ha scritto:
> Se e' vero che la storia si ripete questo vuol dire che chi oggi usa
> MySQL in quanto gratuito, probabilemnte dovrebbe cominciare a
> guardarsi intorno e cercare un sostituto, nell'ipotesi che MySQL
> divenga un prodotto a pagamento.
>
Io invece la vedo in maniera diammetralmente opposta.
MySQL è un ottimo prodotto, viene usato in ambienti estremi (Google e
Wikipedia per citarne 2).
Ha ancora grossissime deficienze (SMP, Stored Procedures, Viste...)
Ad occhio e croce SUN concentrerà tutti gli sforzi in una riscrittura e
ripulitura di MySql 6.x lasciando il ramo 5.x alla manutenzione
Un'altro spunto.
Il copyright di MySQL era tutto in mano a MySQL ab, quindi ora in mano a SUN.
La licenza di MySQL e' GPL, quindi NON puo' essere incluso in prodotti
proprietari, ma chi vuole farlo puo' comprare un'altra licenza dal proprietario
unico del copyright.
Puo' anche darsi che SUN voglia provare un altro modello di business...
--strk;
http://www.linux.com/feature/124909#commentthis
interviste (in video) molto interessanti alle persone coinvolte sia in SUN che in MySQL.
--
Edoardo Marascalchi
ICT Consultant
website: http://www.edoardomarascalchi.it
skype: My status <skype:asca_edom?call>
Andrea Aime ha scritto:
Beh, un po' di WMS lo puoi fare, ma certo siamo anni luce di
distanza da PostGIS. Speravo avesse prestazioni migliori, ma dai
miei ultimi test risulta che le prestazioni di mysql e postgis
sono le medesime (che delusione...)Ciao
Andrea
Scusami, ma dissento. Da test e misure oggettive a me risulta che gli Spatial
di MySQL 5.0 girano in modo sensibilmente più veloce dei corrispondenti
su PostgreSQL 8.2 + PostGIS.
La differenza è molto marcata sotto Windows, ma anche sotto Linux
MySQL rimane sensibilmente più veloce.
Naturalmente ci sono un paio di "questioni di dettaglio" che vanno [forse]
meglio specificate:
1) le configurazioni di default [per entrambi] sono decisamente ridicole;
è vero che l'impronta di memoria è minimale, ma poi girano da
fare pena
2) PostgreSQL sotto Linux [ma non su Windows] fornisce una configurazione
di default ragionevolmente dimensionata; invece quelle di MySQL
richiedono un attento tuning se si vuole ottenere un livello di performace
decoroso.
3) MySQL [5.0 versioni recenti] supporta gli Spatial su quasi tutti gli
engines, ma comunque gli SpatialIndex sono supportati solo ed
esclusivamente sull'engine MyISAM, che non è ACID e neppure
transazionale ... ovvio che se si usa un altro engine [p.es. InnoDB]
che non supporta gli SpatialIndex, allora tutto frana ...
4) il set di funzionalità OpenGis supportato da MySQL è limitato
all'osso, ma ce n'è comunque quanto basta per supportare
decentemente un web server cartografico non banale.
Insomma, io uso da 12 mesi MySQL per supportare tutta la
rete dei trasporti pubblici della Regione Toscana [complessivamente
sono un paio di MILIONI di entità GIS, compresa la CTRT],
e mi gira tutto come un treno e senza sorprese ...
http://www.osservatorio-trasporti.it/Public/
Sandro Furieri
Alessandro Furieri ha scritto:
Andrea Aime ha scritto:
Beh, un po' di WMS lo puoi fare, ma certo siamo anni luce di
distanza da PostGIS. Speravo avesse prestazioni migliori, ma dai
miei ultimi test risulta che le prestazioni di mysql e postgis
sono le medesime (che delusione...)Ciao
Andrea
Scusami, ma dissento. Da test e misure oggettive a me risulta che gli Spatial
di MySQL 5.0 girano in modo sensibilmente più veloce dei corrispondenti
su PostgreSQL 8.2 + PostGIS.
La differenza è molto marcata sotto Windows, ma anche sotto Linux
MySQL rimane sensibilmente più veloce.
Li ho testati sotto windows, entrambi configurazioni di default,
con accesso via jdbc. Non so che dire, i numeri non me li sono inventati.
Ciao
Andrea
Andrea Aime ha scritto:
Alessandro Furieri ha scritto:
Andrea Aime ha scritto:
Beh, un po' di WMS lo puoi fare, ma certo siamo anni luce di
distanza da PostGIS. Speravo avesse prestazioni migliori, ma dai
miei ultimi test risulta che le prestazioni di mysql e postgis
sono le medesime (che delusione...)Ciao
Andrea
Scusami, ma dissento. Da test e misure oggettive a me risulta che gli Spatial
di MySQL 5.0 girano in modo sensibilmente più veloce dei corrispondenti
su PostgreSQL 8.2 + PostGIS.
La differenza è molto marcata sotto Windows, ma anche sotto Linux
MySQL rimane sensibilmente più veloce.Li ho testati sotto windows, entrambi configurazioni di default,
con accesso via jdbc. Non so che dire, i numeri non me li sono inventati.
Btw, hai qualche suggerimento per far andare MySql più veloce?
Può essere che la config di default di mysql è inferiore a quella
di postgres sotto windows...
Altra cosa che ho notato è che inserire i dati in mysql è una vera
pena, il caricamento dello shapefile in postgres è stato _molto_
più veloce. Ti viene in mente nulla che possa essere fuori posto?
Io sto usando MySql 5.1
Ciao
Andrea
Ho dato una occhiata all'articolo.
Molto interessante
Poi sono andato a dare una occhiata alla documentazione di Mysql 6
sulle estensioni spaziali che ha.
http://dev.mysql.com/doc/refman/6.0/en/spatial-extensions.html
1)
Intanto MySQL usa solo X e Y non usa assolutamente la Z.
come si denota chiaramente da questa pagina:
http://dev.mysql.com/doc/refman/6.0/en/gis-class-point.html
E gia' questo e' un grosso punto a sfavore.
La richiesta e' ormai rivolta a prodotti che gestiscano, almeno come
archiviazione, la Z.
Non riesco a capire perche' ad oggi ancora non ci si preoccupa di
archiviare la Z
Io ritengo che prodotti che non archivino la Z sono anacronistici e
non hanno attrattiva nel mercato dei GIS.
2)
Mysql gestisce wkt/wkb . In questo e' allineato agli altri prodotti.
Non ha pero' funzioni di esportazioni/importazione in GML .
3)
La sua documentazione riporta una listata di funzioni per testare le
relazioni spaziali tra le varie geometrie. E in questo sarebbe
allineato agli altri prodotti (all'incirca).
Pero', in cima alla pagina vi e' una postilla:
Currently, MySQL does not implement these functions according to the
specification. Those that
are implemented return the same result as the corresponding MBR-based
functions. This includes
functions in the following list other than Distance() and Related().
These functions may be implemented in future releases with full
support for spatial analysis, not
just MBR-based support.
Il che significa che al momento tutte queste funzioni.anziche' agire
sull'area esatta della geometria (se poligonale) agiscono sul
rettangolo di ingombro.
Immagina una funzione di intersect agente su una linea obliqua che
ritorna in realta' tutte le geometrie che intersecano l'ingombro
rettangolare di tale linea obliqua. Bello !
Ricordavo bene.
La modalita' spaziale di Mysql serve a poco.
Indipendentemente dalla velocita' che puo' raggiungere.
Andrea.
Nei test che ho fatto, si, le prestazioni sono pressoche identiche.
http://www.nabble.com/MySql-5.1…-what-a-delusion…-to14556654.html#a14556654
--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~
Il che significa che al momento tutte queste funzioni.anziche' agire
sull'area esatta della geometria (se poligonale) agiscono sul
rettangolo di ingombro.
Te lo confermo perchè tempo fa andai a guardare il codice e rimasi a
bocca aperta...
come dire "era meglio che non ci mettevamo niente, almeno non stavamo
a vendere aria fritta..."
BTW avete mai testato questo?
http://www.codeplex.com/MsSqlSpatial
le operazioni spaziali sono reali, anche xchè
<pubblicita>son fatte con la "mia" NetTopologySuite:
http://code.google.com/p/nettopologysuite/</pubblicità>
On Thu, 17 Jan 2008 18:31:25 +0100, Andrea Aime wrote
Li ho testati sotto windows, entrambi configurazioni di default,
....
Btw, hai qualche suggerimento per far andare MySql più veloce?
Può essere che la config di default di mysql è inferiore a quella
di postgres sotto windows...
Ciao
Andrea
Credo che il problema è esattamente quello; sia con MySQL che
con PostgreSQL utilizzare le configurazioni di default [specie
su Windows] è come pretendere di cronometrare quanto corre
un levriero, ma tenendogli le zampe legate strette strette ...
Una domanda: ma in JDBC hai impostato:
Connection.setAutoCommit(false); ???
se non l'hai fatto è chiaro che le scritture impiegano
secoli; se è AutoCommit = true [by default !!!]
stai disabilitando tutte le ottimizzazioni sui buffers,
e devi aspettare che ciascuna singola riga sia fisicamente
scritta sul disco, una per volta ...
=========================================================
Comunque, per quanto riguarda le configurazioni:
su win il config di MySQL dovrebbe essere (se hai usato
l'install standard):
C:\Programmi\MySQL\MySQL Server 5.0\my.ini
mentre su Linux lo trovi su: /etc/my.cnf
su un PC WinXP [512MB ram] io ho assegnato:
query_cache_size=32M
myisam_max_sort_file_size=128M
myisam_max_extra_sort_file_size=64M
myisam_sort_buffer_size=64M
key_buffer_size=96M
read_buffer_size=64K
read_rnd_buffer_size=256K
sort_buffer_size=64M
invece un server Fedora7 [2GB ram] io ho assegnato:
query_cache_size=32M
myisam_max_sort_file_size=128M
myisam_max_extra_sort_file_size=64M
myisam_sort_buffer_size=64M
key_buffer_size=256M
read_buffer_size=2MB
read_rnd_buffer_size=8M
sort_buffer_size=256M
Chiaramente più ram metti e meglio gira; ma se poi
non ne rimane abbastanza per gli altri processi vai
in swap, e allora tutto peggiora catastroficamente !
E' tutto spiegato abbastanza chiaramente nella documentazione;
inoltre trovi vari config preconfezionati nella distro, che
si chiamano my-small, my-medium, my-large, my-huge etc
Puoi anche usare il GUI tool MySQLAdministrator per impostare
i parametri di config [StartupVariables]
In tutti i casi devi riavviare il servizio per rendere effettive
le modifiche
CONSIGLIO DA AMICO: salvati prima da qualche parte il my.cnf
originale, perchè se padelli qualcosa rischi che MySQL
non riesce proprio a ripartire !!!!
Comunque se consulti il log ti dice dove è l'intoppo ...
Sandro Furieri
Si, forse ricordavo male.
Troppa acqua e' passata sotto il ponte ....
Ha ancora grossissime deficienze (SMP, Stored Procedures, Viste...)
Ad occhio e croce SUN concentrerà tutti gli sforzi in una riscrittura e
ripulitura di MySql 6.x lasciando il ramo 5.x alla manutenzione
La versione 6.x sarà probabilmente molto più veloce delle 4 e 5, anche
senza avere novità fondamentali
dalla 7.x in poi mi aspetto uno sviluppo rapidissimo e entro la 8.x
potrebbe diventare un prodotto talmente completo da far davvero paura a
colossi come Oracle..
Puo' darsi anche che vada a finire cosi'.
Del resto SUN punta molto sul software OS.
Il fatto e' che comincia a delinearsi una strategia di sistema.
SUN possiede un linguaggio di programmazione (java) una suite da
ufficio (star-office)
un dbms (mysql), un sistema operativo (solaris per intel)
Tutta roba OpenSource.
Ma anche tutta roba che permette a Sun di offrire una soluzione
All-In-One a ditte e grossi clienti.
Tieni presente che SUN e' una ditta che per vocazione ignora il
mercato di piccolo cabotaggio, ma bensi' punta alle grosse commesse.
Offrire una soluzione All-In-One , con capacita'' di garantire la
manutenzione, puo' piacere a un ente pubblico o a un grosso
committente.
Per cui possedere MySQL potrebbe anche voler dire rafforzare le
sinergie tra StarOffice e MySQL .
E questo potrebbe andare a scapito di altre soluzioni sempre OpenSource.
Va tenuto conto anche che se le cose non girassero commercialmente nel
modo giusto ci metterebbe poco Sun a fare in modo che solo StarOffice
riesca a interfacciarsi per benino con MySQL.
Magari rilasciando un driver non OpenSource.
E infine vi e' il mercato della formazione, della consulenza ,
manutenzione e certificazioni.
Ora e' SUN che rilascia le certificazioni per MySQL, e questo si
capisce facilmente cosa vuol dire....
Sai quanto chiede microsoft o Oracle per certificare che si e' un
esperto di Windows o di Oracle ?
Tanti soldi, e va rinnovata in continuazione.
Andrea.
> Pero' non vedo che conseguenze avrebbe nel mondo GIS.
> Visto che MySQL non ha niente di rilevante dal punto di vista delle
> funzionalita' GIS.
>
Immagino che se la comuità farà operazione di lobbying da questo fronte
si potranno avere moltissime sorprese.--
Edoardo Marascalchi
ICT Consultantwebsite: http://www.edoardomarascalchi.it
skype: My status <skype:asca_edom?call>
--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~
On Thu, 17 Jan 2008 19:20:49 +0100, Diego Guidi wrote
> Il che significa che al momento tutte queste funzioni.anziche' agire
> sull'area esatta della geometria (se poligonale) agiscono sul
> rettangolo di ingombro.
Te lo confermo perchè tempo fa andai a guardare il codice e rimasi a
bocca aperta...
come dire "era meglio che non ci mettevamo niente, almeno non stavamo
a vendere aria fritta..."
Bicchiere mezzo pieno oppure bicchiere mezzo vuoto ?
Spesso è questione di gusti ... e di requisiti funzionali ...
MySQL non pretende affatto di supportare a fondo la
spatial analysis, e lo riconosce molto chiaramente
ed onestamente in tutta quanta la documentazione
Ma se lo scopo è semplicemente quello di supportare un
web server [e scusate del poco ...], allora basta ed
avanza un'indicizzazione spaziale che operi sui rettangoli
Mi spiego meglio; se devo generare una mappa che
rappresenta una manciata di isolati nel centro di
Firenze, mi basta abbondantemente un indice
che recuperi "di corsa" quella decina di assi
strada, edifici, fermate bus etc etc che mi interessano,
scartando le altre centomila entità che ora non mi servono;
se anche la query [usando il "rozzo" criterio dei rettangoli]
ritorna qualche decina di entità che non appartengono alla
mappa in elaborazione, non è poi una tragedia, no ?
Ci penserà il sw di rasterizzazione a scartarle; ma intanto
l'indice spatial di MySQL mi serve efficacemente per eseguire
una query molto veloce
ciao Sandro Furieri
On Thu, Jan 17, 2008 at 07:25:53PM +0100, a.furieri@lqt.it wrote:
On Thu, 17 Jan 2008 18:31:25 +0100, Andrea Aime wrote
Una domanda: ma in JDBC hai impostato:
Connection.setAutoCommit(false); ???
se non l'hai fatto è chiaro che le scritture impiegano
secoli; se è AutoCommit = true [by default !!!]
stai disabilitando tutte le ottimizzazioni sui buffers,
e devi aspettare che ciascuna singola riga sia fisicamente
scritta sul disco, una per volta ...
Lo stesso vale per postgresql.. e' in autocommit di default.
begin; ...; end; forza la transazione lunga
--strk;
a.furieri@lqt.it ha scritto:
On Thu, 17 Jan 2008 18:31:25 +0100, Andrea Aime wrote
Li ho testati sotto windows, entrambi configurazioni di default,
....
Btw, hai qualche suggerimento per far andare MySql più veloce?
Può essere che la config di default di mysql è inferiore a quella
di postgres sotto windows...
Ciao
AndreaCredo che il problema è esattamente quello; sia con MySQL che
con PostgreSQL utilizzare le configurazioni di default [specie
su Windows] è come pretendere di cronometrare quanto corre
un levriero, ma tenendogli le zampe legate strette strette ...Una domanda: ma in JDBC hai impostato:
Connection.setAutoCommit(false); ???
se non l'hai fatto è chiaro che le scritture impiegano
secoli; se è AutoCommit = true [by default !!!]
stai disabilitando tutte le ottimizzazioni sui buffers,
e devi aspettare che ciascuna singola riga sia fisicamente scritta sul disco, una per volta ...
Dunque, non ho tempo di verificare ora (lo farò nel weekend)
ma direi proprio di si, a quanto ne so mysql stava lavorando
in autocommit = false. In ogni caso, il test che ho fatto
è di WMS, pura lettura.
=========================================================
Comunque, per quanto riguarda le configurazioni:
su win il config di MySQL dovrebbe essere (se hai usato l'install standard):
C:\Programmi\MySQL\MySQL Server 5.0\my.inimentre su Linux lo trovi su: /etc/my.cnf
su un PC WinXP [512MB ram] io ho assegnato:
query_cache_size=32M
myisam_max_sort_file_size=128M
myisam_max_extra_sort_file_size=64M
myisam_sort_buffer_size=64M
key_buffer_size=96M
read_buffer_size=64K
read_rnd_buffer_size=256K
sort_buffer_size=64Minvece un server Fedora7 [2GB ram] io ho assegnato:
query_cache_size=32M
myisam_max_sort_file_size=128M
myisam_max_extra_sort_file_size=64M
myisam_sort_buffer_size=64M
key_buffer_size=256M
read_buffer_size=2MB
read_rnd_buffer_size=8M
sort_buffer_size=256MChiaramente più ram metti e meglio gira; ma se poi
non ne rimane abbastanza per gli altri processi vai
in swap, e allora tutto peggiora catastroficamente !
E' tutto spiegato abbastanza chiaramente nella documentazione;
inoltre trovi vari config preconfezionati nella distro, che
si chiamano my-small, my-medium, my-large, my-huge etc
Puoi anche usare il GUI tool MySQLAdministrator per impostare
i parametri di config [StartupVariables]
In tutti i casi devi riavviare il servizio per rendere effettive
le modificheCONSIGLIO DA AMICO: salvati prima da qualche parte il my.cnf
originale, perchè se padelli qualcosa rischi che MySQL
non riesce proprio a ripartire !!!!
Comunque se consulti il log ti dice dove è l'intoppo ...
Ok, grazie per le ricche informazioni. Proverò a configurare MySql
in questo modo e vediamo come va.
Posso già dirti che nei test fatti superata una fase iniziale non vi era più accesso al disco (accesso fisico intendo), quindi non so quanto
dare più memoria a MySql possa aiutare. In ogni caso, ri-testo e vi farò sapere.
Ciao
Andrea
1 miliardo di dollari: 800 milioni di dollari in contanti e i restanti
200 milioni in opzioni. Circa 100 milioni di copie, 10 dollari a copia
quindi...
Poi dicono che l'open source è roba da cantinari...
On 1/16/08, Paolo Cavallini <cavallini@faunalia.it> wrote:
http://blogs.sun.com/jonathan/entry/winds_of_change_are_blowing
strana notizia, dato che Sun e' (era?) il principale supporter di
PostgreSQL.
Questo potra' avere conseguenze nel settore GIS, ovviamente.
pc
--
Paolo Cavallini, see: http://www.faunalia.it/pc
Fare le analisi spaziali con l' MBR non e' prerogativa di MySQL.
Tutti i DB che possiedono un modulo spaziale operano
sempre in due passi, prima isolano l'intorno con l' MBR e poi
raffinano con altri algoritmi piu' precisi.
E di conseguenza forniscono due gruppi di funzioni, un gruppo lavoro a
livello MBR , ovvero svolge solo il primo passo. Il secondo gruppo di
funzioni opera a livello di massima precisione e quindi opera con 2
passi.
Per cui la mia perplessita' non era tanto rivolta al fatto che vi
fossero delle funzioni che operassero a livello di MBR, ma piuttosto
rivolta al fatto che non vi fossero funzioni per il secondo gruppo.
Cosa che a una lettura superficiale della documentazione di MySQL non traspare,
perche' MySQL e' impostato esattamente come gli altri DB, ovvero due
gruppi di funzioni.
Infatti ha le funzioni del primo gruppo, quelle che operano sull'MBR,
http://dev.mysql.com/doc/refman/6.0/en/relations-on-geometry-mbr.html
come ad esempio:
-) MBRContains(g1,g2)
-) MBRIntersects(g1,g2)
etc...
e poi ha le funzioni del secondo gruppo, che dovrebbero raffinare il risultato:
http://dev.mysql.com/doc/refman/6.0/en/functions-that-test-spatial-relationships-between-geometries.html
come ad esempio:
-) Contains(g1,g2)
-) Intersects(g1,g2)
etc..
solo che quest'ultime restituiscono il medesimo risultato di quelle
del primo gruppo.
Intendiamoci, pero'.
Non sto' dicendo che sono disonesti. Tutt'altro.
Perche' nella pagina la cosa e' ben chiarita, e scritta nelle prime righe.
Per cui chi si spende a leggere la documentazione lo scopre subito,
chi si affida al solito manualetto rapido, non lo sa' e sono fatti
sua.
Si capisce anche il perche' di questo sdoppiamento. Perche' cosi' chi
vuole un risultato esatto, scrive il codice usando le funzioni del
secondo gruppo. Se poi il risultato non va bene, pazienza, aggiunge
lui le routines per raffinarlo (come appunto dici te).
Poi un domani che MySQL migliorera' le cose (chissa quando), bastera'
buttar via il codice di raffinamento scritto a mano e affidarsi
direttamente a tali funzioni.
Niente da eccepire, tutto giusto e corretto.
E' senzaltro un approccio rivolto agli sviluppatori, se non vi fossero
state le funzioni del secondo gruppo, un domani che fossero state
aggiunte, si sarebbe dovuto rimettere mano pesantemente al codice e
questo e' sempre da evitare se possibile.
Il punto e' ad oggi MySQL offre un set inferiore (dal punto di vista
dell'analisi spaziale) rispetto ad altre soluzioni.
E francamente mi secca un po' quando nei discorsi sento interloquire
persone che sostengono quanto sia ricco , completo e velocissimo il
modulo spaziale di MySQL.
E' chiaro che si tratta di affermazioni che non tengono conto di
quello che sono i risultati che effettivamente vengono fuori, e che
risentono di una analisi forse troppo frettolosa e basata solo sul
conteggio di quante funzioni sono enucleate nella documentazione.
E' altresi' evidente che nel tuo caso, le necessita' di analisi
spaziale erano ridotte e quindi quello che faceva MySQL era
sufficiente.
Tante' che se pure avessi avuto postgres a disposizione probabilmente
non avresti usato le sue funzioni del secondo gruppo, ma ti saresti
comunque limitato a usare quelle di analisi a livello di MBR, per
avere la max. velocita.
Quindi e' un esempio di situazione in cui va bene anche usare MySQL.
Pero' spesso si sentono discorsi dove si generalizza.
Quanto e' veloce mysql nell'analisi spaziale....
quante funzioni ha mysql nell'analisi spaziale....
e cosi' via.
Tutte cose che poi nella realta' non sono verificate.
Andrea.
2008/1/17, a.furieri@lqt.it <a.furieri@lqt.it>:
On Thu, 17 Jan 2008 19:20:49 +0100, Diego Guidi wrote
> > Il che significa che al momento tutte queste funzioni.anziche' agire
> > sull'area esatta della geometria (se poligonale) agiscono sul
> > rettangolo di ingombro.
> Te lo confermo perchè tempo fa andai a guardare il codice e rimasi a
> bocca aperta...
> come dire "era meglio che non ci mettevamo niente, almeno non stavamo
> a vendere aria fritta..."Bicchiere mezzo pieno oppure bicchiere mezzo vuoto ?
Spesso è questione di gusti ... e di requisiti funzionali ...MySQL non pretende affatto di supportare a fondo la
spatial analysis, e lo riconosce molto chiaramente
ed onestamente in tutta quanta la documentazioneMa se lo scopo è semplicemente quello di supportare un
web server [e scusate del poco ...], allora basta ed
avanza un'indicizzazione spaziale che operi sui rettangoliMi spiego meglio; se devo generare una mappa che
rappresenta una manciata di isolati nel centro di
Firenze, mi basta abbondantemente un indice
che recuperi "di corsa" quella decina di assi
strada, edifici, fermate bus etc etc che mi interessano,
scartando le altre centomila entità che ora non mi servono;
se anche la query [usando il "rozzo" criterio dei rettangoli]
ritorna qualche decina di entità che non appartengono alla
mappa in elaborazione, non è poi una tragedia, no ?
Ci penserà il sw di rasterizzazione a scartarle; ma intanto
l'indice spatial di MySQL mi serve efficacemente per eseguire
una query molto veloceciao Sandro Furieri
--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~