Discussion :

[cedric.menec]

Bonjour à tous,

Travaillant pour un éditeur de solutions informatiques, je suis chargé d'analyser l'architecture technique à mettre en place pour un très gros projet.

Notre progiciel, écrit en Java, est multiplateforme et multi SGCD. Il utilise la technologie JDBC pour accéder à ses sources de données, et plus spécifiquement le driver JTOpen pour accéder à des sources DB400 sur un iSeries en V5R4.

Nous n'avons jamais réellement rencontré de soucis jusqu'à présent, mais le projet à venir possède une très grosse volumétrie. Plusieurs millions de lignes par jour. Plusieurs milliard de lignes à l'année... Très grosse sollicitation.

Nous avons réalisé des benchmarks sur un ORACLE 10g hébergé sur un Linux RHEL 5, nous avons également quelques idées des performances que nous pourrions rencontrer sur un SQL Server 2005 hébergé sur un Windows Server, par contre je n'ai aucune idée de ce que cela pourrait donner dans un contexte DB2 for i/5.

Je n'ai pas les moyens, ni le temps d'injecter ces milliards de lignes dans une base DB400 et de faire un nouveau benchmark.

Est-ce que l'un d'entre vous pourrait me faire un retour d'expérience sur l'utilisation de DB400 dans un contexte JDBC, avec de telles volumétries ?

Pour information, nous n'utilisons pas de procédure stockées, et le SQL générés est relativement générique, afin de faciliter la compatibilité multi-SGBD (utilisation de couches de persistance, dont Hibernate).

A votre avis, est-ce viable ?
Aussi bien en terme de performance (temps de réponse), et de robustesse (stabilité), qu'en terme d'exploitation (sauvegarde différentielle, journalisation etc...).

Tout retour d'expérience, positif ou négatif serait apprécié.


D'autre part, si vous aviez à mettre un projet mettant en oeuvre une base relativement volumineuse, avec de forte contrainte de performance et de robustesse, vers quelle configuration technique (paire OS / SGBD) vous vous tourneriez ? Et pour quelles raisons ?

Vos avis m'intéressent.

Merci d'avance à ceux qui auront pris le temps de lire ce message.

Cédric

[K2R400]

Nous avons réalisé des benchmarks sur un ORACLE 10g hébergé sur un Linux RHEL 5, nous avons également quelques idées des performances que nous pourrions rencontrer sur un SQL Server 2005 hébergé sur un Windows Server

Je savais même pas que SQL server pouvait héberger autant de données !
M'enfin j'ai un gros doute.

Aussi bien en terme de performance (temps de réponse), et de robustesse (stabilité), qu'en terme d'exploitation (sauvegarde différentielle, journalisation etc...).

Commencons par la robustesse :
Est-il encore nécessaire de citer le taux de disponibilité d'un IBM i ?
De 99,99% juste derrière le mainframe 99,999%

Exploitation:
1 seule personne aux commandes, pas besoin de DBA ou d'un type pour démarrer et arrêter la BD, elle tourne, elle ne s'arrête jamais, elle ne se démarre pas.
Pas de virus, une sécurité des plus poussées, un OS stable qui a fait ses preuves.

