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 ?