Discussion :

[Zwiter]

Bonjour,
Je fais parti d'un laboratoire de recherche en génétique, et nous faisons du séquençage. Notre but est en gros de repérer des mutations dans l'ADN.
Nous avons des milliards de données qui nécessitent de l'organisation, sous forme d'une base de données afin de pouvoir rechercher des données précises.
Par exemple:

• Combien d'individus partage cette mutation?
• Trouver toutes les mutations communes aux patients atteint de leucémie, qui ne sont pas présentes chez les individus sains ou atteins d'une autre maladie.

les requêtes seraient bien plus complexe, mais suivront ce chema général. Moins de 5 requêtes tourneraient a la fois sur le serveur (windows7, 24go ram, i7, system sur ssd, bdd sur du raid5)
J'estime que ma base de données pourraient atteindre 500Go, pour environ 1 milliards de données. Ceci pourrait doubler d'ici la fin de l'année.
Je cherche a privilégier la rapidité des sélections. Pour cela, je ne prevois pas d'insertion. Les insertions se feront en vidant, et recréant la base de données.

Mes choix actuelles sont:

• une seule table myisam (pas de normalisation = pas de perte de temps sur les jointures. Ma plus grande interrogation sur le gain de temps)
• des champs les plus petits possibles (bon sens... gain de place)
• null non autorisé (gain de place)
• des index sur tous les champs pour accélérer les requêtes (pas d'insertion a faire)

Voici un extrait de my.ini:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
query_cache_size=1G
table_cache=256
tmp_table_size=5G
max_heap_table_size=5G
thread_cache_size=8
myisam_max_sort_file_size=5G
myisam_sort_buffer_size=2G
key_buffer_size=5G
key_cache_age_threshold=172800
sort_buffer_size=200M

On ma déconseillé d'utiliser les clusters de mysql.

Est ce que tout cela vous semble aberrant ?
Y a t il des éléments clés a améliorer?

Merci de m'avoir lu
Zwiter

[SQLpro]

Il me semble utopique de miser sur MySQL, pour faire e que vous voulez faire...
En effet, contrairement à la concurrence, MySQL ne dispose pas :

• d'une gestion fine des espaces de stockage
• d'un partitionnement de données élaboré
• de vues indexées
• d'index couvrants
• d’index filtrés

etc...

Jetez un coup d’œil aux critiques que j'ai formulé à l'encontre de MySQL qui plus est, est farci de bugs... http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

Ainsi qu'aux benchmark de requêtes complexes :
http://blog.developpez.com/sqlpro/p9...lles-en-sql-1/

Enfin, vous pensez utiliser du RAID 5; C'est depuis longtemps une aberration que de préconiser ce genre d'agrégat RAID si vous voulez des performances !
A lire : http://blog.developpez.com/sqlpro/p8...t-le-stocakge/

Enfin, contrairement a ce qu'écrivent beaucoup de crétins sur Internet, la jointure ne pose pas de problème de performance, bien au contraire, à condition que cela soit bien modéliser (respecte des formes normales). Ce qui pose des problèmes de perf, c'est la redondance des données qui fait exploser le volume. Avec 10 tables vous pouvez utiliser 10 index pour vos 10 critères de filtrage et le gain sera exponentiel. Avec une seule table tout ce que vous pourrez faire c'est lire toutes les lignes pour trouver vos données !!!
A lire : http://blog.developpez.com/sqlpro/p1...ances-petites/

A +

[Fred_34]

[*]des index sur tous les champs pour accélérer les requêtes (pas d'insertion a faire)

Tes index prendront certainement plus de place que tes données.
Donc, si tu as 500 GO de données, tu pourrais te retrouver avec un TO d'index.

Les insertions se feront en vidant, et recréant la base de données.

500 GO de données plus les index, ça risque d'être vraiment long. (Plusieurs heures, plusieurs jours ???)

Ainsi qu'aux benchmark de requêtes complexes :
http://blog.developpez.com/sqlpro/p9...lles-en-sql-1/

@SQLpro Je t'ai proposé une procédure qui devrait rendre MYSQL plus rapide que SQL Server. L'as tu testé ?

[EIN-LESER]

Il me semble aussi assez illusoire de vouloir faire quelque chose de cette ampleur avec MySQL qui n'est, a proprement parler même pas une base de donnes relationnel.
Il serait préférable de s'orienter au moins vers du postgres voir de l'oracle ou du sql serveur sur machine dédié.

Bon courage en tout cas.

[SQLpro]

@SQLpro Je t'ai proposé une procédure qui devrait rendre MYSQL plus rapide que SQL Server. L'as tu testé ?

1) nous testions des requêtes et pas de procédures
2) votre procédure n'a jamais fonctionné sur le jeu de données.

