Base de données de 100 téraoctets sur PostgreSQL sans partitionnement

9

Est-il réaliste de configurer une base de données de 100 To (environ 90 To en fait) sur PostgreSQL sans partage de données entre plusieurs nœuds? Existe-t-il des exemples de réussite / exemples de configurations similaires?

database postgresql voidlizard
la source
4
J'imagine que cela dépend de votre charge de travail. Comment les données sont-elles distribuées et comment seront-elles interrogées? De quel temps de réponse avez-vous besoin?
Frank Farmer
Eh bien, le profil de charge peut être décrit comme des insertions fréquentes (environ 50K par seconde en pointe), des sélections relativement rares (plage de lignes par utilisateur et horodatage). Les données peuvent être facilement partagées / partitionnées par l'utilisateur et la date / l'horodatage

Réponses:

9

50 000 écritures par seconde qui doivent être absorbées sont généralement plus qu'un défi. Même dans les benchmarks synthétiques avec des insertions assez simples, les limites de PostgreSQL ont tendance à dépasser environ 10 K / s - et là, vous n'avez même pas une si grosse bête en termes de taille de la base de données.

De plus, le système d'E / S pour ce nœud PostgreSQL unique sera intéressant, car même avec RAID 10 et en supposant que les insertions de 50K vont être égales à seulement 50K IOPS (ce qui est probablement faux, mais cela dépend de votre schéma de base de données et de vos indices ), vous allez avoir besoin d'environ une centaine de disques associés à une très bonne matrice qui vous évite d'acheter plusieurs centaines de disques pour effectuer ces écritures en temps opportun.

Si le partage est facile et que vous vous attendez à une charge d'écriture aussi énorme, optez pour le partage. Les écritures peuvent être très difficiles à mettre à l'échelle.

pfo
la source
Se mettre d'accord. Il s'agit du domaine d'un système de type ExaData. C'est triste, obtenir des IOPS 50k est assez trivial ces jours-ci avec SSD - otoh ceux-ci vont coûter cher. Je m'attendrais à un budget à 7 chiffres plus important pour le matériel, y compris un SAN de milieu de gamme à haut de gamme.
TomTom
Oui, ExaData est une option si vous voulez utiliser la "pile de solutions intégrée verticalement", ce qui n'est probablement pas si mal compte tenu des exigences.
pfo
Ouais. Il y a de sérieux avantages pour quelque chose comme ça, à la fois, 100 To et 50 000 iops ne crient pas vraiment "bon marché" ´. Exadata fait quoi - 1 million d'IOPS lorsqu'il est entièrement chargé avec SSD?
TomTom
2
Pour ajouter à ces commentaires, je pense qu'étant donné le budget nécessaire pour obtenir ce volume de données avec ce volume d'inserts, je serais tenté d'utiliser un moteur SQL payant, ce sera un petit pourcentage du budget global et vous 'aurai un bien meilleur support.
Chopper3
Je suis complètement d'accord. Au moment où votre budget pour un SAN atteint quelques centaines de milliers, beaucoup d'évaluations changent.
TomTom
1

C'est réaliste et ça marchera. Les performances dépendent en grande partie de la quantité de RAM dont vous disposez. Plus la RAM est grande, plus le cache est grand et plus PostgreSQL peut mettre en cache les données avant de les décharger sur le disque.

PostgreSQL écrit des données dans le cache et décharge le cache de temps en temps. Ainsi, 50 000 INSERT par seconde ne seront pas traduits en 50 000 IOPS. Ce sera beaucoup moins, car il regroupera les enregistrements et les enregistrera tous en même temps.

Une base de données aussi volumineuse n'est pas un problème si la majorité du travail est INSÉRER. PostgreSQL devra changer les index ici et là, mais c'est vraiment une tâche facile. Si vous aviez beaucoup de SELECT sur une base de données de cette taille, vous auriez vraiment besoin de partager.

J'ai déjà travaillé sur une base de données Oracle (Oracle 10g) avec 400 To sur un serveur de 16 Go, une seule instance. La charge de travail de la base de données était également des INSERT principaux, donc quelques SELECT par jour et des millions d'INSERT par jour. La performance était loin d'être un problème.

ThoriumBR
la source
1

À 100 To, vous avez des défis importants. Que cela fonctionne pour vous ou non dépend de la façon dont vous souhaitez les résoudre.

  1. Vous avez besoin de moyens suffisants pour absorber la charge d'écriture. Cela dépend de la charge d'écriture. Mais avec un stockage suffisamment impressionnant, il peut être résolu. La vitesse est un gros problème ici. De même, l'accès en lecture doit être examiné attentivement.

  2. La plupart des bases de données ne se composent pas d'un tas de petites tables mais en ont souvent une ou deux très grandes, qui peuvent atteindre jusqu'à la moitié de la taille de la base de données. PostgreSQL a une limite stricte de 32 To par table. Après cela, le type tid manque de compteurs de pages. Cela pourrait être géré par une construction personnalisée de PostgreSQL ou par le partitionnement de table, mais c'est un défi sérieux qui doit être abordé dans un premier temps.

  3. PostgreSQL a de réelles limites dans la quantité de RAM qu'il peut utiliser pour diverses tâches. Donc, avoir plus de RAM peut ou non vous aider au-delà d'un certain point.

  4. Sauvegardes .... Les sauvegardes sont intéressantes à cette échelle. La base de données de 60 To que je connais devait utiliser des sauvegardes instantanées fs, puis simuler les sauvegardes pour barman pour l'archivage wal. Ces fausses sauvegardes étaient des proxys pour les sauvegardes instantanées fs. Comme je l'ai dit "Ce ne sont pas de fausses sauvegardes. Ce sont des sauvegardes alternatives!"

Il y a des gens avec des bases de données qui approchent de cette gamme. J'ai rencontré au moins une personne qui travaillait pour une banque aux Pays-Bas qui avait une base de données PostgreSQL de 60 To. Cependant, cela dépend vraiment, vraiment de votre charge de travail et de la taille n'est pas le problème en soi.

Chris Travers
la source