Architecture: storage data: BDD ou SAS serveur?

Bonjour,

Je dois faire un choix d'architecture et j'essaye de poser les pour et les contres, ainsi petite question pour avoir vos avis:

quels sont les avantages de stocker mes data dans une BDD (type Postgresql) VS les stocker sur un file system (situé dans la même que le serveur de calcul) avec l'utilisation d'un SAS metadata server. La taille des datasets est d'environ 10 million de lignes et 1 go.
L'idée serait à terme d'évoluer vers un DWH. il y a très peu de transaction (mais beaucoup d'analyse statistique)

c'est peut-être un peu vague mais si vous avez des pistes/des idées, histoire d'alimenter ma réflexion.

Merci d'avance

Bonjour,
Je pense pouvoir t'aider, mais je ne suis pas certain d'avoir bien compris le problème.
Le metadata server est incontournable dans une plateforme SAS. Postgres est très bien comme SGBD transactionnel. S'il doit y avoir concurrence d'accès sur les données en question (mises à jour simultanées), Postgres est incontournable. S'il s'agit d'une base mise à jour par tes batches à toi (i.e. un seul compte qui modifie les données) et que ces données sont normalisées façon DWH, les placer en tables SAS a du sens et se révèlera sans doute beaucoup plus performant.
Je ne suis pas certain que le SAS/ACCESS to Postgresql soit intégré dans toutes les plateformes, il faut se renseigner avant de faire le choix, et il se peut que la licence s'ajoute au budget prévu. En accédant par exemple au travers d'un SAS/ACCESS to ODBC, ce sera la cata en termes de performances. Vaut mieux choisir le format SAS pour les données plutôt que de partir là-dessus.
Pour ce qui concerne les développements, s'ils sont faits dans les règles de l'art, c'est à dire en utilisant des bibliothèques déclarées dans les métadonnées, le code devrait être le même que ce soit une base SAS en entrée, ou une base Postgres. Si c'est développé à l'ancienne, faut voir.
Ce qui est certain, c'est que quand on a du SAS en entrée et du SAS en sortie, il n'y aura pas de souci lié au format :)

Si tu veux préciser ta demande, pose tes questions et j'essaierai d'y répondre.

Citation:

---

Envoyé par Stackware

Bonjour,
Je pense pouvoir t'aider, mais je ne suis pas certain d'avoir bien compris le problème.
Le metadata server est incontournable dans une plateforme SAS. Postgres est très bien comme SGBD transactionnel. S'il doit y avoir concurrence d'accès sur les données en question (mises à jour simultanées), Postgres est incontournable. S'il s'agit d'une base mise à jour par tes batches à toi (i.e. un seul compte qui modifie les données) et que ces données sont normalisées façon DWH, les placer en tables SAS a du sens et se révèlera sans doute beaucoup plus performant.
Je ne suis pas certain que le SAS/ACCESS to Postgresql soit intégré dans toutes les plateformes, il faut se renseigner avant de faire le choix, et il se peut que la licence s'ajoute au budget prévu. En accédant par exemple au travers d'un SAS/ACCESS to ODBC, ce sera la cata en termes de performances. Vaut mieux choisir le format SAS pour les données plutôt que de partir là-dessus.
Pour ce qui concerne les développements, s'ils sont faits dans les règles de l'art, c'est à dire en utilisant des bibliothèques déclarées dans les métadonnées, le code devrait être le même que ce soit une base SAS en entrée, ou une base Postgres. Si c'est développé à l'ancienne, faut voir.
Ce qui est certain, c'est que quand on a du SAS en entrée et du SAS en sortie, il n'y aura pas de souci lié au format :)

Si tu veux préciser ta demande, pose tes questions et j'essaierai d'y répondre.

---

non c'est très bien merci de ta réponse!
Oui le module access to [postgres] a un coût. Je note les difféerents élement et retiens l'avantage de l'accès concurrentiel pour postgresql.

Tu peux également retenir l'avantage performance pour les tables SAS, et le coût car si postgres est opensource, son administration nécessite un expert. Les tables SAS sont de simples fichiers faciles à manipuler, et les tâches d'administration sont réduites.
Les leviers de performances sont plus dans le code qu'autre chose, ou dans la construction du modèle. Postgres est un vrai SGBDR, avec tout ce qui va autour. Une base Oracle demande pratiquement les mêmes efforts, sauf qu'elle bénéficie d'un outillage plus important et abouti, qui permet d'économiser sur l'humain, certes, mais qui coûte cher.
Quand on évalue les coûts, on oublie souvent ce genre de détail qui pourtant finit par peser lourd, et qui aurait pu changer la décision s'il avait été pris en compte :)