Sauvegarde :
Des outils de sauvegarde natifs base ouverte, mais pour des sauvegardes plus poussées (catalogue des sauvegardes, recherche dans le catalogue, gestion d'une robotique etc...) il faudra utiliser des utilitaires payant en sus comme BRMS.

Journalisation :
Des logs comme dans toutes les bases, mais pour des perfomances optimales, il faudra mettre ces logs (receveurs) dans un ASP séparé (c'est à dire sur des disques isolés de là ou se trouve la BD)

Performance :
L'ibm I est avant tout un serveur basé sur les I/O disques plutôt que processeur. Gérer les I/O c'est son truc.
Il intègre nativement DB2 UDB depuis la V5R2 (c'est à dire le code en C++ récupéré du mainframe) avec son nouveau moteur SQL appelé SQE.
Est-il necessaire de parler des volumes que stockent les mainframes ????
Le moteur de l'IBM i est le même que celui des mainframe.
Les temps de réponse sont plus qu'excellents, des benchmarks laissent Oracle derrière. Car IBM possède certains brevet comme les EVI (Encoded Vector Index) qui sont extrêmements performants.
Maintenant, en V5R4 le moteur n'a pas été totalement porté, donc SQE n'est pas totalement complet, par contre il l'est en V6R1.
Si l'ancien moteur CQE traite des requêtes, les performances peuvent être médiocres. C'est le cas dans quelques situations (liste exhaustive en ce qui te concerne) :

- Utilisation des fonctions UPPER/LOWER ou UCASE/LCASE et TRANSLATE.
- Utilisation des UDTFs
- Sort séquence qui ne seraient pas hexadécimales (tri ASCII par exemple)
- Requête sur des Index (et non des tables).

Bien sur, en V6R1 tout ceci est pris en charge par SQE, ecepté le dernier point.


Personnellement, je te dirais que l'IBM i est avant tout un serveur exactement fait pour héberger une grosse SGBD, robuste, sécurisé et facile d'exploitation. A l'inverse, je te déconseille d'y faire tourner un serveur d'application (excepté dans une partition LINUX sur le même serveur).

[cedric.menec]

Bonjour K2R400,


Merci beaucoup pour cette réponse détaillée, qui à priori se veut plutôt rassurante.

Je savais même pas que SQL server pouvait héberger autant de données !

Je n’ai pas dit que c’était le cas
Il est d’ailleurs exclus pour le moment de mettre SQL Server 2005 dans la boucle, mais c'est un autre sujet.


ROBUSTESSE

Ce qui m’inquiète ce n’est pas la robustesse du système, mais celle de la base de données, dans un contexte d’utilisation JDBC (j’insiste sur ce point).
Je suis persuadé qu’en natif l’accès à une base de données DB400 est très performante, mais je m’interroge pour les accès utilisant une interface ODBC ou JDBC (dans notre cas ça sera du JDBC), puisque cela met en œuvre un certain nombre de couche.



EXPLOITATION

Effectivement, en terme d’administration de la base, la charge de travail est quasiment nulle pour les équipes d’exploitation (point non négligeable, je te l’accorde).

Concernant les sauvegardes, et tout particulièrement l’outil « BRMS », je vais me renseigner sur ce produit que je ne connais pas.
A ce sujet, ce qui m’intéresse, effectivement, c’est d’être en mesure de faire des sauvegardes base ouverte, afin de fournir un maximum de disponibilité, mais ça DB2 for i/5 sait le faire nativement.
Mais j’ai également besoin d’être en mesure de faire des sauvegardes fréquentes (différentielles ? transactionnelles ?) afin de minimiser les pertes de données en cas d’incident, et de réduire les délais des reprises de données / resynchronisation d’environnements.

Nous parlons de base qui atteindront probablement assez rapidement une taille conséquente, proche du To, donc les plans de maintenance, et notamment de sauvegarde sont des éléments déterminant dans notre choix du SGBD.



JOURNALISATION

Des logs comme dans toutes les bases, mais pour des perfomances optimales, il faudra mettre ces logs (receveurs) dans un ASP séparé (c'est à dire sur des disques isolés de là ou se trouve la BD)

Autant pour SQL Server ou ORACLE cela me parait naturelle, d’isoler les journaux de transaction sur un autre LUN ou disque, mais sur AS/400 je n’y aurai pas pensé.
Merci du conseil.



PERFORMANCES

Si nous partons sur un DB2 for i/5, le système sera en V5R4, malheureusement je n’aurai pas le choix.

Je vais donc effectivement me renseigner auprès des équipes de développement, pour savoir si nous sommes susceptibles de nous trouver fréquemment dans les situations listées qui nous ferait donc utiliser CQE plutôt que SQE si j’ai bien compris. En tout cas merci de ces importantes informations !

Ce qui m’inquiète le plus au sujet des performances, c’est que contrairement au SGBD ORACLE, je ne vois pas du tout comment monitorer les performances d’une activité sur une base DB400.

D’autre part, autant il existe un certain nombre d’actions de tuning qu’il est possible de mener sur une instance ou un schéma ORACLE pour adapter la base à l’activité souhaitée, autant je ne trouve rien ou presque, sur le tuning d’une base de données DB400. Et j’ai vraiment du mal à croire que le paramétrage, par défaut, d’une base soit en mesure de répondre à toute les problématiques potentiellement généré par une activité logicielle (surtout avec de telles volumétrie…).

Pour finir, pourrais-tu me dire d’où tu sors ces indicateurs de performances s’il te plaît ? (taux de disponibilité, benchmark comparatif Oracle)
Pas que je ne te fasse pas confiance, ou encore moins que je les remette en cause, mais avant de poster sur ce forum, j’ai effectué un certain nombre de recherches.
Si je me suis décidé à interroger la communauté, c’est que je n’ai trouvé aucune information probante pour m’aider à faire mon choix.
Si ce type d’informations existe c’est que je n’ai pas interrogé les bons canaux.
Je serais donc très intéressé de savoir où sont disponibles ces informations, s’il te plaît.


Encore une fois merci d’avoir pris le temps de répondre à ma question, et merci pour la qualité de ta réponse.



NOTE : Comme plusieurs avis valent mieux qu’un, je ne clôture pas le post, donc si d’autre posteur veulent intervenir, n’hésitez pas.

[K2R400]

ROBUSTESSE

Ce qui m’inquiète ce n’est pas la robustesse du système, mais celle de la base de données, dans un contexte d’utilisation JDBC (j’insiste sur ce point).
Je suis persuadé qu’en natif l’accès à une base de données DB400 est très performante, mais je m’interroge pour les accès utilisant une interface ODBC ou JDBC (dans notre cas ça sera du JDBC), puisque cela met en œuvre un certain nombre de couche.

La JVM qui tourne derrière est celle du monde UNIX 32 bits en V5R4 et/ou 64 bits pour la V6R1.

EXPLOITATION

Effectivement, en terme d’administration de la base, la charge de travail est quasiment nulle pour les équipes d’exploitation (point non négligeable, je te l’accorde).

J'ajouterai qu'il possède l'un des records de TCO au monde (Total Cost OwnerShip)

...Mais j’ai également besoin d’être en mesure de faire des sauvegardes fréquentes (différentielles ? transactionnelles ?) afin de minimiser les pertes de données en cas d’incident, et de réduire les délais des reprises de données / resynchronisation d’environnements.

La resynchronistation est automatique sur un AS/400 du moment que la base est journalisée, pas de transactions partielles ou non commitées.
Maintenant, pour de bonnes sauvegardes incrémentielles, mieux vaut BRMS.

PERFORMANCES
Je vais donc effectivement me renseigner auprès des équipes de développement, pour savoir si nous sommes susceptibles de nous trouver fréquemment dans les situations listées qui nous ferait donc utiliser CQE plutôt que SQE si j’ai bien compris.

Exact, tout compris.

Ce qui m’inquiète le plus au sujet des performances, c’est que contrairement au SGBD ORACLE, je ne vois pas du tout comment monitorer les performances d’une activité sur une base DB400.

Il y a dans la bête un moniteur de performance SQL intégré qui nous permet de suivre l'activité, un assitant de gestion des index, des catalogues de statistiques sur l'activité des tables/index/vues, un cache stockant l'ensemble des plans d'accès, un explain pour décortiquer ces plans d'accès etc... qui permettent de faire un état précis de l'utilisation de la base afin de créer les bons index.

...Et j’ai vraiment du mal à croire que le paramétrage, par défaut, d’une base soit en mesure de répondre à toute les problématiques potentiellement généré par une activité logicielle (surtout avec de telles volumétrie…).

Si ton produit est livré sans index, il faudra s'appuyer sur ces outils pour créer les bons index, ce qui veut dire qu'il faudra faire au début un peu de tuning (création d'index & d'EVI). Car même si le moteur créé automatiquement des index temporaires, ceux-ci ne seront conservés que jusqu'au prochain redemarrage.

Pour finir, pourrais-tu me dire d’où tu sors ces indicateurs de performances s’il te plaît ? (taux de disponibilité, benchmark comparatif Oracle)
Pas que je ne te fasse pas confiance, ou encore moins que je les remette en cause, mais avant de poster sur ce forum, j’ai effectué un certain nombre de recherches.

Ce que je te conseille, c'est de prendre un RDV avec le PSSC d'IBM à Montpellier (centre de benchmarks d'europe) afin de venir faire tes benchs toi même.
Aussi il est utile de rappeler que plus il y a de disques (même de petites capacités) donc de bras, plus les performances seront grandes. Au PSSC ils ont toutes sortes de config.

[cedric.menec]

Bonjour K2R400,

Merci pour toutes ces précisions.
Je vais digérer et approfondir tout ça.