A +

[Zwiter]

Hello tous,
Tout d'abord, merci pour vos commentaires.
SQLpro:
Je pressentais que ne pas avoir de normalisation était un handicap. J'ai fait un test avec 55Go de données, et la requête était 3 fois plus lente.
J'ai lu tout tes liens, et je suis vraiment emballé par postgresql. Je suis en train de l'installer, convertir ma base de 55Go et faire des tests. je comprends pas pourquoi MySQL est encore si populaire, mais j'ai bien compris pourquoi les autres SGBD étaient plus performants.

Fred_54:
La taille totale de la BDD m'importe peu. La vitesse d'exécution est vraiment la priorité, sans toutefois toucher au hardware. Toutefois, le lien sur le stockage de SQLpro me fait réfléchir sur la structure des fichiers et la normalisation. Je vais donc normaliser, mais je ne sais pas encore comment organiser les fichiers. Sur 2 stockages différents serait un bon début.

EIN-LESER:
On fait avec les moyens du bord
Encore une fois, je pensais pas MySQL si mauvais

Merci pour vos avis. Je reviendrais parler de l'implémentation de la solution.
Zwiter

[Fred_34]

Je pressentais que ne pas avoir de normalisation était un handicap. J'ai fait un test avec 55Go de données, et la requête était 3 fois plus lente.

Je ne sais pas comment il faut comprendre ta phrase :
Avec normalisation c'est 3 fois plus lent ou 3 fois plus rapide ?

[SQLpro]

...je comprends pas pourquoi MySQL est encore si populaire...

MySQL est un produit commercial dont l'origine vient d'une entreprise mercantile de nom MySQL AB, rachetée par SUN, et maintenant détenue par Oracle.*
Les gens de MySQL AB ont fait du prosélytisme en imposant "gratuitement" leurs outils dans toutes les distributions Linux et auprès des hébergeurs.
Comme les jeunes développeurs sont rarement capable d'étudier un produit avant de s’engouffrer dedans beaucoup ont mis le doigt dedans et ne jure que par MySQL sans avoir jamais pratiqué autre chose.

D'autre part, PostgreSQL étant un outil libre, il n'a pu bénéficier d'une talle publicité... Il faut bien payer les commerciaux qui démarchent !

A +

[Zwiter]

Je ne sais pas comment il faut comprendre ta phrase :
Avec normalisation c'est 3 fois plus lent ou 3 fois plus rapide ?

Sans normalisation, ma requete était 3 fois plus lente.
Mais l'equipe de recherche voisine soutient que c'est le contraire... il faudra que je teste leur bdd!

SQLpro :
Et cette politique aura fait une victime de plus. A force de manipuler MySQL avec les sites internet, ainsi que a la fac dans le cadre de ma formation...

Merci a vous!

[SQLpro]

C'est totalement lamentable de présenter MySQL comme étant un SGBD Relationnel. Cela n'en est pas un...

Il viole les règles de Codd, père fondateur des bases de données relationnelles sur plusieurs points.

Je suis atterré quand je voit des profs enseigner avec cette "chose" !

A +

[EIN-LESER]

Tout a fait en accord avec SQLpro pour ce qui est du fait que MySQL n'est PAS une base de données relationnel mais le fait qu'il soit utilisé pour une première approche d'sql est a mon sens compréhensible a condition de rester qu'une PREMIÈRE approche de ce sujet.

[Fred_34]

C'est totalement lamentable de présenter MySQL comme étant un SGBD Relationnel. Cela n'en est pas un...

Il viole les règles de Codd, père fondateur des bases de données relationnelles sur plusieurs points.

Je suis atterré quand je voit des profs enseigner avec cette "chose" !

A +

Ce genre de troll est inutile... Dois-je jeter à la poubelle ma voiture qui peut rouler à 200Kmh alors que la loi Française dit qu'il est interdit de dépasser les 130Kmh ?

