Discussion :

[pmithrandir]

Pour faire original, quel stockage de donnée choisir ?

Notre projet :
actuellement nous stockons des données en provenance de facebook(les reponses a des posts par exemple) et nous avons un système de stat la dessus.
Nous sommes actuellement sur un SGBD mysql, et notre base est un mélange de myisam, innodb et autant vous dire, la 3 eme forme normale est un lointain souvenir...
Les index sont parfois dupliqués et les type de champs pas toujours adaptés.
Les requetes sont rarement optimisée et les tables sont assez mal foutue par rapport a notre besoin actuel.
Bref, y a de la marge en performance.

Actuellement, on a quand même des tables de 10 M de lignes qui tournent comme ca, ca marche, mais on commencee a sentir la limite qui approche.
L'ajout d'un index sur une table de cette taillee prend parfois une bonne heure par exemple, ce qui me parait super long. Notre temps de migration optimal etant en dessous de 15 minutes, les 5 heures de la derinère fois ont posé un problème.
On prévoit une montée en charge vers 100M de lignes, peut être plus dans les années a venir.

On a aussi un projet de mise en place de service pour acceder a nos données, afin de connecter plusieurs applications dessus.

Notre système est beaucoup plus accés entrée de donnée que selection. On cherche donc a avoir un système super rapide en insertion, et accessible assez vite en lecture(on ne veut pas que nos stats mettent des heures a venir)

Les solutions proposées :
Certains dans l'équipe semblent persuader que SQL nee suivra pas la cadence et que nous devons absoluement migrer vers un systeme NoSQL type hbase.

A contrario, je pense que nous avons de la matière pour nous améliorer et que nous pourrons donc avancer vers des solutions SQL qui peuvent tenir la charge (sur cluster de server???)

Qu'en pensz vous ?
Quelles sont les limitees de SQL dans ses differents domaines ?

[Oishiiii]

Qu'en pensz vous ?
Quelles sont les limitees de SQL dans ses differents domaines ?

Telle qu'est décrite la situation, avant de penser aux "limites" de "SQL", je me pencherai sur la limite des compétences du personnel travaillant sur ce projet en matière de bases de données.



Vous n'avez donc pas de DBA ?

Au lieux de parler en nombre de lignes (10M, 100M, etc...) essayez d'évaluer la volumétrie en Mo, Go...
10 Millions de lignes dans une table avec deux colonnes de type entier ce n'est rien du tout.

[CinePhil]

Si SQLPro passe par là, il dira sûrement que MySQL n'est pas idéal pour ça, notamment parce qu'il y a beaucoup d'insertions.
Le volume de données commençant à devenir important, peut-être faudrait-il songer à un SGBD plus pro genre MS SQL Server, Oracle ou DB2.

Je ne sais pas comment se comporterait Postgresql avec ce genre de traffic.

Ce qui est sûr, c'est qu'il faudrait reconcevoir votre BDD et la normaliser à fond, l'indexer correctement... et vous verrez probablement les performances s'améliorer grandement.

Bon courage !

[pmithrandir]

On a pas vraiment de DBA, startup, pas vraiment de besoin et méthode agile... ca nous donne notre résultat actuel.

Pour nos données :
pour l'instant, en MO nous avons :
1Giga de données pour 2.7Giga d'index
Et sur la seconde base de données :
1.3Giga pour 0,6Giga d'index


En fait, à partir de combien de lignes par table (de données) ou de combien de gigas on pourrait arriver aux limites de mysql ?
Là on est en train de prévoir notre solution à court, moyen ou long terme, donc c'est plus de la réflexion d'ensemble.

[Oishiiii]

Ce volume de donnée semble assez faible, ça devrait tenir largement dans la RAM de votre serveur... j'imagine. Donc pas de problème pour MySQL.

Si éventuellement vous deviez avoir des problèmes de performances lors de requêtes ou traitement batch, cela viendrait de la qualité de la conception de la BDD, de l'écriture des requêtes, puis de l'optimisation (index, etc..).

[pmithrandir]

Ah oui, les deux bases de données ci dessus sont chacune sur un serveur...

