Calcul critique à haute mémoire/performance - Avis sur l'approche architecturale

Question

J'ai besoin d'un avis architectural et d'approches pour le problème suivant :

INTRO :

Nous disposons d'un tableau de ~4M rangées appelées Purchases .
W de ~5k rangées appelées Categories .
En outre, nous disposons d'un ~4k SubCategories .

Nous utilisons T-SQL pour stocker les données.

A ( pendant l'exécution ), le serveur reçoit une requête d'environ 10-15 N possibilités de paramètres. Sur la base des paramètres, nous prenons les achats, les trions par catégories et sous-catégories et effectuons quelques calcul.

Le processus de "calcul" comprend notamment le filtrage, trier, réorganiser les champs d'achats, soustraire les achats les uns des autres, ajouter d'autres achats à la liste. les uns avec les autres, ajouter d'autres achats les uns avec les autres, trouver des économies, etc...

Ce processus est spécifique à l'utilisateur, c'est pourquoi chaque utilisateur obtiendra des données différentes, en fonction de leur rôle.

Problème :

Ce processus prend environ 3 à 5 minutes et nous voulons le réduire. réduire.

Auparavant, ce processus s'effectuait en mémoire, sur le navigateur, par l'intermédiaire du logiciel webworkers (JS). Nous nous en sommes éloignés car la mémoire commençait à devenir la mémoire commençait à devenir très importante et que la plupart des navigateurs commençaient à échouer lors du chargement. Nous avons alors déplacé le service au serveur (NodeJS), qui a traité la demande à la volée, via des processus enfants. Raison d'être des processus enfants : le processus de calcul passe par une boucle "for" à propos de 5,000x fois (pour chaque catégorie) le "calcul" mentionné ci-dessus.

V distribuer le travail en #of child processes, ce qui nous a donné de meilleurs résultats. de meilleurs résultats, si nous utilisions au moins 16 cœurs ( 16 processus enfants ).

Le temps de traitement actuel est en baisse à environ 1,5-2 minutes, b mais nous voulons voir si nous avons de meilleures options.

Je comprends qu'il est difficile de comprendre pleinement nos objectifs sans voir de code, mais je pose la question de manière spécifique. Quels sont les moyens de faire du calcul sur des données semi-big au moment de l'exécution ?

Quelques réflexions que nous avons eues :

1. utiliser des tables SQL en mémoire et effectuer des calculs en SQL

2. utilisation des services azure batch

3. en utilisant des machines plus grandes ( ~ 32-64 cœurs, c'est peut-être notre meilleure chance si nous n'avons pas d'autres idées. Mais bien sûr, le coût augmente drastiquement, mais nous acceptons le fait que le coût augmentera).

4. entrer dans l'écosystème hadoop (ou d'autres écosystèmes big data)

d'autres faits utiles :

1. nos achats portent sur ~1GB (devenant un peu trop volumineux pour l'informatique en mémoire)
2. Nous pensons faire du pré-calcul et de la mise en cache sur redis pour avoir QUELQUES données prêtes pour le client ( nous allons utiliser leurs paramètres définis dans leur compte pour pré-calculer chaque jour, or les clients ont tendance à changer ces paramètres fréquemment, donc nous devons avoir un moyen efficace de traiter les données qui ne sont PAS mises en cache et pré-calculées ).

Si vous avez besoin de plus d'informations pour mieux comprendre notre dilemme, n'hésitez pas à commenter et je vous fournirai autant d'informations que possible. Il y aurait trop de code à coller ici pour que l'on comprenne bien les algorithmes, c'est pourquoi je veux essayer de présenter notre problème avec des mots, si possible.

Answer 1

Ne jamais décider d'une technologie avant d'être sûr du chemin critique du flux de travail.

Cela ne vous aidera jamais à atteindre un objectif (encore inconnu).

Ne connaissant pas le chemin critique du processus, personne ne peut calculer la vitesse de l'architecture, quelle qu'elle soit, que l'on vous "vend" agressivement ou que l'on vous "vend" à l'extérieur. juste - "recommander" de vous suivre en tant que "geek/nerdy/sexy/populaire" - tout ce que l'on veut entendre.

Que gagneriez-vous à prendre une telle décision prématurée ?

Il s'agit généralement d'un mélange de cauchemars liés à la budgétisation (coûts) et à la gestion de projets (échelles de temps glissantes) :

• des coûts supplémentaires (une nouvelle technologie signifie également de nouvelles compétences à acquérir, de nouveaux coûts de formation, de nouveaux délais pour que l'équipe se remodèle, se réajuste et évolue vers une utilisation mature de la nouvelle technologie à des niveaux de performance supérieurs à ceux des outils actuellement utilisés, etc, etc.)
• les risques de choisir une marque "populaire" qui, par ailleurs, ne présente aucun des pouvoirs superficiels que les textes de marketing promettaient (mais après avoir payé les coûts initiaux d'entrée, il n'y a pas d'autre moyen que d'assumer le risque de ne jamais atteindre l'objectif visé, peut-être en raison de bénéfices de performance surestimés, de coûts de transformation sous-estimés et de coûts de fonctionnement et d'entretien fortement sous-estimés).

Que diriez-vous si vous pouviez utiliser une solution ?
où les "meilleures options" restent vos options :

• vous pouvez commencer maintenant avec le code que vous utilisez actuellement sans qu'une seule ligne de code ne soit modifiée
• vous pouvez commencer maintenant avec un toujours VOTRE chemin graduel basé sur le libre arbitre de l'échelonnement des performances
• vous pouvez éviter tous les risques d'un (mauvais) investissement dans une "super-boîte" à coûts extra-primes, mais plutôt que de rester sur le côté sûr réutiliser des unités matérielles COTS bon marché et massivement testées en service, mises au point et éprouvées en termes de déploiement (machines courantes à double CPU + quelques Go, couramment utilisées par milliers dans les centres de données)
• vous pouvez augmenter le niveau de performance dont vous avez besoin, l'augmentation progressive des performances de traitement liées à l'unité centrale dès le départ, sans problème, jusqu'à quelques ~1k ~2k ~4k ~8k CPUs Si nécessaire - oui, jusqu'à plusieurs milliers d'unités centrales, que votre code de travail actuel peut immédiatement utiliser pour fournir le bénéfice immédiat de cette performance accrue et ainsi laisser à vos équipes les mains libres et plus de temps pour un travail approfondi sur les améliorations possibles de la conception et le remaniement du code pour des enveloppes de performance encore meilleures si le flux de travail actuel, ayant été "passivement" juste distribué de manière intelligente à ~1000, plus tard ~2000 ou ~5000 unités centrales (toujours sans un seul SLOC changé) ne suffit pas à lui seul ?
• vous pouvez passer à l'échelle supérieure - encore une fois, progressivement, en fonction des besoins, sans problème - jusqu'à ( presque ) n'importe quelle taille de la capacité in-RAM, que ce soit le jour 1 ~8TB, ~16TB, ~32TB, ~64TB , en sautant à ~72TB ou ~128TB l'année suivante, si nécessaire - tout cela en gardant votre budget toujours (presque) linéaire et entièrement ajusté par vos plans de performance et le trafic réel généré par les clients.
• vous pouvez isoler et concentrer vos efforts en matière de R&D non pas sur le (ré)-apprentissage de "nouvelles" plates-formes, mais purement dans le processus (re) -conception pour améliorer encore les performances du processus (qu'il s'agisse d'utiliser une stratégie de pré-calcul, lorsque cela est possible, ou d'utiliser des schémas plus intelligents entièrement en RAM pour des calculs ad hoc encore plus rapides, qui ne peuvent pas être pré-calculés de manière statique).

Que diraient les chefs d'entreprise d'une telle stratégie axée sur le retour sur investissement ?

Si l'on oblige le PDG et le directeur financier à "acheter" un nouveau jouet, c'est bien de pirater ceci aujourd'hui, cela demain, mais une telle approche ne rendra jamais les actionnaires plus heureux que de jeter (leur) argent dans la rivière du Nil.

Si l'on peut montrer un plan de projet efficace, où la plupart des connaissances et des compétences sont concentrées sur des objectifs alignés sur l'activité, tout en protégeant le retour sur investissement, cela rendrait votre PDG, votre directeur financier et, je le garantis, tous vos actionnaires très heureux, n'est-ce pas ?

Alors, quelle est votre décision ?

Answer 2

Ce sujet n'est pas vraiment nouveau mais juste au cas où... D'après mon expérience, je dirais que votre base de données T-SQL pourrait être votre goulot d'étranglement.

Avez-vous mesuré la performance de vos requêtes SQL ? Que calculez-vous du côté du serveur SQL ? du côté de Node.js ?

Un bon début serait de mesurer le temps de réponse de vos requêtes SQL, de réorganiser vos requêtes, de travailler sur les index et d'étudier le fonctionnement du moteur de requêtes de votre base de données si nécessaire. Parfois, un petit réglage des paramètres de la base de données fait l'affaire !