Tests des partitions

l’adresse https://www.itpro.fr Club abonnés Dans la suite de cet article, je résume les tests et certains résultats importants.

J’ai créé six cubes de structure identique, avec un taux d’agrégation de 30 pour cent et différents types de partitions. Je souhaitais partitionner en fonction des membres des dimensions Time et Occupant_ Severity (comme le montre la figure 2), et les requêtes de test du listing 2 et du listing 3 recherchent ces membres, de telle sorte qu’elles puissent y accéder sans analyse ou avec une analyse accélérée. Le tableau 1 décrit les tranches de données de partitionnement des six cubes de test. J’ai attribué aux cubes des noms qui reflètent leurs dimensions de partitionnement et le nombre total de partitions.

Pour étudier l’incidence sur les cubes partitionnés du nombre et de la vitesse des processeurs, des E/S disque et de la mémoire physique, j’ai répété les mêmes tests sur six serveurs Dell distincts. Le tableau 2 énumère les spécifications relatives à ces serveurs, en partant du serveur haut de gamme le plus performant au serveur d’entrée de gamme le moins performant en termes de ressources matérielles. High1, High2 et High3 constituent des serveurs de production haut de gamme ; Low1 et Low2 sont des ordinateurs de bureau et Low3 est un portable (que j’ai utilisé en tant que serveur aux fins des tests). Chaque test exécute le listing 2 et le listing 3 à partir du client Low2 sur chaque cube de test des six serveurs.

Tous les tests mesuraient les temps de réponse des deux listings. (Pour lire les résultats de mes tests pour le listing 3, consultez l’article « Cube-Partitioning Tests » www.itpro.fr Club abonnés.) La figure 3 montre les performances du listing 2 sur l’ensemble des serveurs. Mes conclusions concernant ce listing sont les suivantes :

• Les serveurs haut de gamme (avec plusieurs processeurs peu rapides) ont été moins performants que les serveurs d’entrée de gamme (avec un processeur rapide), indépendamment du partitionnement des cubes. Les performances dépendent plus de la vitesse du processeur que de leur nombre, de la vitesse des disques, ou de la quantité de mémoire.
• Un partitionnement efficace multiplie par un facteur 5 à 10 la vitesse d’exécution de la requête par rapport à la partition par défaut, en particulier avec des processeurs plus lents.
• Les requêtes comportant des membres calculés, telles que celles du listing 2, sont tributaires du processeur.
• Le partitionnement en fonction des tranches de données interrogées, ce que j’ai fait sur les cubes de test Year_Severity31 et PartitionYear_ Severity7, procure les meilleures performances.
• Un partitionnement en fonction des membres interrogés (par ex., en fonction des six membres de la dimension Severity et des trois membres du niveau Year de la dimension Time) a empêché les analyses séquentielles.
• La limitation de la taille des partitions en excluant les membres non interrogés fréquemment (par ex., [Partition Year].[1], qui inclut les années 1985 à 1996) n’empêche pas l’analyse séquentielle, mais accélère très nettement celleci.
• Les résultats des tests (disponibles dans l’article « Cube- Partitioning Tests) montrent qu’un niveau d’agrégation supérieur à 5 pour cent n’a aucune incidence sur les performances, ce qui prouve mon hypothèse selon laquelle des niveaux d’agrégation élevés constituent une perte de temps et d’efforts.