Discussion :

[toham]

Bonjour,

Dernièrement face à une problématique lors de la conception d'une fonctionnalité d'un site pour mon boulot, j'ai du migrer des données (initialement sous MySQL) sur Redis, pour des raisons de performances principalement. Cependant, au début j'ai tout de même passé un peu de temps à structurer ma base Redis pour qu'elle aussi simple d'utilisation que sous MySQL.

Du coup pour m'amuser j'ai commencé à développer une sorte d'ORM sous Symfony pour Redis, c'était cool et j'arrivais à avoir de bons résultats, mais ce n'était pas encore assez rapide à mon goût et bien trop critique. En gros mon ORM ce chargeait de récupérer les données directement de Redis puis de faire des traitements en PHP, ce qui peut être très lourd lors de la manipulation de données.

Prochaine étape, j'ai développé un moteur de base de données relationnelle Redis sous Node.js. Par conséquent, je lui envoie un requête de type SQL et je récupère la réponse, je gère presque toutes les requêtes "simples" (tout ce qui concerne la structure et données de la base de données).

En terme de performance, et avec un système de cache, j'arrive à des temps d’exécution assez faible, mais toujours inférieur à MySQL...mais seulement quand ça concerne peu de données, par contre le moteur a une bonne scalabilité et c'est ce que je recherche.

La ou j'ai besoin de votre avis, pensez-vous que je devrais revoir tout mon moteur et l'adapté plutôt en C/C++ ou Golang ? Pour de meilleurs performances.

J'ai vraiment des doutes, et même si j'ai déjà une bonne version beta de mon moteur sous Node.js, je trouve ça pas très portable, alors qu' un moteur implémenté en C/C++ est certainement beaucoup plus simple d'installation sur des serveurs (ou pas, peut être que je me goure complet).

J'attends vos avis.

Merci

[Luckyluke34]

[Mode pinailleur ON]

A moins que tu ais greffé à Redis de l'intégrité référentielle et tout le toutim, il me semble que tu n'es pas en train de développer un moteur de base de données relationnelle mais une surcouche de requêtage SQL sur un moteur NoSQL.

[Mode pinailleur OFF]

On peut par ailleurs se demander s'il est pertinent de vouloir requêter un store NoSQL avec des requêtes SQL et s'interroger sur le coût induit par la couche d'adaptation.

Sinon, les SGBD relationnels du marché bénéficient parfois de 30 ans de R&D en continu. Ca va être difficile de faire mieux en matière de perf à mon avis.

(oui, je sais, ça répond pas à la question principale )

[toham]

Dans mon moteur je gère évidemment l'intégrité référentielle, les index, deux niveaux de mises en cache pour améliorer les performances, et d'autres subtilités.

Evidemment, l'intérêt d'un tel moteur n'est pas de substituer un serveur MySQL (par exemple) par Redis et mon moteur. C'est totalement ridicule et comme tu le dis par pertinent du tout.
Non l'intérêt, est de pouvoir traiter un gros volume de données en un minimum de temps, ces données sont structurées, ont des spécifications bien définies.
C'est à dire que si c'est pour gérer quelques centaines/milliers d'enregistrements, non ça ne sert à rien, les SGBDR le font très bien.
Mon besoin à la base c'est quoi ? Pouvoir intégrer des données, le volume de données peut augmenter de manière exponentielle, en gros aujourd'hui je peux intégrer environ 6000 enregistrement, et peut être que demain je devrais en faire 10 fois plus. Il me faut quelque chose de suffisamment scalable, et MySQL ba ça galère à mort, à la restitution des données, c'est lent et c'est la le gros problème, il faut que ce soit très rapide car les utilisateurs qui devront intégrer ces données ne sont pas censés passer des plombes devant leur écran pour attendre la fin de l'intégration (même si actuellement, tout se fait de façon asynchrone).

Dans un premier temps, c'est effectivement une surcouche SQL, la deuxième étape est de trouver d'autres mécaniques pour gérer des problèmes mathématiques (genre théorie des ensembles un peu plus poussé que ce que propose Redis) plus ou moins complexes qui collent à mes besoins.

Comme je l'ai dit, je fais ça aussi pour m'amuser, je trouve ça marrant d'aller chatouiller un peu d'autres horizons.

[Luckyluke34]

OK

Loin de moi l'idée de jouer les rabat joie sur l'intérêt du projet (effectivement même à titre expérimental c'est très intéressant)

Mais prétendre faire mieux que les ténors du marché, à moins d'avoir des cas d'utilisation de niche hyper spécifiques à ton domaine, ça me parait osé.

Je ne comprends pas très bien non plus où se situe ton goulet d'étranglement au niveau des perfs. Tu parles de lenteurs de restitution des données pour des utilisateurs qui intègrent ces données...

Par ailleurs, je ne comprends pas pourquoi vouloir garder à tout prix l'approche relationnelle dans l'équation. C'est quoi les qualités intrinsèques du SQL qui t'intéressent, et celles du NoSQL, qui t'amènent à vouloir marier les deux ?

[toham]

Bien sûr que je ne prétends pas faire mieux que ce qui existe déjà Juste réussir à avoir au moins un outil optimisé pour ce que je souhaite faire, ou pour jouer...

Le goulet d'étranglement, c'est simplement l'intégration et le traitement qui doit être fait quasi simultanément.

Pour donner un exemple concret, via un flux de données je dois intégrer un certains nombre de données, ces données, ce sont celles de centres de relations clients (genre les gens qui te démarchent le soir à 21h pour te vendre un nouveau contrat d'assurance), la quantité de données peut varier. Bon en soit l'intégration est très simple, de simple INSERT dans un base fait l'affaire, sauf que juste après ces données doivent être interprété en faisant des calcules complexes et dynamiques, et il faut que ce soit très rapide pour l'utilisateur.

Exemple : J’intègre pour 300 personnes, une dizaine d'indicateurs pour une date donnée. 3000 données, en soit c'est peu, mais derrière je peux avoir des indicateurs composites, qui eux sont créer par le client avec des formulaires plus ou moins complexes, sachant qu'on peut imbriquer autant d'indicateurs que l'on veut. Dans notre cas, on a 5 niveaux d'imbrication. Sachant que les données intégrés ne concerne qu'un certains type d'utilisateurs (on les appel des collaborateurs), sauf que parfois j'ai aussi besoin de calculer des données pour une équipe de collaborateur suivant des agrégat différent de temps et d'ensemble...bref je rentre un peu trop dans les détails. Chacun de ces données sont utilisé par d'autres outils dans mon application. En gros on a un entrepôt de données ou l'on stock toutes nos données selon une date, un collaborateur et un indicateur, et on a environ 4 outils d'animation qui viennent s'y greffer pour y récupérer et calculer les résultats sur une ou plusieurs périodes pour certains utilisateurs.

Et la ou ça complique, c'est que les animations déclenchées sont à la main du client, nous sommes donc obligés de généré les résultats calculés quand une intégration de données (ou manuellement par le client) est effectuée ui se trouve dans la période des animations déclenchées.

Edit : Ah et il faudra bientôt que je développe un outil de monitoring builder, ou chaque responsable pourra voir en temps réel les données qu'il souhaite sous la forme qu'il souhaite, enfin jouer avec les données comme il l'entend pour une meilleure restitution des données...et la il me faut un truc en temps réel (et donc des calcule complexe d'indicateurs dynamiquement).

Voila pour la petite explication, donc au final, pour 10 challenges, qui sont composés chacun d'une dizaine d'indicateurs (avec un niveau de composite de 5), qui concerne quelques centaines d'utilisateurs, tu te doutes que le traitement de tout ça est assez énorme et MySQL est absolument à la ramasse, sans parler de Php qui n'est pas du tout fait pour ça, manque de temps difficile de se former sur un langage plus à même de gérer ces traitements.

Du coup il faut que je change un peu ma façon de traiter les données, il me faut donc à la fois de la souplesse et des données structurés. Tout ce qui concerne les algorithmes de traitements, je les ai en têtes mais il me faut un système pour récupérer très rapidement un grand nombre de données, de façon intelligente qui pourrait m'éviter d'effectuer des traitements un peu bâtard dans mon algorithme.

Le côté relationnel, c'est simplement que les données que j’intègre doivent être structurés le plus strictement possible, mais je dois avoir à coté avoir la souplesse et la simplicité du NoSQL (plus particulièrement le système clé-valeur) pour gérer "stocker" mes traitements intermédiaires.

Donc pour le moment, le côté relationnel je l'ai, je peux restituer le résultats d'une requête de type SELECT avec des SUM et AVG, GROUP BY et tout le bazar, mais la seconde partie de mon moteur c'est plus axé mathématiques, enfin ça veut otu et rien dire. Disons qu'il faut que je réfléchisse encore un peu plus sur une structure, un mécanisme pour coller au mieux à mes besoins, tout en restant suffisamment générique pour que ça puisse être réutilisable.

J'espère que ça répond à tes questions.

[DonQuiche]

Les problèmes de performances viennent des accès disques dispersés, non ? As-tu essayé de simplement augmenter la taille du cache, ou d'utiliser un SGBD in-memory (gros gains potentiels) ? De toute façon je ne crois pas que tes besoins soient suffisamment spécifiques pour te permettre d'utiliser des algorithmes différents de ceux utilisés dans toutes les DB.

Enfin ne peux-tu pas réduire la DB à un simple rôle de sauvegarde et tout garder en mémoire, et ainsi travailler directement sur des objets ? Est-il vraiment nécessaire de sauvegarder les calculs des indicateurs composites ?

[toham]

Redis est un SGBD In-memory, tu parles plutot d'un SGBDR In-memory, comme Voltdb ou SAP HANA ?
J'avais pensé au début à utiliser ce genre de système comme zone tampon pour mes traitement, tout en gardant une persistance en base de données conventionnel type MySQL. Mais je vois pas l'intérêt si ce n'est rajouté une couche qui je pense peut être plus problématique qu'autre chose, car il me faut de la haute disponibilité, et j'ai peur que implémenter cette fameuse couche entre mon SGBD In-memory (genre Redis) et mon SGBDR MySQL me fasse perdre plus de temps, alors que si tout est déjà sur Redis, avec une bonne configuration suffit.
Pour les SGBDR In-memory, faut que je regarde de plus prêt, ou même les SGBD NewSQL....

Pour l'histoire d'un indicateur composite, je vais te donner un exemple concret pour comprendre que devoir recalculer un composite me bouffe trop de temps :
- Indicateur : A+B+C+D+E+F+G+H+I+J+K+L+M+N
- Indicateur "A" : ((O > 78 && P > 7)?((Q>=0.28)?13.26*R:((Q>=0.25)?11.31*R:((Q>=0.21)?9.36*R:((Q>=0.18)?7.41*R:((Q>=0.14)?5.46*R:((Q>=0.12)?3.51*R:0)))))):0)
- Indicateur "O" : (@((100*AA)/BB) === false ? 0 : (100*AA)/BB)
- Indicateur "P" : (@(CC/DD) === false ? 0 : CC/DD)
Donc au final, voici une petite idée du calcul à traiter dynamique :

Code :

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

(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 78 && (@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 7)?(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.28)?13.26*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.25)?11.31*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.21)?9.36*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.18)?7.41*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.14)?5.46*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.12)?3.51*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):0)))))):0) + (((@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 78 && (@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 7)?(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.28)?13.26*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.25)?11.31*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.21)?9.36*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.18)?7.41*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.14)?5.46*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.12)?3.51*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):0)))))):0) + (((@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 78 && (@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 7)?(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.28)?13.26*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.25)?11.31*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.21)?9.36*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.18)?7.41*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.14)?5.46*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.12)?3.51*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):0)))))):0) + (((@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 78 && (@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 7)?(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.28)?13.26*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.25)?11.31*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.21)?9.36*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.18)?7.41*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.14)?5.46*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.12)?3.51*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):0)))))):0) + (((@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 78 && (@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 7)?(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.28)?13.26*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.25)?11.31*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.21)?9.36*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.18)?7.41*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.14)?5.46*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.12)?3.51*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):0)))))):0) + (((@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 78 && (@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 7)?(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.28)?13.26*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.25)?11.31*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.21)?9.36*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.18)?7.41*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.14)?5.46*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.12)?3.51*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):0)))))):0) + (((@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 78 && (@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 7)?(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.28)?13.26*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.25)?11.31*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.21)?9.36*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.18)?7.41*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.14)?5.46*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.12)?3.51*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):0)))))):0) + (((@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 78 && (@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 7)?(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.28)?13.26*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.25)?11.31*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.21)?9.36*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.18)?7.41*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.14)?5.46*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.12)?3.51*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):0)))))):0) + (((@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 78 && (@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 7)?(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.28)?13.26*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.25)?11.31*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.21)?9.36*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.18)?7.41*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.14)?5.46*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.12)?3.51*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):0)))))):0) + (((@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 78 && (@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 7)?(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.28)?13.26*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.25)?11.31*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.21)?9.36*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.18)?7.41*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.14)?5.46*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.12)?3.51*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):0)))))):0) + (((@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 78 && (@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 7)?(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.28)?13.26*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.25)?11.31*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.21)?9.36*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.18)?7.41*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.14)?5.46*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.12)?3.51*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):0)))))):0) + (((@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 78 && (@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 7)?(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.28)?13.26*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.25)?11.31*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.21)?9.36*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.18)?7.41*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.14)?5.46*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.12)?3.51*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):0)))))):0) + (((@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 78 && (@((100*AA)/BB) === false ? 0 : (100*AA)/BB) > 7)?(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.28)?13.26*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.25)?11.31*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.21)?9.36*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.18)?7.41*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.14)?5.46*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):(((@((100*AA)/BB) === false ? 0 : (100*AA)/BB)>=0.12)?3.51*(@((100*AA)/BB) === false ? 0 : (100*AA)/BB):0)))))):0)