Je suis de l'avis de Pomalaix (qui a écrit ça dans un autre sujet):

... l'invocation de la norme SQL est absolument stérile. Si le SGBD X est conforme à la norme sur tel ou tel point, tant mieux.
Dans le cas contraire, on cherche à savoir si X permet, et comment, de traiter la même problématique, et on adopte cette manière de faire.

Personnellement, je ne me permettrai pas d'encourager ou de décourager l'utilisation de Mysql car je n'ai aucune expérience avec des bases de 1 To.
Toutefois, j'ose espérer que chez Twitter ou FB, ce ne sont pas que des moutons décérébrés...

Vous avez convaincu Zwiter de faire des tests avec postgresql, j'espère pour lui que ce ne sera pas juste une perte de temps.
Postgresql est peut être plus complet que MySql, mais ce qu'il a en plus, est peut être en trop par rapport à ses besoins.

Vous l'avez également convaincu de normaliser sa base, j'espère pour lui que les résultats seront présents. Si ça se trouve, avec sa base normalisée, il lui faudra 4 heures pour écrire/débugger une requête qui comportent 12 jointures et qui s’exécutera en 2 secondes là ou il lui aurait fallu une heure pour écrire une requête simple qui se serait exécutée en 10 secondes (ou 1 seconde...).

Ce que j’essaie de dire, c'est que je pense que les généralités ne doivent pas forcément être appliquées à tout le monde.

Prenons mon cas :
Je développe une application qui a besoin d'une base de donnée. Mon objectif est notamment d'avoir des temps de réponses faibles.
Pour ce, certaines tables sont en partie dénormalisée.

Au départ l'applicaion utilisait uniquement MariaDB (Mysql).

Lisant de ci de là que Postgresql était plus complet que MySQL, nous l'avons intégrer.
Résultat :
- Les choses en plus sont en trop puisque elles ne sont pas utilisées
- Il a fallu réécrire ce qui était en moins dans Postgresql ( Par exemple show create table)
- Des performances moindres que MariaDB. ( Note: Je n'ai pas été aidé par un DBA ninja Postgresql pour la configuration...)


Ensuite, pour une question d'image, il a aussi fallu intégrer Oracle ( Ça fait sérieux sur le papier...).
Résultat :
- Beaucoup de temps pour l'installation
- Pas mal de temps pour l'intégration ( plus que Postgresql). De mémoire, les null, les types et les majuscules/minuscules...
- Des performances encore moindres que Postgresql. ( Note: La non plus, pas de DBA Oracle...)

J'ai même tenté d'intégrer SQLServer...

Que dois-je faire ? Ne plus utiliser MariaDB qui est le SGBD qui répond le mieux à mes besoins actuels, et prendre un SGBD plus cher et moins performant mais qui de l'avis des experts est meilleur en tous points ?

[SQLpro]

Que dois-je faire ? Ne plus utiliser MariaDB qui est le SGBD qui répond le mieux à mes besoins actuels, et prendre un SGBD plus cher et moins performant mais qui de l'avis des experts est meilleur en tous points ?

J'aime beaucoup le tissus de connerie que l'on lit dans ce forum... En gros vous nous dites que vous n'avez pas su administrer ni utiliser correctement les autres produits, et que par ce fait MySQL est meilleur...

Ayez au moins l'honnêteté de procéder à des test comparatifs censés et non une expérience futile faite sur un coin du bureau en cinq sec....

Quand aux exemples invoqués nous avons déjà dit, à de nombreuses reprises, qu'ils n'avait aucun intérêt car :
1) non transactionnel
2) base non monolithique.
Par exemple sachez que MySQL fait figure de pauvre en matière de volume de données ne serai-ce que chez les grand comptes français. Par exemple France Telecom utilise plus de 600 To sous Oracle....
Sauf que ce que l'on ne vous dit pas c'est que sous MySQL c'est répartit sur des centaines de serveurs avec u cout d'exploitation démentiel !
En revanche sous Oracle, c'est sur quelques serveur dont le TCO est bien moindre que même la solution mySQL soit disant gratuite....

A +

[gene69]

bon du coup si ya des tests perf sur la solution retenue ça m'interesse.

en tout état de cause, Mysql est détenu par Oracle. InnoDB est maintenu par Oracle. Y sont leader sur le marché il doit bien y avoir des raisons. On peut avoir des doutes sur la perfection de innodb surtout quand on lit les changelog mais bon quand je vois l'usage qui peut être fait d'une base oracle "pure"...

