Différences

Ci-dessous, les différences entre deux révisions de la page.

--- boardz:performances [2020/02/09 14:14] – [Montée en puissance : topologies d'implantation de Boardz2] admin
+++ boardz:performances [2026/01/13 08:03] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
+| {{ :avignon-universite.jpg?nolink|}} | {{ :blocks:logo-apl.png?nolink&220|}} |
 ===== Boardz2 : Performances =====
@@ Ligne 66: / Ligne 68: @@
    - des tâches de production et de distribution documentaire
    - des tâches d'alertes sur les indicateurs et données.
+La répartition de ces différentes tâches de calcul sur des unités système différentes permet une certaine montée en puissance et une répartition de l'effort de calcul "PHP" du boardz.
+En l'état du projet, la scalabilité verticale du stockage de données lui-même (base de données Boardz) n'est pas encore évaluée. Il est possible cependant de dévoiler quelques pistes plausibles d'architecture pour adresser cette scalabilité :
+Boardz2 stocke quatre types de données :
+   * Les données de configuration internes : elles décrivent les objets du Boardz et leur assemblage. Ces données sont statiques en cours d'exploitation.
+   * Les données de "modèle" ou de référence" : provenant des applicatifs, ces données sont relativement statiques en cours d'exploitation, même si elles doivent être régulièrement resynchronisées à partir des applicatifs qu''elles décrivent.
+   * Les données "captées", soit des alimentations (feeders), soit à partir de mesures directes (measurement) et de leurs source de données (datasources). Ces données sont dynamiques, elles arrivent en flux continu à partir des applicatifs en exploitation.
+   * Les données "transformées", issues de calculs sur les mesures ou les indicateurs, et constituant des "caches" locaux de valeurs calculées intermédiaires, directement consultables par les vues et les rapports. Ces données sont dynamiques et "suivent" (data-tracking) la réception des données 'captées".
+La gestion de la croissance des tailles de stockages pour ces données peut être adressée :
+   * par segmentation du stockage pour des instances séparées (réduisant la taille de stockage globale du "tablespace" pour chaque type de données)
+   * par répartition des deux derniers types de données (alimentation et données transformées) dans deux unités de bases de données distinctes.
+Dans le premier cas, l'avantage vient de la réduction de l'arité des index dans chaque table, accélérant le calcul des sélections de données, mais en rendant difficile la consolidation de données. Dans le deuxième cas, la consolidation de données reste plus simple et accessible, mais les temps de calcul liés à la taille des index ne sera pas globalement améliorée.
 [[:start|Revenir au sommaire]]