.....
Et encore la on a seulement 4 niveaux d'imbrication, sur l'indicateur composite tout en haut, les 14 indicateurs qui le compose ressemblent à quelques petits détails à l'indicateur "A".
Donc recalculer à chaque fois

[DonQuiche]

Je ne suis pas sûr qu'on se comprenne bien. Pourquoi devrais-tu faire cohabiter un SGBD in-memory avec un SGBDR traditionnel ? Quand tu disais dans ton message initial que les traitements avec Redis étaient lourds, parlais-tu des performances ou de la facilité à programmer ? J'ai l'impression que tu veux une interface relationnelle pour la facilité de programmation , c'est bien ça ? Si oui, alors un SGBDR in-memory pourrait effectivement être ta réponse.

Pour tes indicateurs composites, en soi ils n'ont pas l'air coûteux du tout à calculer mais j'imagine que le problème vient de la récupération des données sources ? Mais ces données ne sont-elles pas requises pour d'autres calculs de toute façon ? Quelle est la somme des tes données par client ? Ne serait-il pas possible de récupérer toutes ces données d'un coup puis de calculer les indicateurs composites à la volée ?

[toham]

Ma question première vient du choix du langage. Actuellement mon moteur tourne sous node.js. Il fait le boulot, mais je voulais juste savoir si un langage comme C++ pour ne cité que lui, serait plus performant. Je parle bien que de la performance du langage. Je ne pense pas que la programmation événementielle de Node.js soit le meilleur paradigme pour mon moteur, alors que C++ permet une programmation orienté objet, ce qui pour ma part me simplifierait la vie en terme d'organisation du code et développement.

