Quel moteur relationnel embarqué choisir pour sa performance ? [Résolu]

[Alesque]

Bonjour,

Dans le cadre d'un refactoring complet d'une application C++ faisant du batch processing nous cherchons à remplacer le moteur de base de données (pour l'instant l'application est compatible avec Oracle et SQL Server) par un moteur relationnel embarqué (le modèle client serveur n'étant pas une obligation) pour améliorer les performances. À ce sujet je me tourne donc vers vous pour savoir si certains ont eu des expériences positives.

Quelques infos sur l'utilisation de la base de données :

- 3 phases distinctes dans le process, update (5%), select (80%) et insert/update (15%), donc une db qui optimise les reads est souhaitée.
- Volume des données : jusqu'à 1 To réparti sur ~ 10 tables
- Tables contenants jusqu'à 500 colonnes et 1.000.000.000 de tuples.
- Transactionnel avec un niveau d'isolation read committed.
- OS: Windows, Linux, Solaris, AIX

Donc si vous connaissez des moteurs « open source » ou commerciaux en C/C++ ou Java qui puisse supporter ce genre de charge cela m'intéresse. Pour l'instant j'ai listé :

- H2 : KO taille limitée à 256 Gb.
- Berkeley DB ?
- PostgreSQL ?
- MySQL (InnoDB) ?
- FireBird ?

Tous les avis sont les bienvenus.

[qi130]

Question préliminaire : qu'entends-tu par "embarqué" ?

Afin qu'on soit en phase avec par exemple les versions "embedded" de Firebird ou MySQL...

[Alesque]

Je parle des versions embedded de ces moteurs.

Pour l'instant le principal bottleneck de l'application est la lecture en base des données, étant donné qu'au niveau du budget on ne peut se permettre de mettre la db en cluster la solution qui nous est venue à l'esprit est de partir sur des moteurs "in process".

[Marc Lussac]

Dans les solutions embeded les plus utilisées et Open source tu as PostgreSQL et FireBirdSQL.

[qi130]

Ceci dit, j'ai du mal à comprendre la démarche

Utiliser un moteur embarqué apporte son lot de limitations qui me semblent incompatibles avec l'architecture new-look (très succintement décrite) à mettre en place...
Le moteur embarqué impose le plus souvent un accès exclusif à la base. Cette même base sera le plus souvent en local et donc, dans ce cas de figure, quid du volume évoqué (1 To) par rapport à 1 HD de 500 Go qui pourrait équiper les PC des utilisateurs?

De même, le modèle C/S est évoqué: je suppose que c'est le modèle de l'appli actuelle ?
Dans cette configuration, il est possible de partager les données. Cette possibilité est-elle reconduite ? Si oui, quel est le moyen envisagé pour consolider les données ? (x clients -> 1 référentiel -> x clients).

Alors, bien sûr que c'est faisable, mais le coût induit (essentiellement matériel) ne sera t'il pas largement supérieur à une licence Oracle ?

En l'état actuel des éléments fournis, c'est tout ce que je peux dire

[SQLpro]

- 3 phases distinctes dans le process, update (5%), select (80%) et insert/update (15%), donc une db qui optimise les reads est souhaitée.

Sur un SGBDR bien fait ce sera à vous d'optimiser ce que vous voulez en choisissant judicieusement vos stratégies d'indexation.

- Volume des données : jusqu'à 1 To réparti sur ~ 10 tables

alors commencer par vous limiter aux trois grands : Oracle, DB2, SQL Server, car ce sont les seuls à vous proposer des solutions de partionnement de tables, d'index, de vues... Nécessaire lorsque l'on veut à la fois de l'optimisation et des grand volumes

- Tables contenants jusqu'à 500 colonnes et 1.000.000.000 de tuples.

Nous ne sommes plus donc dans un modèle relationnel. Dans un modèle relationnel les tables ont peu de colonnes. Soit vous ne connaissez pas grand choses au SGBDR et encore moins en modèle de données, comme hélas beaucoup d'informaticiens, soit votre application est très praticulière et le SGBDR n'est pas le bon choix. Au passage le nombre de lignes n'a aucune signification pour un SGBDR

- Transactionnel avec un niveau d'isolation read committed.

Vous savez donc déjà toutes les transactions qui y seront faites ? De toutes façon sur un bon SGBDR obéissant à la norme SQL, le niveau d'isoaltion des transactions est pilotable dynamiquement et par session.

- OS: Windows, Linux, Solaris, AIX

Heureusement que vous n'exigez pas en plus MVS uniquement !!! ;-)

Donc si vous connaissez des moteurs « open source » ou commerciaux en C/C++ ou Java qui puisse supporter ce genre de charge cela m'intéresse.

Pourquoi vous focalisez vous sur C++ ou Java ? Vous exigez que le moteur SQL soit écrit en C++ Ou Java ??? Je ne coprend pas ce que vous voulez dire ??? Précisez SVP !

Enfin que voulez-vous dire par embarqué ? Ce sera dans une fusée ????

A +

[al1_24]

Envoyé par SQLpro

alors commencer par vous limiter aux trois grands : Oracle, DB2, SQL Server, car ce sont les seuls à vous proposer des solutions de partionnement de tables, d'index, de vues... Nécessaire lorsque l'on veut à la fois de l'optimisation et des grand volumes

En effet, 1To c'est un peu court pour passer à Teradata ou Netezza

[Alesque]

Je vais essayer de répondre en une seule fois :

Le moteur embarqué impose le plus souvent un accès exclusif à la base. De même, le modèle C/S est évoqué: je suppose que c'est le modèle de l'appli actuelle ? Dans cette configuration, il est possible de partager les données. Cette possibilité est-elle reconduite ?

On fonctionne aujourd'hui sur SQL Server, Oracle et DB2. Le mode C/S nous sert uniquement à processer des reports 1 fois par mois. L'accès exclusif pour notre utilisation n'est pas un problème il suffit d'extraire les données une fois par mois dans une db C/S pour lancer les reports. Je vous vois déjà arriver... effectivement la consommation en espace de stockage sera doublée.

Sur un SGBDR bien fait ce sera à vous d'optimiser ce que vous voulez en choisissant judicieusement vos stratégies d'indexation.

Déjà fait avec partitionnement des fichiers sur des volumes différents mais le processing est toujours limité par les reads en db. On a également réduit au maximum le nombre de requêtes.

soit votre application est très praticulière et le SGBDR n'est pas le bon choix.

Je vous rejoins complètement. LA solution mis en avant est l'utilisation de fichiers plats pour l'instant. Peut être qu'un compromis avec une db "in process" permettrait de garder certaines fonctionnalités d'un SGBDR (transaction) qui nous sont utiles tout en améliorant les perfs d'un mode C/S.

Enfin que voulez-vous dire par embarqué ? Ce sera dans une fusée ????

Quand je parle d'embarqué je veux dire "in-process".

Pourquoi vous focalisez vous sur C++ ou Java ? Vous exigez que le moteur SQL soit écrit en C++ Ou Java ??? Je ne coprend pas ce que vous voulez dire ???

L'implémentation actuelle est en C++, mais Java est un candidat sérieux car dans certaines parties du process Java performe mieux. Donc si on part sur du C++, le mieux et de pouvoir linker la lib en statique et si on part sur du java avoir le moteur écrit en Java. Le but est d'avoir le moins de couches middleware pendant les appels au moteur.

J'espère que cela répond à vos questions...

[kedare]

si jamais le java ne te derange pas , H2 est vraiment pas mal :
http://www.h2database.com/html/frame.html