L'idée est de se dire que par exemple, on a une table qui prend 500 000 enregistrements par mois, avec tendance à s'accélérer. (on vient de lancer le produit)

Donc le volume de données devrait augmenter par 5 ou 10 d'ici 6 mois un an...

Ces solutions resteront elles adaptées pour des BDD de 30 gigas ?

[Jester]

Vous n'avez pas besoin d'un DBA mais vous avez des problématique requérant un DBA.

La réponse est dans votre premier post. En faisant n'importe quoi (mixer du MyIsam et de l'innodb sans raison en est une) vous avez des performances suffisantes pour 10% de la charge. Aucun doutes qu'en faisant les choses correctement tout ira bien à 100%. Le seul avantage de NoSQL dans votre cas sera d'éviter le prix de l'interprétation du langage SQL, or vous ne semblez pas avoir des milliers de requetes par seconde donc pas de problème.

MySQL est très rapide en insertion.

[aieeeuuuuu]

Pour nos données :
pour l'instant, en MO nous avons :
1Giga de données pour 2.7Giga d'index
Et sur la seconde base de données :
1.3Giga pour 0,6Giga d'index

Tu semble avoir déjà pas mal d'index de définis. Ce qui dans ton cas précis n'est pas forcément une bonne solution si tu dis avoir beaucoup d'insertions et peu de lectures de tes données.

tu peux déjà te poser la question de savoir si tout tes index sont vraiment utiles et supprimer ceux qui sont superflus

Si (malgré la pertinente remarque de skuatamdad) tu fais des injections en masse, il sera peut être avantageux de désactiver tes index avant les insertions...

mais dans tous les cas (et pour répondra a la question initiale), une solution "SQL" me parait tout a fait adaptée. Quant à MySQL en particulier je dirai que ca dépendra de la complexité de la base, mais d'autres solutions existent...

SQL Server par exemple dispose d'une version express gratuite qui pourra surement répondre à tes besoins

[pmithrandir]

Merci pour toutes ces réponses...

Vous confirmez pour la plupat ce que j'essaye de faire passer comme message depuis longtemp : Le problème n'est pas l'outil, mais la facon dont on s'en sert.

J'ai identifié au moins 10 index dupliqués dans la BDD, plusieurs que l'on pourrrait surement optimisés, etc... Bref, y a du boulot simple qui ne ferait pas de mal. Comme le fait aussi de passer toutes les tables sur le même moteur(innodb a priori) pour optimiser notre mémoire au niveau serveur.

Enfin, maintenant, il ne me reste plus qu'a faire bouger les mentalités et a leur faire comprendre que leur beau projet tout clinquant est tout bonnement inutile... comme ca fait 3 semaines qu'ils s'exitent dessus j'ai du boulot...

[skuatamad]

Ceci dit le type d'application sur lequel tu travailles peut faire partie des 1% d'applications qui correspondent assez bien à NoSql.
Comme tes données proviennet de facebook, à priori tu n'as pas vraiment besoin de contrainte d'intégriter, de typage fort des données et de ce qui fait la valeur ajoutée d'un SGBDR.
Donc pourquoi pas NoSQL, mais il faut s'assurer que les requêtes statistiques effectuées à partir des applis peuvent s'écrire aussi facilement et s'exécuter aussi rapidement (je ne connais pas du tout NoSQL) et concernant des SELECT avec de gros regroupement je ne suis pas sûr de la valeur ajoutée de NoSql.

Si vous restez sur MySQL et s'il n'y a quasiment pas d'update concurrent via les applications je préconniserais plutôt MyISAM qui, à mon avis, boostera les INSERTS, INNODB permettant de gérer des transactions ce qui ne semble pas vraiment être ton besoin.

Dernier point, dans un but purement statistique, la normalisation d'un SGBD n'est plus la 3eme forme normale mais la conception en étoile ou flocon, avec des tables de faits et des tables dimensions.

[SQLpro]

1Giga de données pour 2.7Giga d'index
Et sur la seconde base de données :
1.3Giga pour 0,6Giga d'index