Cela ne te parait pas coûteux à calculer...je me demande si on parle bien de la même chose . Le problème ne vient pas de la récupération des données mais bien du traitement des données. Quand tu parles de sommes de données, tu parles de quoi, du volume que ça représente ?
Actuellement, je ne récupère pas toutes les données d'un coup (chose qui va changer) mais je calcule bien la valeurs des indicateurs composites (ou pas) à la volée, déjà la je sais qu'il y a un problème.

[DonQuiche]

Il est évident qu'un code C++ est plus performant qu'un code JS de niveau comparable (disons 3x avec un excellent compilateur JIT comme celui de node). Sauf que souvent les performances dépendent des accès disque ou réseau et non pas du temps d'exécution lui-même. Par ailleurs un code C++ est plus long, plus coûteux et plus bogué. Enfin JS a bien des défauts, mais le C++ est un langage des années 70 qui est lui-même bourré de défauts dus à son âge.

Et, non, une quarantaine d'opérations arithmétiques ne sont pas coûteuse à calculer !
* Si le processeur a tes vingt opérandes en cache, cela lui prendra moins de vingt nanosecondes.
* S'il faut aller les chercher en mémoire il en coûtera quelques centaines de nanosecondes.
* S'il faut aller les chercher sur le disque ou ailleurs sur le réseau, il faudra quelques dizaines de microsecondes.