[SQLpro]

Oracle est en train de perdre des parts de marché sur le marché des SGBDR parce qu'ils sont beaucoup trop cher face à MS SQL Server qui fait aujourd'hui strictement l même chose avec un cout de 4 a 50 fois moins cher qu'Oracle...
De ce fait, oracle à racheter MySQL pour offrir une solution d'entrée de gamme afin d'attirer à lui la clientèle.
Sauf que ça marche visiblement pas aussi, les bons clients fuyant aujourd'hui MySQL de peur de l'hégémonie d'oracle, pas vraiment champion du libre....
Les bénéficiaires actules sont PostGreSQL (seule solution haut de gamme vraiment libre) et MS SQL Server.
Du coup Oracle tente de faire croire que MySQL peut remplacer SQL Server. mais là c'est prendre les clients pour des cons !

A +

[Fred_34]

Par exemple France Telecom utilise plus de 600 To sous Oracle....

C'est cette base de données qui a rendu l’âme vendredi ?

[Waldar]

C'est vrai que facebook est hébergé sur du MySQL, mais les besoins sont assez spécifiques, et surtout ils ont une équipe de petits génies qui recodent tout ce qui ne leur plaît pas ou leur manque dans MySQL.

Hors les petits génies, c'est cher et ça ne court pas les rues.

Faut-il mettre MySQL à la poubelle pour autant ? Je ne crois pas.
Il faut juste, comme toujours en informatique, avoir bien cerné les limites du produit qu'on utilise.
Pour des sites web, c'est adapté.
Pour mettre des applications dessus, sûrement pas pour toutes les raisons que SQLPro évoque régulièrement.

[Zwiter]

Hello,
Un message pour vous dire que je n'ai pas oublié de vous rendre mes conclusions. Les priorités au boulot ont changée cette semaine, donc migrer ma base de données en PostgreSQL prendra plus de temps. Sachez que je lis vos échange avec beaucoup d'attention.
Merci a vous tous.
Zwiter

[SQLpro]

C'est cette base de données qui a rendu l’âme vendredi ?

Orange c'est pas france telecom... Orange est une entité à part entière séparée de FT. FT gère les lignes fixes. Orange le mobile et Internet.

D'autre party on ne gère pas les communications avec une BD, mais seulment des infos de gestion (lignes, abonnement, facturation, y compris détaillé...).

A +

[tse_jc]

Bonjour,

Une petite intervention si vous me le permettez, en particulier pour fred_34.

Loin de moi l'idée de donner des leçons, ce n'est pas le but de ma démarche ici, mais à mon sens en tant qu'administrateur de base de données et au delà/indépendamment de toute considération d'ordre préferentielle, on se doit de préserver l'acidité et la qualité de nos données avant tout. Or par rapport à cela je vais faire que deux remarques.

1) Independamment du respect des règles de CODD, il faut bien se rendre à l'évidence qu'à partir d'une certaine volumétrie, MySQL n'est plus en mesure de garantir cela à un administrateur tout court, ou dans des conditions acceptables de gestion et de budget pour le reste (dépendant de la volumétrie). Je rappele aussi que la plupart du temps que les fortes volumétries sont proportionnelles à la volumétrie des accès concurrentiels transactionnés, ce qui en rajoute une couche à MySQL sur ce point.

2) En ingéniérie logicielle, s'il faut savoir adapter la résolution des contraintes métier aux contraintes techniques notamment représentées pour partie par les limitations d'un moteur BD tel innoDB puisque l'on est sur un forum MySQL, un administrateur BD est en droit de pouvoir disposer de tous les outils mis à sa disposition par l'algèbre relationnelle de manière à pouvoir faire son travail dans de bonnes conditions. D'ailleurs certains manquement à ce niveau par MySQL ne peuvent malheureusement pas toujours être contournés. Rien qu'à ce titre, le respect des règles de CODD est le minimum syndical que tout administrateur/société est en droit d'attendre de son SGBDR.

Que penseriez vous d'un serveur objet violant pour partie les règles de la POO et/ou ne les implémenteraient que d'une manière partielle? Je suis certain que votre position ne serait pas autant pondérée.

Cordialement,

Jc.