Base 1 situation anormale, base 2 situation normale.
Normalement pour une base de données ordinaire transactionnelle; le ratio est de 25 à 33% d'index pour 67 à 75% de données.
Mais si cette base n'a qu'un seule processus d'insertion (connexion unique) et de nombreuses requêtes de lecture (statistiques) alors le ratio peut s'inverser (base OLAP par exemple).
Enfin,pour accélérer certaines traitements statistiques, on peut alors recourir à des vues indexées (SQL Server) ou matérialisée (Oracle) qui diminuent drastiquement les temps de réponse (par 1000 ou beaucoup plus).
Lisez l'étude que je donne ici : http://sqlpro.developpez.com/optimisation/indexation/

Enfin, sur la pose des index, lisez l'article que j'ai écrit : http://sqlpro.developpez.com/cours/quoi-indexer/

J'ai aidé pas mal de statup du temps de la bulle internet.
Lisez les articles que j'ai écrit sur l'optimisation. Ils ont été écrit pour MS SQL Server, mais le principe est à peu près le même pour tous les SGBDR (http://sqlpro.developpez.com/optimis.../optimisation/) à l'exception de MySQL qui est le plus pervers et mauvais des SGBDR en terme de perf. http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/
Le point n°1 des performance est la qualité du modèle et notamment le respect de la normalisation pour une base transactionnelle (ce qui semble être le point que vous redoutez).

Sachez que les performances transactionnelles des SGBDR (combinaisons d'insertion, suppressions, modification avec retour arrière en cas de problème) peuvent atteindre 6 millions par minute en mode non cluster et 30 millions par minute en mode cluster. (Source http://www.tpc.org/tpcc/results/tpcc...p;currencyID=0)

A +

[pmithrandir]

Merci !!!

Voila pas mal de lecture pour reprendre du service en douceur après les fetes !!!

Merci pour les conseils divers en tout cas.

[kedare]

Je ne sais pas comment se comporterait Postgresql avec ce genre de traffic.

Il y a pas de raisons qu'il se porte mal.
Je pense pas que MySQL ai trop de problème au niveau du stockage lui même, c'est plus au niveau fonctionnalités qu'il risque d'y avoir un problème après...

[skuatamad]

MySql n'est pas très bon en concurrence d'accès, mais dans ton cas je vois plutôt des batchs insert et des utilisateurs qui font des select via une ou plusieurs applis, donc niveau concurrence d'accès ça reste très soft.

Par contre MySql ne semble également pas très bon niveau maintenance de table comme créer un index sur une table volumineuse (quelques recherches sur google semblent confirmer les temps de création d'index que tu constates)
Donc effectivement MySql n'est peut être pas l'outil le plus adapté...

Mais quel est ton problème exactement, est ce un problème de maintenance (comme création d'index) ou un problème d'insert.
Notemment qu'entends tu par temps de migration dans :

Notre temps de migration optimal etant en dessous de 15 minutes, les 5 heures de la derinère fois ont posé un problème.

Si tu as des prolèmes de perfs lors d'insert massif il est très important, quelque soit la BDD, d'utiliser des opérations ensemblistes comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
insert into t
select * from t2;

Or tes données proviennent de facebook et comme je doute que tu ais des accès aux bases de facebook, j'imagine donc que tu passes par une API, peut être développée en PHP ou PYTHON. Dans ce cas il est possible que tu fasses des insert lignes à lignes comme par exemple un INSERT VALUES au sein d'une boucle. Et ça ce n'est vraiment pas performant.
Evidemment il est possible (je pense aussi sur MySql mais ce n'est pas ma base de prédilection) de BULK loader des données en provenance d'une API, comme passer par un fichier texte par exemple ou autre...

J'ai l'impression que pour le moment tout roule plus ou moins mais que tu te poses des question pour l'avenir.
Afin que nos conseils soient plus pertinant peux tu nous préciser quels sont les éléments les plus "dégradés" de ta solution actuelle, aka la création d'index ou les insert ou les select.

Concernant les craintes de tes collègues sur les limites de SQL, je dirais que SQL est incroyablement performant tant que tu l'utilises en mode ensembliste (aka comme il a été pensé et donc comme il fonctionne le mieux), par contre en utilisation ligne à ligne (dans des boucles), ce langage ne vaut pas grand chose....