Entreposage de données - Stratégie de partitionnement

Le partitionnement est fait pour améliorer les performances et faciliter la gestion des données. Le partitionnement aide également à équilibrer les diverses exigences du système. Il optimise les performances matérielles et simplifie la gestion de l'entrepôt de données en partitionnant chaque table de faits en plusieurs partitions distinctes. Dans ce chapitre, nous aborderons différentes stratégies de partitionnement.

Pourquoi est-il nécessaire de partitionner?

Le partitionnement est important pour les raisons suivantes -

Pour une gestion facile,
Pour aider à la sauvegarde / restauration,
Pour améliorer les performances.

Pour une gestion facile

La table de faits dans un entrepôt de données peut atteindre des centaines de gigaoctets. Cette énorme table de faits est très difficile à gérer comme une seule entité. Par conséquent, il a besoin d'un partitionnement.

Pour assister la sauvegarde / la restauration

Si nous ne partitionnons pas la table de faits, nous devons charger la table de faits complète avec toutes les données. Le partitionnement nous permet de charger uniquement autant de données que nécessaire sur une base régulière. Il réduit le temps de chargement et améliore également les performances du système.

Note- Pour réduire la taille de la sauvegarde, toutes les partitions autres que la partition actuelle peuvent être marquées en lecture seule. Nous pouvons alors mettre ces partitions dans un état où elles ne peuvent pas être modifiées. Ensuite, ils peuvent être sauvegardés. Cela signifie que seule la partition actuelle doit être sauvegardée.

Pour améliorer les performances

En partitionnant la table de faits en ensembles de données, les procédures de requête peuvent être améliorées. Les performances des requêtes sont améliorées car désormais la requête analyse uniquement les partitions pertinentes. Il n'est pas nécessaire de scanner toutes les données.

Partitionnement horizontal

Une table de faits peut être partitionnée de différentes manières. Dans le partitionnement horizontal, nous devons garder à l'esprit les exigences de gestion de l'entrepôt de données.

Partitionnement par temps en segments égaux

Dans cette stratégie de partitionnement, la table de faits est partitionnée sur la base de la période. Ici, chaque période représente une période de rétention importante au sein de l'entreprise. Par exemple, si l'utilisateur demandemonth to date datail convient alors de partitionner les données en segments mensuels. Nous pouvons réutiliser les tables partitionnées en supprimant les données qu'elles contiennent.

Partition par temps en segments de différentes tailles

Ce type de partition est effectué là où les données anciennes sont rarement consultées. Il est implémenté comme un ensemble de petites partitions pour les données relativement actuelles, une plus grande partition pour les données inactives.

Points à noter

Les informations détaillées restent disponibles en ligne.
Le nombre de tables physiques est maintenu relativement petit, ce qui réduit les coûts d'exploitation.
Cette technique convient lorsqu'un mélange de données plongeant dans l'histoire récente et l'exploration de données à travers l'histoire entière est nécessaire.
Cette technique n'est pas utile lorsque le profil de partitionnement change régulièrement, car le repartitionnement augmentera le coût de fonctionnement de l'entrepôt de données.

Partition sur une dimension différente

La table de faits peut également être partitionnée sur la base de dimensions autres que le temps telles que le groupe de produits, la région, le fournisseur ou toute autre dimension. Prenons un exemple.

Supposons qu'une fonction de marché ait été structurée en départements régionaux distincts comme sur un state by statebase. Si chaque région souhaite interroger les informations capturées dans sa région, il serait plus efficace de partitionner la table de faits en partitions régionales. Cela accélérera les requêtes, car il ne nécessite pas d'analyser les informations non pertinentes.

Points à noter

La requête n'a pas à analyser les données non pertinentes, ce qui accélère le processus de requête.
Cette technique n'est pas appropriée lorsque les dimensions sont peu susceptibles de changer à l'avenir. Donc, il vaut la peine de déterminer que la dimension ne change pas à l'avenir.
Si la dimension change, la table de faits entière devra être repartitionnée.

Note - Nous vous recommandons d'effectuer la partition uniquement sur la base de la dimension temporelle, sauf si vous êtes certain que le regroupement de dimensions suggéré ne changera pas pendant la durée de vie de l'entrepôt de données.

