Discussion :

[zatmania]

Bonjour,

J'ai pris l'habitude d'utiliser Mysql en raison des mon parcours professionnel. Je suis amené à utiliser également Postgresql. J'aurai aimé savoir si vous avez des retours d'expériences concernant HyperfileSQL que ce soit sous linux ou windows sur des projets conséquents (en terme de lignes stockées), d'architectures un peu évoluées, en terme de charge....

Cordialement

zat

[gancau]

Bonjour,
J'ai une appli de saisie, avec aide à la saisie. Tu remplis le champ1 et s'il est connu, les autres champs sont remplis automatiquement.
j'ai entre 30 et 50.000 enreg dans ma base.
Les temps de recherche et d'affichage des autres champs sont instantanés.
Gancau

[Bowen]

Bonjour, voici notre situation :

Base de 1,3 Go
Une centaine de fichiers, 1*400*129 enreg actuellement

Machine dédiée pour le serveur HF (Serveur siemens, Disques de données séparés du système, le tout en Raid5, Double quad-core 2,5 Ghz.... Bref, un gros serveur)

Les 30 postes clients sont remplacés par deux serveurs TSE, même config que le serveur HF.
+ 4 PDA.

Lien 2 Gbit/s entre tous ces serveurs.

Accès direct aux données suivant un parcours d'index : Instantané
Exécution de requêtes avec

• Une table, et un filtrage sur une rubrique non indexée : beaucoup plus long (2 à 3 secondes pour un SELECT TOP 1 xx FROM MaTable WHERE xx LIKE 'BOW-%' où xx est non indexé, MaTable = 240 000 lignes).
• Plusieurs tables, en jointures : exponentielles selon le nombre de tables.
• Fonctions d'agrégat sur une jointure de 4 tables : 30 secondes à 2 minutes, selon les critères (ensemble de résultats avec une seule fonction d'agrégat, comprenant moins d'une centaine de lignes)

En résumé, les performances s'écroulent dès que

• On filtre sur une colonne non indexée
• On fait des requêtes avec des jointures multiples (> 4)
• On fait des sous-requêtes
• On utilise les fonctions d'agrégat.

Il faut donc trouver des moyens de contourner ces limitations.

Par contre
Le point fort de cette base est sa souplesse d'utilisation. Les procédures stockées en WLangage par exemple.
Et ça nous sert beaucoup.
Par exemple, l'utilisation de fonctions récursives n'était pas disponible en SQL Server (avec la version sur laquelle j'avais testé, je crois que c'était la 2005). Aujourd'hui on s'en sert.

Bref, mon avis, moteur souple, mais qui pêche de jeunesse. Quelques bugs (des HLitRecherche dans des procédures stockées qui ne renvoient pas les résultats filtrés comme il faut par exemple, des SUM() qui renvoient deux lignes au lieu d'une...)
Mais on sent que le moteur évolue et gagne en puissance au fur et à mesure (on a démarré avec la version 12, et les jointures externes étaient par exemple beaucoup plus longues).

J'espère que ça éclairera ta lanterne.

[zatmania]

Merci Bowen & gancau pour ces retours en esperant qu'il y en aura d'autres.

Bowen, il est clair qu'au vu de tes propos je ne me sens pas encore prêt à utiliser cette BDD pour de gros projets. D'après ce que tu dis, vous disposez de la version 12 peut-être que les limitations que vous avez trouvé n'existe plus en version 14. Je préfèrerais m'investir dans Postgresql que j'utilise avec d'autres applications que Windev et l'accès natif est inclus depuis la version 14. Je pense néanmoins qu'hyperfilesql peut être très bien pour des applications clientes. Il faut que j'ajoute également que je viens de développer ma première application en windev. Je verrai avec le recul.

gancau, il est clair qu'en développant une appli avec hyperfilesql, l'intégration est parfaite et les fonctionnalités accrues.

zat

[Bowen]

D'après ce que tu dis, vous disposez de la version 12 peut-être que les limitations que vous avez trouvé n'existe plus en version 14.

Nous sommes en HF 14 depuis environ mars cette année.
Le projet a été mis en exploitation en août l'an dernier, en 12.
Une des fonctionnalités qui nous a fait basculer était la reconnexion automatique, pour les PDA. (reliés en wi-fi, il arrive parfois que les users passent dans des zones mal couvertes du dépôt).

Finalement nous ne sommes pas mécontents d'avoir basculé en 14, vu que les perfs y sont meilleures qu'en 12, et les normes mieux respectées.

Bref, comme je le disais, on sent l'évolution constante. on verra si ça se confirme en 15.

[vmolines]

Bonjour, voici notre situation :

Base de 1,3 Go
Une centaine de fichiers, 1*400*129 enreg actuellement

Machine dédiée pour le serveur HF (Serveur siemens, Disques de données séparés du système, le tout en Raid5, Double quad-core 2,5 Ghz.... Bref, un gros serveur)

Les 30 postes clients sont remplacés par deux serveurs TSE, même config que le serveur HF.
+ 4 PDA.

Lien 2 Gbit/s entre tous ces serveurs.

Accès direct aux données suivant un parcours d'index : Instantané
Exécution de requêtes avec

• Une table, et un filtrage sur une rubrique non indexée : beaucoup plus long (2 à 3 secondes pour un SELECT TOP 1 xx FROM MaTable WHERE xx LIKE 'BOW-%' où xx est non indexé, MaTable = 240 000 lignes).
• Plusieurs tables, en jointures : exponentielles selon le nombre de tables.
• Fonctions d'agrégat sur une jointure de 4 tables : 30 secondes à 2 minutes, selon les critères (ensemble de résultats avec une seule fonction d'agrégat, comprenant moins d'une centaine de lignes)

En résumé, les performances s'écroulent dès que

• On filtre sur une colonne non indexée
• On fait des requêtes avec des jointures multiples (> 4)
• On fait des sous-requêtes
• On utilise les fonctions d'agrégat.

Il faut donc trouver des moyens de contourner ces limitations.

Par contre
Le point fort de cette base est sa souplesse d'utilisation. Les procédures stockées en WLangage par exemple.
Et ça nous sert beaucoup.
Par exemple, l'utilisation de fonctions récursives n'était pas disponible en SQL Server (avec la version sur laquelle j'avais testé, je crois que c'était la 2005). Aujourd'hui on s'en sert.

Bref, mon avis, moteur souple, mais qui pêche de jeunesse. Quelques bugs (des HLitRecherche dans des procédures stockées qui ne renvoient pas les résultats filtrés comme il faut par exemple, des SUM() qui renvoient deux lignes au lieu d'une...)
Mais on sent que le moteur évolue et gagne en puissance au fur et à mesure (on a démarré avec la version 12, et les jointures externes étaient par exemple beaucoup plus longues).

J'espère que ça éclairera ta lanterne.

Intéressant retour d'expérience. Ca me conforte dans mon idée, non fondée au départ, de ne pas utiliser hyperfile.

Concernant la récursivité sur SQL Server, elle est surpportée par les procédures stockées (lien) mais aussi dans les requêtes avec le concept de CTE (lien). J'ai d'ailleurs un exemple avec une requête qui ramène une structure arborescente directement utilisée avec ArbreAjoute si ça vous intéresse.

[Bowen]

Intéressant retour d'expérience. Ca me conforte dans mon idée, non fondée au départ, de ne pas utiliser hyperfile.

Concernant la récursivité sur SQL Server 2005, elle est surpportée par les procédure stockée mais aussi dans les requêtes avec le concept de CTE. J'ai d'ailleurs un exemple avec une requête qui ramène une structure arborescente directement utilisée avec ArbreAjoute si ça vous intéresse.

Pour les procédures stockées, je ne savais pas et ça m'intéresse. pour les structures arborescentes, c'est moins gênant, je peux contourner.

Maintenant, pour SQL server 2005, il me semble qu'il me reste un problème, c'est le coût de licence (oui, je sais que je dévie du sujet)

Pour info, le moteur tourne à cette vitesse suite à la montée en charge.
La puissance des serveurs est là à cause de ça d'ailleurs.

En démarrant, les temps de réponses étaient très courts sur de plus vieux serveurs.

[vmolines]

J'ai travaillé uniquement avec la version Express de SQL Server 2005. Le moteur de base de données est complet en termes de fonctionnalités. Le bridage se fait sur la taille :

- limite à un processeur physique (multicore autorisé) utilisé par le process sqlserver
- limite à 1go de mémoire utilisé par le process sqlserver
- limite de base à 4go de données

C'était suffisant pour le projet sur lequel j'étais. Pour enlever cette limite, il faut débourser quelquechose comme 5000€ si je ne m'abuse. C'est cher mais pas non plus exorbitant. Je ne fais pas la pub de SQL Server, sachant qu'il y a d'autres alternatives gratuites à HF éprouvées (MySQL, Postgre).


Concernant votre volumétrie, le nombre de clients et la qualité de votre serveur, je suis effaré et attristé par les résultats de HF C/S. Sans être DBA, une telle volumétrie ne devrait poser aucun problème avec un SGBD correct et correctement utilisé.

Il serait vraiment interessant d'avoir un exemple de requête longue à l'exécution pour faire des tests sur un autre SGBD remonté avec les mêmes données (brouillées pour des besoins de confidentialité). Je suis persuadé qu'on arriverait à un tout autre résultat. Si l'expérience vous en dit...

[zatmania]

J'ai été à la présentation de la version 14 l'année dernière à Nantes (je réitère la semaine prochaine avec la 15). Ils ont fait un test de requete sur le serveur Hyperfile Sql qui contenait quelques millions de ligne et le résultat était presque instantané. Alors pour le côté commercial, je pense que dans l'assemblée beaucoup de gens ont du se dire cool c'est gratuit et performant. Par contre je me suis dit qu'une requete lancé X fois sur le serveur doit bénéficier du cache et donc forcément le résultat s'en ressent.

C'est pour cela que j'avait ouvert cette discussion pour obtenir un retour objectif et non pas le discours commercial de pc soft.

Merci à tous

zat