Différences

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

--- boardz:performances [2020/02/09 15:04]
admin [Montée en puissance : topologies d'implantation de Boardz2]
+++ boardz:performances [2020/04/07 11:07] (Version actuelle)
@@ Ligne 1: / Ligne 1: @@
+| {{ :avignon-universite.jpg?nolink|}} | {{ :blocks:logo-apl.png?nolink&220|}} |
 ===== Boardz2 : Performances =====
@@ Ligne 55: / Ligne 57: @@
 Chaque site a sa propre définition et son propre espace indexé d'enregistrements dans les tables du Boardz2. Cependant, plusieurs bases de données Boardz et plusieurs "installations physiques" du Boardz2 sont possibles sur une machine physique (ou une VM). Cependant, dans le cas d'installations "séparées", les données statistiques ne pourront pas être consolidées en multisite.
+=== Scalabilité verticale ===
+Le BoardZ2 est un ETR (Extract, Transform and Report) organisé par "processus" autour d'un modèle de stockage de données en base de données. Les différents processus (synchrones réguliers pour les alimentations et mesures calculées, asynchrone pour les consultations de résultats) sont techniquement indépendants les uns des autres (même s'il peuvent être "ordonnancés" par une "dernière date de donnée disponible"). Ainsi il est possible de répartir sur des systèmes ou processeurs différents :
+   - les diverses tâches d'alimentation ou de synchronisation de données. (E)
+   - les tâches de calcul sur les mesures et les "transformées de données" (T)
+   - les tâches d'assemblage et de construction de vues et de rapports (R)
+A plus long terme :
+   - 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]]

BoardZ Moodle Stat Project

Outils pour utilisateurs

Outils du site

Différences

Outils de la page