Et ces coûts augmentent d'un ou deux ordres de grandeur lorsque les données sont contenus dans de lourdes structures de données nécessitant des accès disséminés sur plusieurs pages du disque ou zones mémoire non contiguës ! Et plus encore s'il faut mettre en œuvre des mécanismes de synchronisation pour faire cohabiter des lectures et écritures concurrentes. Et l'écriture est encore plus lourde que cela. Bien que concernant les accès disque les SGBD mutualisent les écritures, ce qui implique parfois un temps d'attente, et mettent en cache les lectures.

[toham]

Désolé, mais comme je le disais, je ne pense pas que tu comprennes l'ampleur des calcules. La "quarantaine d'opérations arithmétiques" à faire, ce sera à la limite pour un seul périmètre (1 personne, une période données, 1 indicateurs) sauf que dans la majeur partie des cas, c'est pour au moins 200 personnes, environ 3 à 4 périodes différentes (et donc autant de calculs à faire) et pour plusieurs indicateurs...donc prenons un exemple, si sur une période données, on a 4 animations de lancés, ayant chacun 200 utilisateurs concernés, et environ 5 indicateurs, cela nous donne 4*5*200, soit 4000 opérations à faire. 4000 c'est pas beaucoup, je suis bien d'accord, sauf que la on parle que de 4 animations, et qu'on ça ne concerne qu'un seul client, demain on peut très bien avoir une dizaine de clients, avec entre 200 à 4000 utilisateurs de l'applications, donc plus il y a d'utilisateurs, plus il y a d'animations déclenchés, plus il faut avoir quelque chose de performants pour éviter que le serveur perde la tête.

