PostgreSQL pour les transactions à volume élevé et pour l'entreposage de données

Je suis assez nouveau sur PostgreSQL, je n'ai jamais fait de déploiement important en l'utilisant auparavant. Mais, j'ai une bonne expérience dans les solutions d'entreprise et je veux essayer d'appliquer une partie de ce que j'ai appris en utilisant PostgreSQL.

J'ai un site qui est dimensionné pour gérer un grand nombre de données et de trafic. L'infrastructure sera construite à l'aide d'Amazon (AWS) à l'aide d'instances EC2 et de volumes EBS.

La conception devrait avoir deux bases de données, une base de données transactionnelle principale et un entrepôt de données pour gérer l'analyse et les rapports.

Base de données transactionnelle principale

sera utilisé pour le site Web en direct, le site est construit sur plusieurs nœuds pour étendre les utilisateurs simultanés. Principalement, nous exigeons que la base de données pour ce cas soit extrêmement rapide dans les opérations de lecture, nous nous attendons à> 100 Go de données avec une croissance annuelle de 30%. À ce stade, nous prévoyons d'utiliser deux serveurs EC2 ( et d'en ajouter plus tard si nécessaire ).

ma question, quelle est la configuration recommandée pour les exigences ci-dessus? De plus, existe-t-il un moyen de gérer le partitionnement des tables et des volumes? existe-t-il des recommandations pour l'utilisation de la configuration AWS?

Base de données d'entrepôt de données

Sera utilisé principalement pour capturer toutes les données de la base de données transactionnelle principale dans la dimension temporelle. ainsi, même les enregistrements supprimés de la base de données principale seront capturés dans le DWH. Par conséquent, les données seront très volumineuses et la croissance sera encore plus importante. Nous utiliserons également quelques instances EC2 ou plus si nécessaire.

Quelle est la configuration recommandée dans ce cas? cela nécessitera une opération d'écriture rapide en raison de l'écriture constante (ETL). Peut-on construire des cubes OLAP dans PostgreSQL? si oui, quelqu'un a-t-il essayé?

Connexion à la base de données

Les serveurs Web se connecteront à la base de données principale pour interroger et écrire. Nous développons actuellement une application utilisant django qui utilise une bibliothèque native pour la connexion. Est-il recommandé d'utiliser la même méthode de base? ou devons-nous configurer pgpool?

Entrepôt de données (ETL)

Quelle est la méthode recommandée pour créer des processus ETL pour lire à partir du principal et charger dans l'entrepôt de données? Des outils? méthodologie à suivre? PostgreSQL propose-t-il des fonctions / outils utiles pour la construction de processus ETL?

Services d'infrastructure / de base de données

Vous devriez probablement lire ceci pour un aperçu d'un site à haut volume qui s'exécute sur AWS avec EBS. Ils sont passés au stockage éphémère mais ont dû créer une certaine redondance pour pouvoir (re) stocker les données.

http://blog.reddit.com/2012/01/january-2012-state-of-servers.html

Entrepôt de données / ETL

J'ai déjà utilisé Pentaho. Pas directement avec postgres, mais j'ai trouvé que c'était une bonne solution pour OLAP (Mondrian) et ETL (Kettle)

http://www.pentaho.com/

edit: "Community Editions" peut être trouvé ici

http://mondrian.pentaho.com/

http://kettle.pentaho.com/

Connexion

Ces gens semblent vraiment aimer pgbouncer. /programming/1125504/django-persistent-database-connection

Je n'en ai cependant aucune expérience. Apparemment, Disqus l'utilise.

Votre configuration ressemble à celle que j'ai développée pour une université. La base de données n'était pas énorme, mais assez grande, d'environ 300 Go et le plus grand tableau contenait environ 500 millions d'enregistrements. Et toujours en croissance.

Pour cela, deux serveurs vraiment costauds (du vrai fer, non virtualisés), l'un dédié à la gestion des données d'un site web et l'autre utilisé pour les calculs et analyses statistiques, ont été utilisés. Les données ont été répliquées dans les deux directions à l'aide de Slony. Les données OLTP ont été répliquées sur le serveur OLAP en continu et certains schémas et tables uniques ont été répliqués du serveur OLAP vers l'OLTP. De cette manière, des calculs lourds pouvaient être effectués sur le serveur d'analyse sans impact sur le serveur OLTP. De nos jours, il existe des alternatives à Slony pour la réplication des données: http://www.postgresql.org/docs/9.2/static/different-replication-solutions.html

Slony était bon et rapide pour notre inquiétude, mais cela peut être un professeur sévère.

Comme le serveur OLAP augmentera régulièrement, vous devriez envisager d'utiliser une sorte de partitionnement, le cas échéant.

Si vous en avez la possibilité, utilisez le pool de connexions. Je n'ai utilisé que PgPool et cela a fonctionné parfaitement. PgBouncer est une autre option. En plus de réduire la latence d'initialisation, il réduit également le démarrage et la gestion de session. http://momjian.us/main/blogs/pgblog/2012.html#April_25_2012

Un autre avantage de l'utilisation d'un pool de connexions est que vous avez un seul point où vous pouvez facilement rediriger votre trafic (cela pourrait bien sûr également être un risque).

Je n'ai utilisé aucun ETL prêt à l'emploi pour charger des données dans le serveur OLAP. J'ai écrit mon propre script en Python car certaines des données étaient livrées dans d'énormes fichiers texte avec un format particulier.

La structure de la base de données doit être soigneusement examinée. L'utilisation de schémas est utile pour rassembler et faciliter la manipulation d'objets. Il peut sembler lourd de commencer à utiliser des schémas, mais à mesure que le nombre d'objets augmente, vous vous en remercierez. Sachant que vous devez préfixer explicitement les objets avec leur schéma, vous savez exactement sur quels objets vous opérez. http://momjian.us/main/blogs/pgblog/2012.html#April_27_2012

Pour les plus audacieux, PostgreSQL XC est une alternative intéressante ou juste un costume surdimensionné http://postgres-xc.sourceforge.net/