Pour l'instant, Urungi attaque directement la base à laquelle on connecte le layer. Pas d'intermédiaire transparent et géré par Urungi.
Donc la base de prod ou une réplication. Pour nos clients petits, on va attaquer la base de prod, pour les gros, on va monter un serveur de réplication de la base. On n'a pas besoin de traiter des données "chaudes", quasi que du "froid" (voire tiède).
Dans une bibliothèque, le catalogue ne bouge pas fondamentalement d'un jour à l'autre, ni les engagements budgétaires ou les inscriptions. Donc c'est acceptable d'avoir des données "de la veille".
Ou bien on fera un master/slave et on interrogera le slave.
Et dans la roadmap il y a "mise en cache des résultats", qui permettra d'alléger encore la charge des serveurs de prod.
On a conscience que c'est une limite d'Urungi à ce jour, et que c'est ce qui fait que ça ne peut pas (encore) rivaliser avec des outils de BI.
Autre limitation du même accabit : on ne peut pas agréger de manière transparente plusieurs sources de données.
Mais bon c'est le début, ça va évoluer avec les 15 000 développeurs qui vont rejoindre le projet ;)
[^] # Re: Base infocentre ?
Posté par Paul POULAIN (site web personnel, Mastodon) . En réponse à la dépêche Publication d’Urungi, tableaux de bord, statistiques, Business Intelligence. Évalué à 5.
Pour l'instant, Urungi attaque directement la base à laquelle on connecte le layer. Pas d'intermédiaire transparent et géré par Urungi.
Donc la base de prod ou une réplication. Pour nos clients petits, on va attaquer la base de prod, pour les gros, on va monter un serveur de réplication de la base. On n'a pas besoin de traiter des données "chaudes", quasi que du "froid" (voire tiède).
Dans une bibliothèque, le catalogue ne bouge pas fondamentalement d'un jour à l'autre, ni les engagements budgétaires ou les inscriptions. Donc c'est acceptable d'avoir des données "de la veille".
Ou bien on fera un master/slave et on interrogera le slave.
Et dans la roadmap il y a "mise en cache des résultats", qui permettra d'alléger encore la charge des serveurs de prod.
On a conscience que c'est une limite d'Urungi à ce jour, et que c'est ce qui fait que ça ne peut pas (encore) rivaliser avec des outils de BI.
Autre limitation du même accabit : on ne peut pas agréger de manière transparente plusieurs sources de données.
Mais bon c'est le début, ça va évoluer avec les 15 000 développeurs qui vont rejoindre le projet ;)