Sur la grosse opération arithmétique que je t'ai montré, dis toi bien que pour chaque variable, il faut aller chercher la données. Sauf que suivant la période il faut rajouter encore des calculs intermédiaires. Imaginons, notre client a effectué 3 imports (le premier du du 01/11 au 05/11, le second du 06/11 au 11/11 puis du 12/11 au 17/11), et que moi j'ai une animation du 01/11 au 17/11...donc il faut en plus que je fasse un calcul (certes ultra simple, soit on fait une somme, une moyenne ou un taux d'évolution), mais plus il y aura de variables différentes dans notre gros opération, plus on a de calcules intermédiaires, et donc à nos 4000 opérations de toute à l'heure, on le multiplie par le nombre de calcul intermédiaire...tout ça juste pour 4 pauvre animations qui concerne seulement 200 personnes.

Désolé, je passe beaucoup de temps à expliquer tout ça, mais c'est nécessaire pour poser la situation. Si demain on un client qui souscrit 4000 licences, qui souhaite interfacer des flux de données, pour mettre à jour toute la plateforme chaque jour, avec une moyenne (au minimum hein, car il y a aussi des animations individuels qui peuvent se multiplier très rapidement) de 3 à 5 animations...avec un référentiel d'indicateur, complexe, poussée avec des agrégat temporelle et ensemble dans tous les sens, des périmètres différents dans les indicateurs composites....il faut avoir un script qui tienne la route.

Au final, t'es questions et réponses sont super pertinentes, car ça me permet de mieux cerner ce que je vais devoir optimiser encore plus.

Donc pour revenir au sujet. Je pense garder Redis comme SGBD In memory pour un accès cache très rapide. As-tu une idée du langage qui pourrait répondre à toutes mes attentes ? Après, c'est aussi une question d'hardware, aujourd'hui on a un serveur dédié tout simple chez OVH, et je pensais justement à augmenter de gamme si on a ne plus en plus de nouveaux clients.

En tout cas merci de tes réponses.

[DonQuiche]

Tu poses le problème d'une façon erronée : tu justifies la mise en cache des intermédiaires de calcul (indicateurs composites) par le fait qu'il y a plusieurs utilisateurs qui pourraient faire plusieurs requêtes, et qu'au final on va recalculer plusieurs milliers de fois la même chose. Sauf qu'on s'en fiche : tout ce que tu veux vraiment c'est pouvoir traiter toutes les requêtes en heure de pointe. Avoir un serveur par gros client n'est a priori pas un problème pour le coût de votre offre. Tu dois donc seulement te concentrer sur tes besoins en pointe pour une seule base de données commune. Quelle est la fréquence en pointe des lectures ? Et des écritures ?

Ensuite tu te concentres sur l'optimisation des lectures. Mais les écritures sont beaucoup plus coûteuses. Or la mise en cache des indicateurs implique des écritures supplémentaires et parfois inutiles. Il te faudra en effet, à chaque écriture, invalider ou mettre à jour tes indicateurs (à moins que tu utilises de simples dates de péremption). C'est aussi coûteux en euros à coder et maintenir. A ton échelle mettre en cache ces indicateurs n'est donc indiqué que s'il y a un problème incontournable de performances et s'ils économiseront suffisamment d'accès pour compenser les écritures induites.

Pour terminer sur les performances, il faut bien comprendre que si tes données étaient immuables, contenues en mémoire, stockées en tant qu'objets, et tenaient sur quelques centaines de Mo, tu pourrais réaliser aisément plusieurs Go d'accès par seconde et calculer des dizaines de millions d'indicateurs composites dans ce laps de temps, sans outil tierce ou optimisation particulière. Si une base de données est beaucoup plus lente c'est parce qu'elle fait cohabiter lectures et écritures concurrentes en garantissant la transactionnalité, parce qu'elle persiste tout sur le disque, parce qu'elle est optimisée pour lire depuis le disque, parce qu'elle est capable de gérer des bases de plusieurs pétaoctets réparties sur des milliers de serveur avec réplication, et parce qu'elle doit transformer des chaînes de caractères en commandes (vivent les requêtes paramétrées). A part la concurrence, ces fonctionnalités n'ont aucun intérêt pour tes indicateurs composites, que tu pourrais te permettre de perdre en cas d'extinction du serveur.


Concernant Redis, un mot : tu n'auras de bonnes performances que si ton problème correspond à ce pour quoi il est fait : accès clé/valeur, listes, ensembles. Si tu veux parcourir les données du client #1359, super. SI tu veux trouver tous les clients ayant claqué plus de 150€ et nés avant 1960, mieux vaut sans doute un SGBDR in-memory (à moins d'avoir préalablement créé un ensemble 150€ et d'y ajouter manuellement les clients en question). Je connais peu Redis cela dit.

Concernant le langage, je ne pense pas que ce soit ton facteur limitant. Le choix idéal serait un langage moderne, productif et facile à maintenir. Go ou Scala, avec quelques légers doutes sur l'avenir de Go (pas plus que nodejs sans doute). Mais tu peux rester sur JS si tu es à l'aise avec lui.

[toham]

C'est vrai que je me concentre un peu trop sur la lecture des données et moins sur l'écriture, simplement parce que pour une centaine de lecture j'ai une écriture.

SI tu veux trouver tous les clients ayant claqué plus de 150€ et nés avant 1960, mieux vaut sans doute un SGBDR in-memory (à moins d'avoir préalablement créé un ensemble 150€ et d'y ajouter manuellement les clients en question). Je connais peu Redis cela dit.

Il y a quelque chose dans ce que tu dis qui est très intéressant (cf ce qui est en gras), c'est justement l'objet de la seconde étape que je souhaite mettre en place sur mon moteur. Mon but n'est pas simplement de transformer un SGBD IM en SGBDR IM, ça n'a bien sur aucun intérêt. Bien sur le faire est toujours sympa à développer, mais à par ça il n'y a pas vraiment de gros challenge.
Non la ou ça devient intéressant, et c'est la tout l'intérêt de mon moteur, c'est de pouvoir automatiser et rendre dynamique un processus que l'on est censé faire manuellement. Ton exemple est très parlant, et plus haut dans ce topic, je parlais des "vues matérialisées" qui est aussi un exemple de ce que je souhaite pas.

Redis, que ce soit en écriture et en lecture, il faut partie des SGBD les plus rapides. Mais pour utiliser Redis, il faut avoir réfléchie à la structure de ses données, c'est 95% du travail, car si ce n'est pas assez poussée alors on se retrouve à devoir faire des appels intermédiaires.

Pour le langage, Go faisait partie des langages auxquels j'avais pensé, mais tu n'es pas le premier à douter de l'avenir de Go, et ça m'inquiète un peu, car j'ai envie de m'y mettre mais si c'est le voir mourir dans 5/10 ans...

En fait, si je prends un peu de recul, créer un moteur relationnel pour Redis est un peu inutile si je m’arrête à ça, il faut que je lui greffe un truc en plus.

Après ce qui concerne mon projet, pour optimiser au mieux tous les traitements, il faut juste bien s'organiser, et je pense qu'avec les conseils que tu me donnes, ça me permettra déjà de minimiser le temps de traitement de quelques points.

[DonQuiche]

C'est vrai que je me concentre un peu trop sur la lecture des données et moins sur l'écriture, simplement parce que pour une centaine de lecture j'ai une écriture.

Mais si ce changement impacte vingt indicateurs, chaque écriture en causera-elle vingt autres ? Comment vas-tu gérer la propagation des changements ?

Non la ou ça devient intéressant, et c'est la tout l'intérêt de mon moteur, c'est de pouvoir automatiser et rendre dynamique un processus que l'on est censé faire manuellement. Ton exemple est très parlant, et plus haut dans ce topic, je parlais des "vues matérialisées" qui est aussi un exemple de ce que je souhaite pas.

D'accord, je comprends ce que tu essayes de faire.

Mais pour des bases de quelques Mo, je trouve que c'est tout de même faire une grosse usine à gaz alors qu'il te suffirait de charger toute ta base en mémoire, puis de faire tous les traitements en mémoire et sur un seul thread. Si tu as quelques milliers d'employés tu peux te permettre de les scanner sans jamais créer d'indexes. Simple, brutal, efficace.

Et pour toute optimisation, tu te contentes de mettre en cache les résultats des requêtes et tu invalides tout à la moindre écriture. Ça vaut aussi si tu utilises une DB d'ailleurs, plutôt que de mettre les indicateurs en cache.

[toham]

Mais si ce changement impacte vingt indicateurs, chaque écriture en causera-elle vingt autres ? Comment vas-tu gérer la propagation des changements ?

Je ne sais pas trop ou tu veux en venir en parlant de changements. Mais dans tous les cas, on a plus de lecture que d'écriture, et plus le temps passe et plus la différence entre le volume de lecture et d'écriture va se creuser, tout en gardant une proportionnalité.

Mais pour des bases de quelques Mo, je trouve que c'est tout de même faire une grosse usine à gaz alors qu'il te suffirait de charger toute ta base en mémoire, puis de faire tous les traitements en mémoire et sur un seul thread. Si tu as quelques milliers d'employés tu peux te permettre de les scanner sans jamais créer d'indexes. Simple, brutal, efficace.

Alors oui c'est une idée intéressante, cependant j'ai peur d'être en grosse galère si demain, on a 5 clients de 4000 collaborateurs qui souscrivent au programme, et même si ça passe, je n'ai pas l'assurance que tout se passera toujours bien.

[DonQuiche]

Je ne sais pas trop ou tu veux en venir en parlant de changements.

Dans l'exemple que tu avais fourni plus tôt, chaque fois que tu changes A ou B tu dois changer la valeur des indicateurs composites qui en dépendent. Et comme d'autres indicateurs dépendent de ceux-ci, tu dois également les modifier. Tout système réactif implique des cascades d'événements.

Si tu veux mettre tes indicateurs en cache, alors tu dois définir une politique d'invalidation et de mise à jour. Selon ce que tu veux faire ça peut être très simple et rapide (révisions à date fixe), ou très complexe et très lent (cascades).

Alors oui c'est une idée intéressante, cependant j'ai peur d'être en grosse galère si demain, on a 5 clients de 4000 collaborateurs qui souscrivent au programme, et même si ça passe, je n'ai pas l'assurance que tout se passera toujours bien.

Tu n'as pas non plus l'assurance que ça se passera bien avec Redis. La scalabilité dépend autant du système que de l'usage qui en est fait. Par exemple tu envisages pour créer dynamiquement des indexes de scanner linéairement toute la base, quelles vont être les implications face à des requêtes concurrentes ou en heure de pointe ?

Cela dit, encore une fois, 4000 collaborateurs ça veut dire une base de quelques Mo, ce qui est ridiculement petit. Ça peut être suffisant pour mettre un SGBD à genoux, surtout si tu l'utilises mal, par exemple en introduisant une gestion complexe de caches qui n'est pas forcément nécessaire, mais ce sont des volumes de données ridiculement faibles pour un traitement en mémoire sans SGBD. Dans ce cas les limites s'expriment en millions ou milliards. Et au pire des cas, ajouter dynamiquement des indexes ne sera pas plus compliqué qu'avec Redis ou MySQL.

Accessoirement tu n'as pas besoin de stocker tes 5 clients sur le même serveur : ça n'est sûrement pas significatif en termes de coûts et certains clients pourraient d'ailleurs vouloir une machine dédiée. La scalabilité c'est d'abord pouvoir découper son problème.


Sans vouloir te vexer, j'ai un peu peur que tu sois dans le cas de l'architecte chargé de concevoir un pavillon et qui fait venir une grue de cent mètres au cas où. Comme il faut ensuite trouver la place pour la grue, il achète les terrains avoisinants. Ça retarde la circulation des personnes et produits, alors il construit une voie ferrée entre les postes. Et comme il lui faut une centrale électrique afin d'alimenter tout le chantier, il décide de bâtir une usine de panneaux solaires.

La simplicité est la meilleure amie de l'ingénieur. Bien plus que les outils compliqués, même lorsqu'ils ont été mis à la mode par des personnes avec des besoins compliqués.

[toham]

Dans l'exemple que tu avais fourni plus tôt, chaque fois que tu changes A ou B tu dois changer la valeur des indicateurs composites qui en dépendent. Et comme d'autres indicateurs dépendent de ceux-ci, tu dois également les modifier. Tout système réactif implique des cascades d'événements.

Si tu veux mettre tes indicateurs en cache, alors tu dois définir une politique d'invalidation et de mise à jour. Selon ce que tu veux faire ça peut être très simple et rapide (révisions à date fixe), ou très complexe et très lent (cascades).

La modification doit être aussi réactive qu'un ajout de données, ça veut que toute modification (que ce soit des données ou même de l'indicateur lui même) doit entraîner des modifications en cascades, il faut que tout soit en temps réel, le client attends avant-tout de la réactivité et un impact immédiat sur leurs accès. Après on peut fourber, et passer par un job queue pour faire le boulot 10/15min après...enfin on est pas non plus à la minute prés. D'ailleurs la modification d'un indicateur (je parle de sa définition, et non de ces valeurs), peut entraîner beaucoup plus de modification surtout s'il y a un historique de données volumineux, mais ça reste un cas très très rare.

