Mise en cache des données de reporting dans la même base de données de transactions par rapport à l'utilisation d'un entrepôt de données
P粉511749537
P粉511749537 2024-02-26 19:20:23
0
1
364

Nous disposons d'une solution SaaS où chaque locataire dispose de sa propre base de données MySQL. Je conçois maintenant un tableau de bord pour ce système SaaS et cela nécessite des graphiques analytiques. Pour obtenir les données nécessaires à la cartographie, nous pouvons interroger en temps réel les données de transactions de chaque locataire à partir de sa base de données. et obtenez des graphiques mis à jour sans mauvaises performances puisque le volume de données n'est pas si important jusqu'à présent. Cependant, comme le volume de données continuera de croître, nous avons décidé de séparer les données analytiques et les données transactionnelles pour chaque entreprise. Nous récupérerons les données analytiques des graphiques en arrière-plan, les sauvegarderons/les mettrons en cache et les mettrons à jour régulièrement. Ma question est :

  • Quels sont les bonnes questions ou facteurs que nous devrions prendre en compte avant de décider si nous devons inclure l'entreposage de données et la modélisation des données dès le départ, ou simplement mettre en cache les données analytiques des graphiques générés par l'API dans les colonnes JSON dans de nouveaux tableaux pour chaque locataire ? Base de données MYSQL.

P粉511749537
P粉511749537

répondre à tous(1)
P粉759451255

Au lieu d'entrer dans des millions de lignes dans un tableau « de faits », créez et maintenez un tableau récapitulatif, puis récupérez les données. Il peut fonctionner 10 fois plus vite.

Cela nécessite un changement de code en raison des tables supplémentaires, mais cela peut en valoir la peine.

Tableau récapitulatif

En d’autres termes, si l’ensemble de données devient supérieur à X, un tableau récapitulatif est la meilleure solution. La mise en cache n'aidera pas. Le matériel ne suffit pas. JSON ne fait que gêner.

Construire des graphiques pour une année sur la base d'une année de points de données (un par seconde) est lent et inutile. Il est beaucoup plus logique de construire un graphique annuel basé sur des sous-totaux quotidiens.

Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal
À propos de nous Clause de non-responsabilité Sitemap
Site Web PHP chinois:Formation PHP en ligne sur le bien-être public,Aidez les apprenants PHP à grandir rapidement!