Vous n'êtes pas identifié(e).
Bonjour,
Je travaille à la conception d'un entrepot de données de l'ordre de 2 à 3 To. Il est rempli par des applications métiers, et requeté par un outil BI du type Tableau à des fins d'analytics assez simples.
Question 1 : Quel serait le dimensionnement necessaire pour un noeud unique en termes de RAM/CPU ?
Je pensais partir sur une approche maitre-esclaves. Depuis la version 9.1 de Postgres, j'ai vu qu'une fonctionnalité de réplication synchrone est disponible. J'imaginais pouvoir faire du load balancing, mais la documentation n'est pas très claire sur ce point. Dans mon idée : un master gérant lectures et ecritures, et pouvant déléguer les lectures sur d'autres esclaves.
Question 2 : PostgreSQL 9.1 est-il autonome sur le sujet, ou dois-je passer par Pgpool ?
Question 3 : Combien d'esclaves pourraient être nécessaires pour avoir des performances acceptables ? Peut-on ajouter des esclaves à chaud ?
Question 4 : Un passage à Greenplum/AsterDate/GridSQL est-il indispensable ?
Ca fait beaucoup de questions mais mon expérience PostgreSQL passée se résumé à des bases de 10Go tournant sur QuadCore/24Go de RAM... donc autant dire sans (mauvaise!) surprise.
Merci de vos lumières !
Hors ligne
Question 1 : Quel serait le dimensionnement necessaire pour un noeud unique en termes de RAM/CPU ?
Tout dépend de votre activité sur votre base. Le nombre de CPU dépend principalement du nombre d'utilisateurs. Leur vitesse dépend principalement des requêtes exécutées. La taille de la mémoire dépend surtout du volume utile de la base sur une certaine durée. Bref, c'est impossible de vous répondre sans plus d'informations. Pour prendre un exemple extrême, j'ai vu une base de 4 To avec un bi Xeon et 4 Go de RAM. C'était clairement pas de l'OLTP avec un grand nombre d'utilisateurs.
Question 2 : PostgreSQL 9.1 est-il autonome sur le sujet, ou dois-je passer par Pgpool ?
Il faut passer par pgpool. Il faut un hyperviseur à PostgreSQL pour faire la répartition de charge et cela passe par pgpool (ou par un codage spécifique du client).
Question 3 : Combien d'esclaves pourraient être nécessaires pour avoir des performances acceptables ?
Là-aussi, c'est impossible à répondre sans plus de détails. Vous n'indiquez même pas la charge que vous pensez avoir, dans quelles conditions, etc, etc.
Peut-on ajouter des esclaves à chaud ?
Oui.
Question 4 : Un passage à Greenplum/AsterDate/GridSQL est-il indispensable ?
Non.
Guillaume.
Hors ligne
Bonsoir Guillaume,
Question 1 : dimensionnement dans le cas d'un noeud unique ?
Oui j'avoue avoir été léger en détails. La vérité est que la volumétrie est encore hypothétique.
Partons sur une table unique, une trentaine de champs pour 1000 octets au total (taille des données brutes) : un timestamp, une dizaines de compteurs (qu'on veut grapher), quelques chaines de caractères sur lesquelles on va filtrer. 5 index sur les colonnes de filtre.
En écriture :
- une centaine de clients faisant des INSERT, disons un toutes les dix secondes, en permanence, 24/7
En lecture :
- un client unique (l'outil de BI) qui viendrait faire ses requêtes deux à trois fois par jour pour générer un dashboard. Je n'ai pas regardé la complexité des requêtes générés par Tableau.
J'ai constaté que Postgres n'utilisait qu'un seul processeur, ce qui me semble sous-optimal. Donc finalement ca rend ma question stupide en réalité, non ?
Question 3 :
cf la question 1 
Question 4 : GreenPlum & Co
D'expérience, savez vous à quelle volumétrie on peut s'y intéresser (plutot 100Go, 1Po et +) ? Grossièrement bien sûr.
J'espère avoir été plus précis cette fois. Encore merci de votre aide !
Hors ligne
J'ai constaté que Postgres n'utilisait qu'un seul processeur, ce qui me semble sous-optimal. Donc finalement ca rend ma question stupide en réalité, non ?
Ce n'est pas tout à fait ça. Une requête n'est exécutée que par un processeur. Si vous avez 10 requêtes exécutées en même temps et seulement 4 processeurs, seules 4 requêtes pourront s'exécuter à un instant t, du coup vous irez moins vite que si vous avez 10 processeurs. Et avec 11 processeurs, vous n'irez pas plus vite. (évidemment, tout dépend de l'activité disque, de l'activité des autres programmes sur le serveur, etc. .. mais dans la théorie, ça fonctionne ainsi)
100 clients, avec une insertion par client toutes les dix secondes, ça veut dire 10 insertions par secondes, autrement dit une toutes les 100 ms. Pour écrire 1ko, c'est comfortable.
À moins que les 100 insertions se font en même temps, pas besoin d'un grand nombre de coeurs. À priori, 8 coeurs devraient suffire à tenir la charge. Concernant l'activité du BI, il ira plus vite s'il peut paralléliser en utilisant plusieurs connexions à la base.
Au niveau de la RAM, ça se jouera surtout au niveau des requêtes du BI. Difficile d'en dire plus. De toute façon, plus vous en aurez, mieux ça sera.
Vous n'avez pas parlé du tout de rétention des données ? vous avez une limite ? x années ou quelque chose du genre ?
Question 3 :
Concernant votre outil de BI, s'il a besoin de créer des tables temporaires, impossible d'utiliser les esclaves pour ça. Il faudra passer par le maître (oui, même pour des tables temporaires).
Question 4 : GreenPlum & Co
La dernière fois que j'en ai entendu parler, les commerciaux de Greenplum ne se déplaçaient pas pour des volumétries inférieures à 10 To. Maintenant, cela a peut être changé depuis. Cependant, avant de réclamer leur services (payants), j'essaierai de voir ce qu'il est possible de faire avec PostgreSQL.
Guillaume.
Hors ligne
Très clair pour la question 1. On peut rêver à imaginer du parallélisme à l'avenir pour une même requête
Concernant la rétention, elle est intégré dans l'approximation de volume. L'idée est de retenir 5 ans maximum (on part sur 500Go/an minimum au départ).
Question 3 : je suis parti du principe que non, mais effectivement, la question mérite d'être posée à l'éditeur, ce que je viens de faire. C'est embêtant car ça mine toute possibilitié de faire du scaling, sauf à utiliser une architecture maitre-maitre c'est ça ? (et dans ce cas les choix pourraient par ex. être Bucardo, PostgresXC )
Question 4 : Oui, je pense que le plus raisonnable reste de prendre le temps de maquetter la chose.
Merci pour ces éclaircissements !
Hors ligne
On peut rêver à imaginer du parallélisme à l'avenir pour une même requête
Vous ne croyez pas si bien dire. Il y a quelques jours a été commité un patch qui permet à deux connexions de voir la base de données avec le même snapshot. C'est clairement ce qui manquait pour permettre une exécution parallèle. Cela étant dit, il reste encore plein de choses à faire pour que cela soit possible.
Question 3 : je suis parti du principe que non, mais effectivement, la question mérite d'être posée à l'éditeur, ce que je viens de faire. C'est embêtant car ça mine toute possibilitié de faire du scaling, sauf à utiliser une architecture maitre-maitre c'est ça ? (et dans ce cas les choix pourraient par ex. être Bucardo, PostgresXC )
Si vous utilisez BO, il a besoin de tables de travail. Donc, si vous voulez rester à la réplication interne de PostgreSQL, il vous faut un pgpool devant qui redirige les écritures sur le maître et les lectures sur l'esclave. Sinon, vous pouvez utiliser Slony, surtout sur un schéma aussi basique. Et vous pourrez utiliser l'esclave bien mieux pour votre outil de BI, Slony n'interdisant pas les modifications de schéma sur les tables non répliquées et autorisant l'ajout d'index sur les tables répliquées. Dans votre cadre spécifique, je vous conseillerai plutôt Slony si votre outil de BI a besoin d'écrire.
Concernant Bucardo, pourquoi pas. Attention que vous aurez à gérer les conflits en écriture. Pour Postgres XC, à ma connaissance, ce n'est pas à installer en prod actuellement.
Guillaume.
Hors ligne
Si vous utilisez BO, il a besoin de tables de travail. Donc, si vous voulez rester à la réplication interne de PostgreSQL, il vous faut un pgpool devant qui redirige les écritures sur le maître et les lectures sur l'esclave. Sinon, vous pouvez utiliser Slony, surtout sur un schéma aussi basique. Et vous pourrez utiliser l'esclave bien mieux pour votre outil de BI, Slony n'interdisant pas les modifications de schéma sur les tables non répliquées et autorisant l'ajout d'index sur les tables répliquées. Dans votre cadre spécifique, je vous conseillerai plutôt Slony si votre outil de BI a besoin d'écrire.
Oula... là je suis perdu ! 
Pourquoi le fait que Slony n'interdise pas les modifications de schéma sur les tables non répliquées va aider mon outil de BI ?
On ne peut pas ajouter d'index à une table répliquée par Postgres lui-même ?
C'est ces deux points qui vont font préférer Slony à Postgres+Pgpool dans mon cas ?
Concernant Bucardo, pourquoi pas. Attention que vous aurez à gérer les conflits en écriture. Pour Postgres XC, à ma connaissance, ce n'est pas à installer en prod actuellement.
Complexe à mettre en oeuvre, moins mature.. je passe mon chemin !
Hors ligne
On ne peut pas ajouter d'index à une table répliquée par Postgres lui-même ?
Non, l'esclave est vraiment bloqué en lecture seule sur la réplication avec PostgreSQL.
C'est ces deux points qui vont font préférer Slony à Postgres+Pgpool dans mon cas ?
Si c'est pour faire du BI, du Datawarehouse, il y a de forte chance que Slony corresponde mieux à votre besoin que la réplication proposée par PostgreSQL. Ensuite, tout dépend de votre outil. Ce que j'ai dit n'est qu'une règle générale.
Guillaume.
Hors ligne
Tout ceci se clarifie doucement. Je vais creuser la piste Slony.
Merci encore Guillaume !
Hors ligne
