2010-03-14 4 views
2

J'ai une énorme base de données qui contient des paires de nombres (A, B), chacune allant de 0 à 10 000 et stockée comme des flottants.PostgreSQL: Auto-partitionner une table

par exemple,

(1, 9984.4), (2143.44, 124.243), (0.55, 0), ... 

Depuis la table PostgreSQL stocke ces paires qui ont grandi assez grand, j'ai décidé de partition it into inheriting sub-tables. J'ai l'intention de créer 100 tables de ce type, chacune stockant une gamme de 1000x1000.

Le problème est que ces nombres ont tendance à venir en gros morceaux de nombres proches. Cela signifie qu'à l'avenir, certaines tables seront presque vides et d'autres détiendront une très grande partie de la base de données. Malheureusement, la distribution des futures paires est encore inconnue.

Je cherche un moyen de repartitionner automatiquement ma table. Cela signifie que si une certaine sous-table contient plus d'un nombre spécifique de paires, elle sera automatiquement partitionnée en quatre sous-sous-tables, et ainsi de suite.

Mes questions sont les suivantes:

  • est le partitionnement récursif et l'héritage possible dans PostgreSQL 8.3? Les index et les plans de requête le comprendront-ils?
  • Quelle est la meilleure façon de diviser une sous-table une fois qu'elle est devenue trop grande? Je tiens à souligner que ce n'est pas une base de données en direct, donc un temps d'arrêt de quelques heures chaque semaine est tout à fait acceptable.
  • MISE À JOUR: Je pourrais diviser les tables héritantes en quatre tables qui remplaceraient la table d'origine (c'est-à-dire hériter directement de la table principale). J'éviterai d'avoir plus d'un niveau d'héritage, mais j'en aurai des milliers si les tables héritent directement d'une table. Quels sont les avantages et les inconvénients de cette approche?

Merci à l'avance,

Adam

+0

Qu'est-ce que "grand" et quel problème tentez-vous de résoudre? Le partitionnement est génial, mais seulement quand cela a du sens pour vos instructions SELECT. Il peut également être utile pour supprimer toutes les données dans le tableau complet, mais ce n'est pas quelque chose que vous faites tous les jours. –

+0

a. Des centaines de millions d'enregistrements; b. Il est en effet destiné aux requêtes SELECT, et cela faciliterait vraiment la division de la base de données entre plus d'un ordinateur dans le futur. –

Répondre

2

D'abord, si les tables sont déjà grandes, vous êtes sûr que la distribution n'est pas fiable pour les estimations futures? Un histogramme fait aujourd'hui serait-il inutile?

Je pense que même si l'héritage récursif est possible, il ajoute une complexité inutile au modèle, à la fois pour la maintenance et le planificateur. Lorsque vous le partitionnez à 100 tables, je pense que vous allez générer les partitions et insérer/mettre à jour les règles/déclencheurs automatiquement.

L'approche la plus simple peut être de copier des données d'une partition vers une table temporaire, de les supprimer, de créer 4 partitions à sa place et de recopier les données. Je ne pense pas que cette opération serait plus difficile que le partitionnement récursif.

Vous pouvez également demander à des personnes dans les listes de diffusion PostgreSQL. Ils sont les meilleurs experts que vous pouvez éventuellement obtenir, y compris les développeurs originaux.

+0

+1 pour les conseils et la référence à la liste de diffusion PostgreSQL –

Questions connexes