Quelle est la taille d'une table PostgreSQL?

127

Je travaille sur la conception d'un projet RoR pour mon entreprise, et notre équipe de développement a déjà eu un petit débat sur la conception, en particulier la base de données.

Nous avons un modèle appelé Messagequi doit être maintenu. C'est un très, très petit modèle avec seulement trois colonnes de base de données autres que l'identifiant, mais il y aura probablement BEAUCOUP de ces modèles lorsque nous passerons à la production. Nous examinons jusqu'à 1 000 000 d'insertions par jour. Les modèles ne seront jamais recherchés que par deux clés étrangères sur eux qui peuvent être indexées. De plus, les modèles n'ont jamais à être supprimés, mais nous n'avons pas non plus à les conserver lorsqu'ils ont environ trois mois.

Alors, ce que nous nous demandons, c'est si l'implémentation de cette table dans Postgres présentera un problème de performances important? Quelqu'un a-t-il de l'expérience avec de très grandes bases de données SQL pour nous dire si cela posera un problème ou non? Et si oui, quelle alternative devrions-nous choisir?

— Dylan Karr
source

avec une bonne couche de cache et une petite configuration dans PG, tout devrait bien se passer. Vous devez aborder les problèmes de performances au cas par cas et éviter de préoptimiser. Cela dit, le partitionnement et la réplication sont toujours d'excellentes options dont vous pouvez profiter une fois que vous rencontrez des goulots d'étranglement.

— Sam

Question connexe ici et ici .

— Erwin Brandstetter

Nous traitons environ 30 millions de messages par jour dans une base de données PostgreSQL de plus de 5 To, fonctionne très bien.

— Frank Heikens

voir aussi stackoverflow.com/questions/3132444/…

— rogerdpack

Pour info, je lisais postgresql.org/about aujourd'hui et j'ai remarqué qu'il dit que (en principe) le nombre de lignes dans une table est illimité.

— Al Chou

Réponses:

115

Les lignes par table ne seront pas un problème en soi.

Donc, environ 1 million de lignes par jour pendant 90 jours équivaut à 90 millions de lignes. Je ne vois aucune raison pour laquelle Postgres ne peut pas gérer cela, sans connaître tous les détails de ce que vous faites.

En fonction de la distribution de vos données, vous pouvez utiliser un mélange d'index, d'index filtrés et de partitionnement de table pour accélérer les choses une fois que vous voyez les problèmes de performances que vous pouvez ou non rencontrer. Votre problème sera le même sur tout autre RDMS que je connais. Si vous n'avez besoin que de 3 mois de conception de données dans un processus d'élagage des données, vous n'en avez plus besoin. De cette façon, vous aurez un volume constant de données sur la table. Votre chance, vous savez combien de données existera, testez-le pour votre volume et voyez ce que vous obtenez. Tester une table avec 90 millions de lignes peut être aussi simple que:

select x,1 as c2,2 as c3
from generate_series(1,90000000) x;

https://wiki.postgresql.org/wiki/FAQ

Limit   Value
Maximum Database Size       Unlimited
Maximum Table Size          32 TB
Maximum Row Size            1.6 TB
Maximum Field Size          1 GB
Maximum Rows per Table      Unlimited
Maximum Columns per Table   250 - 1600 depending on column types
Maximum Indexes per Table   Unlimited

— Kuberchaun
source

Je suis d'accord que 90 millions de lignes ne seront pas un problème pour PostgreSQL. Mais cela peut être un problème pour un ORM avec PostgreSQL. (Un ORM avec des dbms, en fait.)

— Mike Sherrill 'Cat Recall'

@ MikeSherrill'Catcall 'Bon point, j'étais juste concentré sur "Quelle est la taille d'une table PostgreSQL?"

— Kuberchaun

@yeyo: Parce que les ORM utilisent généralement beaucoup de requêtes pour obtenir des données qui pourraient être renvoyées avec seulement une ou deux. L'OP utilise Ruby on Rails.

— Mike Sherrill 'Cat Recall'

C'est un peu tard mais je pense que dans de nombreux cas (en particulier avec les rails / enregistrement actif), il est courant de supprimer complètement l'ORM de l'équation et d'écrire une chaîne SQL brute à interroger pour des raisons de performances. Ne laissez pas votre ORM prendre des décisions concernant les données à votre place! C'est un accessoire pas un indispensable.

— Stefan Theard

L'URL à propos citée dans l'URL n'indique pas ces limites actuellement - quelqu'un sait-il où elle est déplacée?

— Shorn

Une autre façon d'accélérer considérablement vos requêtes sur une table de plus de 100 millions de lignes consiste à regrouper la table sur l'index le plus souvent utilisé dans vos requêtes pendant les heures creuses. Nous avons une table avec> 218 millions de lignes et avons trouvé des améliorations 30X.

De plus, pour une table très volumineuse, c'est une bonne idée de créer un index sur vos clés étrangères.

— James Doherty
source

> pendant les heures creuses, regroupez le tableau sur l'index le plus souvent utilisé dans vos requêtes .... pouvez-vous expliquer comment cela se fait?

— espion

Oui, voici un exemple étape par étape: 1) Le tableau auquel je fais référence est appelé investissement dans cet exemple. 2) L'index le plus utilisé dans les requêtes est (bankid, record_date) Voici donc votre étape par étape: 1) psql -c "drop index investment_bankid_rec_dt_idx;" dbname 2) psql -c "créer un index investment_bankid_rec_dt_idx on investment (bankid, record_date);" 3) psql -c "cluster investment_bankid_rec_dt_idx sur investissement;" 4) videdb -d ccbank -z -v -t investissement Ainsi, aux étapes un et deux, nous supprimons l'indice et le recréons.

— James Doherty

Étape 3, nous créons le cluster, cela place essentiellement la table de base de données dans l'ordre physique de l'index, donc lorsque postgresql exécute une requête, il met en cache les lignes suivantes les plus probables. Étape 4, nous passons l'aspirateur dans la base de données pour réinitialiser les statistiques du planificateur de requêtes

— James Doherty