MySql - realizzazione di una query abbastanza ostica

[k.b]

Originariamente inviato da franzauker
No, anzi no di certo per un forum che non sia un miniforum.
1) Son troppo lenti (motivo assorbente)
e
2) Non puoi fare i backup hot (senza --opt, altro motivo assorbente)

Per dare un'idea alla "stragrossa" fare una ricerca full text su diciamo un milione di post, per un forum piuttosto trafficato, ma non poi eccessivamente, per un db "tutto" myisam richiede anche 20 o 30 secondi A QUERY.

Beh vbulletin usa MyISAM per la tabella post, e di certo e' usato anche per forum di discreto traffico.

Originariamente inviato da franzauker
A parte il mitico problema 139 (che in realtà salta fuori spesso proprio quando converti), qual'è l'eventuale casino nella conversione?
Ma, soprattutto, ti giro la domanda.
Sei proprio sicuro che serva?
Non sarei così assertivo, visto che c'è tutta una "catena" da gestire.
Campo, tabella, server mysql, client mysql, applicazione (e pure backup e restore)

Il casino della conversione deriva proprio da questa catena. Studiare il tutto da principio o adattarlo dopo non e' proprio la stessa cosa.
La catena in se' non lo vedo come un problema, perche' in fase di progettazione dell'applicazione do per scontato che tutti i componenti siano sviluppati in modo che concordino sull'encoding da usare.

Originariamente inviato da franzauker
sicuramente dipende dai casi.
Personalmente non lo consiglio, se non dopo aver valutato appieno pregi e difetti.
Ma questo vale un po' per tutte le situazioni.

Questo senz'altro, pero' la mia impressione - per quello che ho appreso da questa discussione - e' che i casi in cui utf8 possa essere un problema siano piu' rari di quelli in cui sia un vantaggio, almeno parlando di applicazioni generiche come un forum. Chiaro che piu' le esigenze sono particolari piu' e' facile (e ovviamente necessario) ottimizzare ogni parte.

[deleted_29]

Originariamente inviato da k.b
Beh vbulletin usa MyISAM per la tabella post, e di certo e' usato anche per forum di discreto traffico.

Non vorrei fare lo "sborrone" oltre misura, ma ti dò un consiglio proprio banale.
Prova.
POI che sia 10000 volte più facile usare myisam, piuttosto che scornarsi con sphinx, lucene, cugini&affiliati, sono perfettamente d'accordo.
E che nei forum diciamo così "pacchettizzati" sia lo standard pure, concordo.

Che funzioni invece "in produzione" non direi
Ecco un esempino "vero" di un forum "vero" con myisam e fulltext.

Count         : 50  (5.32%)
Time          : 852.062107 s total, 17.041242 s avg, 1.385475 s to 19.647678 s max  (15.51%)
  95% of Time : 793.327464 s total, 16.879308 s avg, 1.385475 s to 19.527625 s max
Lock Time (s) : 148.411 ms total, 2.968 ms avg, 30 µs to 146.261 ms max  (0.01%)
  95% of Lock : 1.98 ms total, 42 µs avg, 30 µs to 56 µs max
Rows sent     : 2.57k avg, 3 to 29.89k max  (24.31%)
Rows examined : 370.59k avg, 33.69k to 405.19k max  (14.95%)
Database      : 
Users         : 
	XXX: 100.00% (50) of query, 97.12% (912) of all users

Query sample:
SELECT p.pid FROM posts p WHERE   forum_id IN (XXX) AND queued <> 1  AND MATCH(post) AGAINST ('XXX YYY' IN BOOLEAN MODE);

Il casino della conversione deriva proprio da questa catena. Studiare il tutto da principio o adattarlo dopo non e' proprio la stessa cosa.
La catena in se' non lo vedo come un problema, perche' in fase di progettazione dell'applicazione do per scontato che tutti i componenti siano sviluppati in modo che concordino sull'encoding da usare.

Bhè dai per scontate parecchie cose, soprattutto gli strumenti di mysql non necessariamente, per default, lavorano con utf8
Anzi...

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.1.40-community MySQL Community Server (GPL)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> status;
--------------
mysql Ver 14.14 Distrib 5.1.40, for Win64 (unknown)

Connection id: 2
SSL: Not in use
Using delimiter: ;
Server version: 5.1.40-community MySQL Community Server (GPL)
Protocol version: 10
Connection: localhost via TCP/IP
Client characterset: latin1
Server characterset: utf8
TCP port: 3306
Uptime: 5 min 20 sec

Threads: 1 Questions: 9 Slow queries: 0 Opens: 15 Flush tables: 1 Open tables: 8 Queries per second avg: 0.28
--------------

Questo senz'altro, pero' la mia impressione - per quello che ho appreso da questa discussione - e' che i casi in cui utf8 possa essere un problema siano piu' rari di quelli in cui sia un vantaggio...

Sono parzialmente d'accordo.
"parzialmente" nel senso già spiegato.
Mini-forum (=mini-db)? Va bene qualsiasi cosa. utf8, myisam, full text myisam etc.

[k.b]

Ti ringrazio molto per le informazioni, era una questione che non avevo mai incontrato

[MacApp]

@franzauker
Le problematiche da te riscontrate con mysql e utf8, implicano, che per le lingue che ne necessitano, si debba escludere a priori l'utilizzo di mysql per db di grandi dimensioni, o basta semplicemente moltiplicare per tre l'hardware a disposizione?
grazie.

[deleted_29]

Originariamente inviato da MacApp
@franzauker
Le problematiche da te riscontrate con mysql e utf8, implicano, che per le lingue che ne necessitano, si debba escludere a priori l'utilizzo di mysql per db di grandi dimensioni, o basta semplicemente moltiplicare per tre l'hardware a disposizione?
grazie.

utf8 è cosa buona e giusta, se ti serve.

Se non ti serve è il male, altrimenti è bene.
---
ho avuto problemi solo con db "grandi" (grandi per me significano un 20G righe), probabilmente la maggior parte degli utenti neppure si accorge dell'esistenza di differenze sensibili.

Il "crollo" di mysql avviene quando non riesce a tenere in memoria le pagine degli indici, nel caso di innodb praticamente blocca qualsiasi cosa (gli indici secondari sono a loro volta "indiciati" dall'indice della chiave primaria); myisam "soffre" leggermente meno (nella mia esperienza) da questo punto di vista.

Non è per nulla semplice configurare "bene" un server mysql, anzi in generale direi che è proprio difficile (sempre con riferimento a db grandi, db piccoli funzionano praticamente anche con un commodore 64), anche perchè ci sono differenze abissali tra le varie versioni e sottoversioni, e le enormi differenze tra i carichi.
Si parte dal pentium IV fino a qualcosa tipo questo
http://www.oracle.com/technetwork/da...eSiteId=ocomen