Division / fusion SQL de partitions de table: quelle est la meilleure approche à mettre en œuvre?

Question

Microsoft dans son entrée à propos de MSDN à propos de modification des partitions SQL 2005, voici quelques approches possibles:

• Créez une nouvelle table partitionnée avec la fonction de partition souhaitée, puis insérez les données de l'ancienne table dans la nouvelle table à l'aide d'une instruction INSERT INTO ... SELECT FROM.
• Créer un index clusterisé partitionné sur un segment de mémoire
• Supprimez et reconstruisez un index partitionné existant à l'aide de l'instruction CREATE INDEX Transact-SQL avec la clause DROP EXISTING = ON.
• Effectuez une séquence d'instructions ALTER PARTITION FUNCTION.

Vous avez une idée du moyen le plus efficace pour une base de données à grande échelle (des millions d’enregistrements) avec des partitions basées sur les dates des enregistrements (comme des partitions mensuelles), où les données s’étalent sur 1 à 2 ans?

De plus, si j’accède principalement aux informations récentes (pour les lire), est-il judicieux de conserver une partition pendant les X derniers jours, et le reste des données sera une autre partition? Ou est-il préférable de partitionner également le reste des données (pour tout accès aléatoire basé sur une plage de dates)?

Answer 1

Je recommanderais la première approche - créer une nouvelle table partitionnée et y insérer des éléments - car elle vous offre le luxe de comparer vos anciennes et nouvelles tables. Vous pouvez tester les plans de requête par rapport aux deux styles de table et voir si vos requêtes sont effectivement plus rapides avant de passer à la nouvelle conception de table. Vous constaterez peut-être qu'il n'y a pas d'amélioration, ou vous pouvez essayer plusieurs fonctions / schémas de partitionnement avant de choisir votre résultat final. Vous souhaiterez peut-être partitionner sur autre chose que la plage de dates - la date n'est pas toujours efficace.

J'ai réalisé le partitionnement avec des tables de 300 à 500 m de lignes avec des données réparties sur 6 à 7 ans, et cette approche d'insertion de table était celle que j'ai trouvée la plus utile.

Vous avez demandé comment partitionner. La meilleure solution consiste à essayer de concevoir vos partitions de manière à ce que vos requêtes atteignent une seule partition. Si vous avez tendance à concentrer les requêtes sur les données récentes ET si vous filtrez sur ce champ de date dans vos clauses where, alors oui, créez une partition séparée pour les X derniers jours.

Sachez que vous devez spécifier le champ partitionné dans votre clause where. Si vous ne spécifiez pas ce champ, la requête touchera probablement toutes les partitions pour obtenir les données. À ce stade, vous ne obtiendrez aucun gain de performances.

J'espère que ça aide! J'ai fait beaucoup de partitionnement, et si vous voulez poster quelques exemples de structures de table & amp; requêtes, cela vous aidera à obtenir une meilleure réponse pour votre environnement.