Cela dit, encore une fois, 4000 collaborateurs ça veut dire une base de quelques Mo, ce qui est ridiculement petit. Ça peut être suffisant pour mettre un SGBD à genoux, surtout si tu l'utilises mal, par exemple en introduisant une gestion complexe de caches qui n'est pas forcément nécessaire, mais ce sont des volumes de données ridiculement faibles pour un traitement en mémoire sans SGBD. Dans ce cas les limites s'expriment en millions ou milliards. Et au pire des cas, ajouter dynamiquement des indexes ne sera pas plus compliqué qu'avec Redis ou MySQL.

On est d'accord la dessus, 4000 collaborateurs c'est pas grand chose. Après il ne faut pas oublier que le cas que je te présente ici n'est qu'une brique de l'application, ça représente peut être 15% du programme (15% très importante on est d'accord), et en quelques semaines/mois d'utilisation, la base de données atteint facilement 200 Mo juste avec 300 collaborateurs....Donc bon si demain, j'ai 10000 collaborateurs, le Go je le fais péter facile

Accessoirement tu n'as pas besoin de stocker tes 5 clients sur le même serveur : ça n'est sûrement pas significatif en termes de coûts et certains clients pourraient d'ailleurs vouloir une machine dédiée. La scalabilité c'est d'abord pouvoir découper son problème.

Par soucis de coût, pour le moment tout est stocké sur une seule machine, le programme n'en est qu'à ces débuts. On verra à l'avenir.

Edit : Du coup, j'ai commencé à regarder un peu le Go, et je vois beaucoup de développeurs passer à ce langage (C++ => Go, Java => Go, Node.js => Go), mais même si ça à l'air intéressant, j'ai envie quelques réserves sur sa pérennité. Car si je dois me former dessus, il faudra aussi que ça me serve pour mon avenir pro.