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-frsag@duchatelet.net mailto:greg-frsag@duchatelet.net> a écrit :
Bonjour, intéressant, avec quel moteur ? ARCHIVE ? et quel matériel ? Le 8 octobre 2013 20:11, Nathan delhaye <contact@nathan-delhaye.fr <mailto:contact@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" <ml@sekil.fr <mailto:ml@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/