Peut-être qu'il serait intéressant de regarder du côté de MariaDB. La
migration de MySQL vers MariaDB est facile car elle a été pensé pour
être prête à être exécutée. Chez MariaDB tout est quasi identique à
MySQL (c'est la même core team) tous les fichiers de données sont
parfaitement compatibles, MariaDB peut fonctionner avec l'instance MySQL
existante. Donc vos applications ne changent pas d'un seul Bit, et les
performances sont immédiates.
En plus des améliorations et de la supériorité des fonctionnalités,
MariaDB bénéficie des apports de la communauté (Facebook, Twitter,
Google et Percona),
Par exemple sur l'exécution des requêtes qui est un énorme défi pour les
applications à 100% sur le Web, MariaDB offre de sérieuses
améliorations, notamment pour l'optimisation des sous-requêtes et des
vues, à la fois plus rapides et homogènes. J'ai des exemples
d'utilisateurs qui géraient de très importants volumes en Po, qui sont
aujourd'hui bluffés par MariaDB.
Véro
Le 09/10/2013 10:21, Nathan delhaye a écrit :
Anciennement un mix innodb/myisam qui est maintenant full innodb. On
utilise les build percona.
Coté matos c'est du r610 bi-x5650, 96G de ram et des disques sas. La
RAM c'est surtout important pour les index et les buffers MySQL afin
de s'assurer que les disques ne soient pas trop sollicités.
Mais comme dit Benjamin, la config de l'os est tout aussi important
que la config de MySQL. Quand on atteint ces chiffres, il faut
premièrement commencer a sharder si c'est possible (ça c'est côté
applicatif et ce n'est pas applicable au problème présent) et surtout
tunner tout ce que l'on peut des couches les plus basses aux plus
hautes, c'est a dire MySQL.
Le principal soucis c'est vraiment la réplication. Par exemple avec
300 mo de binlog par 5 minutes, la volumétrie devient vite un problème
si on veut pouvoir conserver suffisamment d'historique pour intervenir.
Le 9 oct. 2013 08:30, "Greg" <greg-fr...@duchatelet.net
<mailto:greg-fr...@duchatelet.net>> a écrit :
Bonjour,
intéressant, avec quel moteur ? ARCHIVE ? et quel matériel ?
Le 8 octobre 2013 20:11, Nathan delhaye <cont...@nathan-delhaye.fr
<mailto:cont...@nathan-delhaye.fr>> a écrit :
Certes... Pour avoir une instance de 6To (une des bases fait
4To) c'est un peu galère a administrer. Par contre t'est
toujours obligé de sortir des tricks de l'espace pour faire
des opé sans down la base. Mais ça fonctionne et ça fonctionne
bien à 3000 write/s et 10000 read/s
Au niveau réplication par contre (c'est bien la redondance),
si t'a BEAUCOUP de modifications par secondes, tu peux taper
les limites de MySQL (ou plutôt de tes disques et de ton cpu)
et c'est là que le bas blesse. Cette la 5.6 fait
automagiquement de la réplication multi-coeur, mais je pense
après quelques tests que la version/fonctionnalité est encore
un peu jeune.
Sinon certes c'est long a mettre en place pour faire un truc
un peu chiadé, mais kibana ça fait le café. Je ne vois pas
pourquoi est-ce que les marketteux ne pourraient pas lire les
graphes?
My 20 cents
Le 8 oct. 2013 19:54, "Emmanuel Thierry" <m...@sekil.fr
<mailto:m...@sekil.fr>> a écrit :
Bonjour,
Le 8 oct. 2013 à 18:12, Greg a écrit :
>
> - piwik : permet de lire les logs, mais interface en
PHP/MySQL, et avec la quantité de donnée un moteur NoSQL
serait plus approprié
A la limite teste le...
Contrairement à ce que l'on peut penser, MySQL sait gérer
de grosses bases.
Cordialement
Emmanuel Thierry
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
