Discussion :

[d3b14n2121]

Bonjour à toute la communauté,

Heureux de vous rejoindre ce jour J'espère que je pourrai apporter mon aide sur le forum. Aujourd'hui par contre c'est moi qui rencontre un soucis que je n'arrive pas à résoudre avec MySQL.

Pour faire simple : pour tracker en détail les envois de mes emails, lors de chaque envoi sur ma base d'utilisateurs j'effectue un INSERT correspondant à mon nombre d'utilisateurs, environ 100k pour l'instant. Je fais donc un INSERT de 100k lignes environ pour chaque newsletter qui sont ensuite traités par un cron au fur et à mesure (lissage). Lorsque je fais des modifications je fais des UPDATES sur ce même nombre de lignes.

Mon soucis est très simple, le temps d'un INSERT/UPDATE même si il est très rapide, sur des centaines de milliers de lignes, la requête devient beaucoup trop longue (environ 40 secondes). Mes requêtes sont vraiment bien optimisées, là je suis devant un vrai problème de temps d'un INSERT quoi qu'il arrive. Et si un jour j'arrive à devoir INSERT/UPDATE un million de lignes je ne veut même pas imaginer :/

la question à ultra simplifié est donc : je veux insérer/update 1 000 000 d'enregistrement en quelques secondes comment faire ?

Sachant que cette architecture est indispensable pour un suivit parfait de mes emails, je suppose donc que je suis foutu et que je dois changer de SGBD ?

Peux-être avez-vous une technique (qui je pense n'existe pas pour MySQL) ? Sinon quel SGBD choisir pour insérer et update des millions d'enregistrements en seulement quelques secondes ?

Je pense que cela est possible car je sais de source sur que les opérateurs type Mailjet et compagnie enregistre bien chaque email envoyé sur une ligne. Donc des millions voir des milliards de lignes traités chaque jour.

Je suis désolé si je m'exprime mal. Merci de bien comprendre que l'optimisation des requêtes ne changera rien, seul une stratégie ou changement de SGBD pourrait m'aider il me semble.

Merci par avance à toute la communauté

[Obsidian]

Bonjour et bienvenue,

Tu as réellement 100.000 utilisateurs inscrits et actifs dans ta base ? Si c'est réellement le cas, tu devrais avoir des infrastructures conséquentes et dimensionnées à ton activité. Dans tous les cas, je dirais au moins que le temps de traitement de tes requêtes devrait être largement compensé par le temps d'envoi des e-mails associés, à moins d'être propriétaire d'un backbone continental.

Il y a au moins un point que tu peux contrôler : est-ce que tu effectues des transactions ? J'ai déjà rencontré le cas en travaillant sur une base de résultats de recherche en génétique (donc à coups de millions d'insertions également), où l'utilisateur faisait un BEGIN, cinq cent mille insertions, et un COMMIT à la fin. :-\ Sachant que le SGBD enregistre toutes les directives dans une table temporaire qui grossit au fur et à mesure et pose ensuite des locks pour honorer la transaction de façon atomique, le serveur restait coincé pendant une nuit entière. Bon, à l'époque, c'était sous Sybase ASE 12.5, pas MySQL.

Autre point important : les index. Ils devront être mis à jour à chaque insertion, donc si tu en as un ou plusieurs, il peut être intéressant de les optimiser (voire de les désactiver et les recalculer en une fois, si c'est possible).

Pour le reste, il est probable que ton modèle soit malgré tout intrinsèquement mauvais et notamment, qu'il recoure pour rien à des produits cartésiens. 1000×1000 utilisateurs, ça fait un million de combinaisons et ça reste abordable pour un PC. 100.000 × 100.000 utilisateurs, en revanche, représente dix milliards de combinaisons. Ce n'est donc pas 100 fois plus long, mais 10.000 fois. C'est la différence qu'il y a entre une heure et un an.

À ce stade, il peut être également intéressant de se pencher sur l'usage que tu fais de ta base : si c'est une vraie base de donnée relationnelle avec des cardinalités bien étudiées, des contraintes d'intégrité, etc. c'est valable. Si en revanche, chaque table est plus ou moins indépendante des autres et remplit le même office qu'une feuille de tableur, alors il peut être plus intéressant de se tourner vers des flat files pré-dimensionnés et mappés en mémoire par un processus système.

Enfin, bien sûr, il convient d'examiner les technologies que tu utilises pour traiter ces requêtes et pour communiquer avec le serveur : si tu utilises des curseurs avec des requêtes dûment préparées et des données proprement indexées en mémoire, ça passe, mais si tu utilises un langage de script interprété qui va construire une chaîne de toutes pièces pour chaque insertion et que le serveur doit recevoir et analyser à chaque itération, ça risque de vite devenir lent là aussi.

À défaut de trouver de quoi creuser dans tout cela, tu pourras te pencher sur la complexité de tes algorithmes et essayer de déterminer dans quelle mesure ils explosent avec l'augmentation du nombre de tes utilisateurs.

[SQLpro]

Que voulez vous que l'on vous dise ?
MySQL n'a jamais été taillé pour faire des choses fines et performantes sur de gros volumes de données...
Contrairement à une légende urbaine, MySQL n'est pas le plus performant des SGBD... mais dans bien des circonstances, c'est un veau !
À me lire : http://blog.developpez.com/sqlpro/p9...alles_en_sql_1

Pour aller vite dans les mises à jour, il faut plusieurs conditions :
1) une journalisation minimale (exemple : SQL Server permet de journaliser en mode complet, en bloc ou simple)
2) une mise en cache maximale (exemple : SQL Server par défaut prend toute la RAM du serveur comme cache)
3) une gestion des espaces de stockage fait par le SGBDR et non pas la couche système (exemple : SQL Server a ses propres routines d'écriture disque à bas niveau)
3 bis) À condition d'avoir le 3, une organisation physique du stockage sur le serveur physique qui n'utilise que des niveaux de RAID 0, 1 et toutes combinaisons avec 0 et 1, mais pas 5, 6, DP et autres combinaisons, et si utilisation d'un SAN, qu'il soit dédié...
4) éventuellement la création de tables "in memory" (SQL Server est doté depuis la version 2014 d'un moteur "In Memory") qui ne journalisent pas et ne sont pas persistantes : http://www.microsoft.com/fr-fr/serve...in-memory.aspx)
5) pour des chargement en masse un ETL parallélisé dédié (SQL Server dispose d'un des ETL les plus puissants - https://technet.microsoft.com/en-us/...ql.100%29.aspx)

Notez que Oracle propose les mêmes solutions mais pas du tout au même prix !

A +