Choix d'un SGBD pour application métier (Web)

[Neilime05]

Bonjour,

Depuis maintenant 10 ans, notre application métier tourne sous MYSQL MyISAM (Serveur apache & PHP pour infos).
Nous rencontrons de plus en plus de problématique en terme de scalabilité et de performances (lecture extrêmement longue sur de grosses tables)
Il est grand temps d'évoluer vers un SGBD digne de ce nom.

La charge principale est la lecture même si les données écrites restent importantes.

De plus nous utilisons le mirroring pour répliquer la base de données sur différents serveurs.

Je suis donc chargé de trouver un sgbd capable de répondre aux attentes évoquées ci-dessus pour évoluer sereinement.

Je me suis intéressé à la vague NoSQL et notamment Cassandra qui me semble particulièrement approprié pour ce cas mais je suis quand même intéressé par des conseils ou des retours d’expérience qui pourrais m'aider à choisir efficacement un SGBD.

Merci d'avance pour vos réponses et vos orientations.

[SQLpro]

Quel est le volume actuel de votre base ?
Quel est le nombre de bases ?
Quel est le nombre de connexions simultanées ?
Quel est le nombre de transactions par minute ?
Quelle est la configuration actuelle de votre serveur physique ?

A +

[Neilime05]

Quel est le volume actuel de votre base ?

environ 5Go+

Quel est le nombre de bases ?

130 tables

Code :

Quel est le nombre de connexion simultanées ?

Selon les statistiques sur le trafic de phpmyadmin (max. de connexions simultanées) : 47

Code :

Quel est le nombre de transaction par minute ?

Selon les statistiques sur les requêtes de phpmyadmin : 4,64 k

Code :

Quelle est la configuration actuelle de votre serveur physique ?

Debian 64bits
16coeurs
24Go Ram
Disque dur 64Go

Besoin d'autres informations en particulier ?

[Waldar]

Laissez tomber le NoSQL : trouvez surtout des développeurs qui connaissent bien le SQL.

C'est impensable d'avoir des problèmes de performance entre la configuration que vous annoncez (excellente) et la taille de votre base de données (petite) !

[Neilime05]

C'est impensable d'avoir des problèmes de performance entre la configuration que vous annoncez (excellente) et la taille de votre base de données (petite) !

Je tiens à préciser qu'il y a une quinzaine de bases de données de cette taille par serveurs.

Laissez tomber le NoSQL : trouvez surtout des développeurs qui connaissent bien le SQL.

Je suis conscient de l'impact du modèle de données (mal pensé au début, puis consentement "engraissé" sans aucune refonte pour améliorer la performance).

En ce qui concerne l'adoption du NoSQL, cela n'est pas du tout acté, mais plutôt une réflexion de son utilité.
La refonte du modèle de donnée doit s'accompagner d'un changement de SGBD afin de garantir de meilleures performances, ma demande est réellement large et pas seulement axée sur le NoSQL

[punkoff]

Avant de tout défoncer et partir sur une migration de vos application...

Avez-vous fait auditer votre système actuel pour savoir d'où venaient vos problèmes ?

[SQLpro]

La première des optimisations est la restructuration des bases en respectant A LA LETTRE les règles de l'art de la modélisation que sont les formes normales.
Bref, commencez par normaliser votre base.

A +

[Jester]

1- InnoDB (disponible sous MySQL si ce n'est pas trop vieux) sera potentiellement plus performant car permettant de conserver des données en mémoires. La version 5.5 de MySQL a beaucoup avancé sur la gestion d'un grand nombre de requêtes parallèles pour ce moteur qui est par défaut à présent.

2- Y a-t'il des index? Si, quand il n'y pas d'autres requêtes en même temps, sélectionner une ligne via une requête classique prend plus de 100 millisecondes, il y a un problème à ce niveau.

3- Quel est la complexité des requêtes? Notamment en nombre de sélections et de jointures? MySQL n'est pas prévu pour prendre un grand nombre de lignes d'une table et les lier avec des lignes d'une autre.

4- Le NoSQL ne vous sera pas très utile. NoSQL serait plus rapide que MySQL si le nombre de requêtes était très grand et la complexité d'exécution très faible (cas où comprendre le SQL prend du temps relativement à exécuter la requête). L'autre avantage du NoSQL est ses schéma libres, mais dans votre cas ça me semble peu utile.

5- Quel est le problème? Disque (en exécutant la commande top vous avez le '%wa' très élevé, wa = waiting for I/O)? CPU?

Exécutez les requêtes et regardez celles qui prennent trop de temps, pourquoi ?

[Neilime05]

Le modèle de données étant complexe, il y a en effet un certain nombre de requêtes portant sur de nombreuse jointure, il y a cependant des index, je vais donc m'orienter vers l'optimisation du modèle de données / requêtes.

Auriez vous des outils à me conseiller permettant de m'aider dans cette tache de benchmark / optimisation / normalisation ?

Il en existe plutôt pas mal sur le marché, je ne sais pas vers le(s)quel(s) me tourner.

Merci

[CinePhil]

Quelques logiciels de modélisation :
- La star "PowerAMC".
Cher mais paraît-il très performant, uniquement sous Windows.

- Open Modelsphere.
Gratuit et assez complet mais parfois capricieux et nécessitant quelques manipulations pas ergonomiques dans certains cas (héritages notamment).

- JMerise.
Tout nouveau et gratuit.

- MySQL Workbench.
Dédié à MySQL donc en principe parfaite cohérence avec les types et les spécificités de MySQL. Par contre, on modélise directement les tables ; pas de MCD Merisien ou de diagramme de classes UML avec ce logiciel. Quand on n'est pas habitué à la modélisation, je conseillerai de toujours commencer par un MCD, fut-il simplifié (sans les propriétés) et fait à la main.

Et pour vous aider à bien modéliser :
- le cours de SQLPro sur la modélisation Merise ;
- la bible de fsmrel sur la normalisation des BDD ;
- le forum Schéma.

[Jester]

Je remonte que passer vos tables en InnoDB pourrait résoudre déjà une partie du problème sans grand effort.

En effet, vous avez beaucoup d'écriture. Or sous MyISAM l'écriture bloque la table donc on ne peut y lire et il faut attendre.

Faite déjà le test sur un clone pour voir.

Ensuite listez la liste des requêtes les plus fréquentes et vérifiéz qu'elles n'utilisent pas de lecture séquentielles dans les tables (via EXPLAIN, http://dev.mysql.com/doc/refman/5.0/...g-explain.html mais la suite mysql propose peut-être un outil graphique) mais passent toujours par des index.

Sur la prod, en ligne de commande lancez top et regardez le %id (idle), %wa (waiting I/O), ça vous dira pas mal de chose, notemment si vous êtes CPU bound ou IO bound.

Si c'est IO bound (et c'est fort probable), InnoDB et un bon buffer de 10Go solutionnera probalement le problème.
Si c'est %id est important, c'est que vous avez trop de lock du aux écritures. Là encore InnoDB peut gérer le problème.

Après vous pouvez refaire le modèle de données et recoder une bonne partie de l'application si vous avez beaucoup de temps à perdre. Mais dans tout les cas ne restez pas en MyISAM, c'est n'est pas un mode de stockage sûr pour vos données.