Partition par taille de table

Lorsqu'il n'y a pas de base claire pour partitionner la table de faits sur n'importe quelle dimension, alors nous devrions partition the fact table on the basis of their size.Nous pouvons définir la taille prédéterminée comme un point critique. Lorsque la table dépasse la taille prédéterminée, une nouvelle partition de table est créée.

Points à noter

Ce partitionnement est complexe à gérer.
Il nécessite des métadonnées pour identifier les données stockées dans chaque partition.

Partitionnement des dimensions

Si une dimension contient un grand nombre d'entrées, il est alors nécessaire de partitionner les dimensions. Ici, nous devons vérifier la taille d'une dimension.

Considérez une conception de grande taille qui change avec le temps. Si nous devons stocker toutes les variations afin d'appliquer des comparaisons, cette dimension peut être très grande. Cela affecterait certainement le temps de réponse.

Partitions à la ronde

Dans la technique du round robin, lorsqu'une nouvelle partition est nécessaire, l'ancienne est archivée. Il utilise des métadonnées pour permettre à l'outil d'accès utilisateur de faire référence à la partition de table correcte.

Cette technique facilite l'automatisation des fonctions de gestion des tables au sein de l'entrepôt de données.

Partition verticale

Partitionnement vertical, divise les données verticalement. Les images suivantes montrent comment le partitionnement vertical est effectué.

Le partitionnement vertical peut être effectué des deux manières suivantes -

Normalization
Division de ligne

Normalisation

La normalisation est la méthode relationnelle standard d'organisation de la base de données. Dans cette méthode, les lignes sont réduites en une seule ligne, ce qui réduit l'espace. Jetez un œil aux tableaux suivants qui montrent comment la normalisation est effectuée.

Tableau avant normalisation

Product_id	Qté	Valeur	date_vente	Store_id	Nom du magasin	Emplacement	Région
30	5	3,67	3-août-13	16	ensoleillé	Bangalore	S
35	4	5,33	3-sept.-13	16	ensoleillé	Bangalore	S
40	5	2,50	3-sept.-13	64	san	Bombay	W
45	sept	5,66	3-sept.-13	16	ensoleillé	Bangalore	S

Tableau après normalisation

Store_id	Nom du magasin	Emplacement	Région
16	ensoleillé	Bangalore	W
64	san	Bombay	S

Product_id	Quantité	Valeur	date_vente	Store_id
30	5	3,67	3-août-13	16
35	4	5,33	3-sept.-13	16
40	5	2,50	3-sept.-13	64
45	sept	5,66	3-sept.-13	16

Division de ligne

Le fractionnement de lignes a tendance à laisser une carte univoque entre les partitions. Le motif de la division des rangées est d'accélérer l'accès à une grande table en réduisant sa taille.

Note - Lors de l'utilisation du partitionnement vertical, assurez-vous qu'il n'est pas nécessaire d'effectuer une opération de jointure majeure entre deux partitions.

Identifier la clé de la partition

Il est très important de choisir la bonne clé de partition. Le choix d'une mauvaise clé de partition conduira à réorganiser la table de faits. Prenons un exemple. Supposons que nous voulions partitionner la table suivante.

Account_Txn_Table
transaction_id
account_id
transaction_type
value
transaction_date
region
branch_name

Nous pouvons choisir de partitionner sur n'importe quelle clé. Les deux clés possibles pourraient être

region
transaction_date

Supposons que l'entreprise soit organisée en 30 régions géographiques et que chaque région ait un nombre différent de succursales. Cela nous donnera 30 partitions, ce qui est raisonnable. Ce partitionnement est suffisant car notre capture des exigences a montré qu'une grande majorité des requêtes sont limitées à la propre région d'activité de l'utilisateur.

Si nous partitionnons par transaction_date au lieu de region, la dernière transaction de chaque région sera dans une partition. Désormais, l'utilisateur qui souhaite consulter des données dans sa propre région doit interroger plusieurs partitions.

Par conséquent, il vaut la peine de déterminer la bonne clé de partitionnement.