Le Post Infeeny

Les articles des consultants et experts Infeeny

[TAB] Near Real-Time Analytics with xVelocity (without DirectQuery)

Speaker : Marco Russo – Niveau : 300

Il s’agit de montrer comment on peut pousser le moteur « xVelocity » à faire du « quasi » temps réel.

On commence par une discussion sur ce que l’on entend par le « quasi » temps réel. Il existe plusieurs réponses qui dépendent des utilisateurs et du contexte (heures, minutes, secondes ?)

On poursuit par une présentation du scénario de la démonstration. Il s’agit d’une société de pari où l’on veut connaître le plus rapidement possible les paris et les gagnants (temps de réponses inférieur à 1 minute)

Points critiques :

–          Le temps de « process » doit être rapide

–          Les données doivent accessibles pendant le rafraîchu

–          On doit pouvoir prévoir le temps de latence

–          Les temps de réponses des requêtes doivent être court.

Bien sûr dans cette démonstration, on ne veut pas utiliser le mode « DirectQuery » qui présente certaines limites notamment en termes de performances.

Il y a 2 étapes à optimiser dans le chargement :

  • Chargement des données
  • Chargement des autres structures : colonnes calculés, indexes, relation et hiérarchies

Chargement des données

On détaille les éléments à prendre en compte avant de mettre en place notre « quasi » temps réel (gestion des transactions, de la mémoire).

L’idée est de réduire le temps de chargement (charger uniquement les tables nécéssaires, etc.)

On peut charger en mode « push » (« process » à la demande) ou en mode « pull » (SSIS, C#).

La solution proposée ici est un chargement incrémental (« Process Add ») afin de charger les données récentes, toutes les minutes, dans une nouvelle partition.  Puis, en fin de journée, on fait un (« Process Data ») pour fusionner la nouvelle partition avec l’ancienne (pour cela, on utiliser l’AMO)

Chargement des autres structures

On va essayer d’optimiser le chargement des autres structures sachant que ces entités sont « processer » au niveau table. Pour cela, plusieurs pistes :

  • Essayer de limiter au maximum les colonnes calculées
  • Eviter de trier les colonnes
  • Limiter les relations même si elles sont importantes pour les performances
  • Supprimer les hiérarchies

Une dernière remarque sur le verrou placé sur le cube après le chargement (nécessaire pour remplacer les anciennes données par les nouvelles) et qui peut aboutir à rejeter certains requêtes.

En conclusion, une très bonne session donnant plusieurs pistes afin d’optimiser le chargement de nos données  dans un modèle tabulaire.

Julien

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :