PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV (précédentes versions) → Méga BD ou plusieurs BD identiques
Méga BD ou plusieurs BD identiques
Débuté par ChouLAGH, 07 juin 2017 17:50 - 10 réponses
Membre enregistré
248 messages
Popularité : +1 (1 vote)
Posté le 07 juin 2017 - 17:50
Bonjour à tous,
J'ai développé un Software avec une BD HyperFile c/s sur le Cloud PC Soft.
Le software est en 3 morceaux : partie mobile avec Windev mobile 20 Smartphone et tablette, partie Desktop avec Windev 20
et Web services avec Windev 20 et HyperFile sur Le Cloud PC Soft.

Je suis très content des tests unitaires que je réalise.

LE PROBLEME CLASSIQUE QUI SE POSE : qu'on sera t il des temps de réponse en production avec des grosses tables ?

La BD Elle contient environ 30 tables.

Le software sera vendu à plusieurs sociétés. chacune sera reconnue dans la BD par un code société.
une dizaine des tables seront mises à jour assez intensément tous les jours = jus qu à 200 000 lignes par jour.
en plus ces tables contiendront des images.

Je crains les temps de réponse des requêtes lorsque la BD deviendra très grosse.
===========================================
Je vais procéder à la création d'un jeu d'essais pour simuler les grosses tables et simuler des requêtes
Mais je serai seul à interroger.

=======================================
JE VIENS ICI VOUS DEMANDER VOTRE AVIS ET VOTRE EXPÉRIENCE SVP
=======================================

Sachant que j'ai réfléchi à plusieurs solutions :
===============================
1) 1ère Solution nécessaire : j'augmente les ressources de la plateforme Cloud au fur et à mesure de la taille de la BD :
je modifie l'abonnement sur le Cloud PC Soft,
===============================
2) La réplication :
J'ai vu dans différentes discussions sur ce forum que la réplication est proposée.

Je ne connais pas le sujet mais il me semble que c'est compliqué dans mon cas car :
- Les utilisateurs utilisent :
Soit un Smartphone, Soit une Tablette , Soit un PC = Software en 3 parties = Windev mobile Smartphone + windev mobile Tablette + Windev Desktop sur PC.
- Il n'est pas question d'installer une BD sur les PC de la société = le but est que le poste client soit léger et aucune installation ou configuration,
================================
3) plusieurs BD identiques (une par société) :
Je ne l'ai jamais fait :
- Comment générer plusieurs BD sur le Cloud avec une seule Analyse ?
-Comment se connecter à telle BD plutôt qu'à une autre selon le code société ?
là j'ai une idée : tous les accès à la BD se font par des Web services Windev : je peux centraliser le changement de base dans
une fonction du web service qui recevra le code société. mais je n'ai pas d'exemple de code pour changer de BD.
================================
4) Garder la Méga BD unique mais décider de dégraisser les grosses tables :
càd que je peux décider d'archiver les lignes anciennes de plusieurs mois dans des tables d'archives.
donc des tables en ligne moins grosses.
Mais il faut que je modifie mon code pour que :
les requêtes interrogent des données récentes et éventuellement proposer d'aller interroger des données plus anciennes.

=====================
DONC MES QUESTIONS :
=====================
- Quelqu'un a déjà une expérience d'interrogation de grosse base de données sur le Cloud PC Soft ? et si oui quelles stats
sur les temps de réponse ? quels conseils ?

- Avez vous d'autres solutions à me proposer ?
- que pensez vous de mes propositions de solutions ?

Merci d'avance de vos avis.

Chouaib

--
Chouaïb
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 13 juin 2017 - 07:53
Bonjour,

Petite question, qu'est-ce qui doit s'afficher sur ton appli ? Si tu dois récupérer 1000 lignes à chaque fois, ce sera juste impossible à travers un webservice qui n'est absolument pas fait pour ça.

S'il n'est pas question de poser les données chez le client alors la réplication n'est pas possible.

Il te reste dans ce cas l'appli web, pas de données chez le client, pas d'obligation de passe par WS si le volume de donnée est important.

--
Cordialement,

Philippe SAINT-BERTIN
Géode Informatique
Membre enregistré
248 messages
Popularité : +1 (1 vote)
Posté le 13 juin 2017 - 12:28
Merci Philippe pour ta réponse.
Mon Ws fonctionne tres bien car il ramène en tout et pour tout
Une et une seule chaine.
Cette chaine contient des sous-chaines séparées par un RC.
DONC chaque sous chaine est une ligne de la bd.
Je ramène au maxi. 80 lignes a la fois que j affiche dans une table graphisue
Sur smartphone ou tablette ou pc selon besoin.

--
Chouaïb
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 13 juin 2017 - 12:55
Comme le volume n'est pas trop important reste sur ton WS. L'idée de mettre un code société aux fichiers concernés est bonne et je dirais que c'est ce qu'il faut faire, en tout cas moi je le ferai comme ça également.

Ensuite les temps de réponse ne dépendent que du SGBD que tu utilises, du serveur sur lequel ça tourne et la complexité de la requête. Pour des requêtes simples HFSQL ne pose aucun problème même sur de grosses volumétries. Par contre si tes requêtes sont complexes (beaucoup de jointures, sous-requêtes,...) je pense que ce n'est plus le bon SGBD. Après cela ne reste que mon avis et n'engage que moi.

Le seul problème que je vois c'est pour les images. Si elles sont volumineuses, ça peut être long selon le type de connexion, notamment en mobilité, et tu risques le timeout.

--
Cordialement,

Philippe SAINT-BERTIN
Géode Informatique
Posté le 13 juin 2017 - 13:06
Haaa

c'était ce post la...

Pour compléter la réponse de Philippe, la question est complexe et la
réponse encore plus, et elle va dépendre de beaucoup de facteurs.

Mais je vais essayer de donner quelques éléments.

LE PROBLEME CLASSIQUE QUI SE POSE : qu'on sera t il des temps de réponse
en production avec des grosses tables ?


Ca dépend de plein de choses :
- ton code
- la puissance du serveur (et je ne sais pas du tout comment le cloud de
pcsoft est géré)
- la bande passante disponible entre le client et le serveur au MOMENT
de l'échange (ce qui est très souvent le facteur critique, surtout pour
les mobiles)
>

===============================
1) 1ère Solution nécessaire : j'augmente les ressources de la plateforme
Cloud au fur et à mesure de la taille de la BD :
je modifie l'abonnement sur le Cloud PC Soft,



Ca risque d'être nécessaire quelle que soit la solution technique
choisie... Ce n'est qu'au moment de l'exploitation que tu verras les
VRAI besoins.

D'où l'intéêt de choisir une solution facilement modulable.

===============================
2) La réplication :
J'ai vu dans différentes discussions sur ce forum que la réplication est
proposée.

Je ne connais pas le sujet mais il me semble que c'est compliqué dans
mon cas car :
- Les utilisateurs utilisent :
Soit un Smartphone, Soit une Tablette , Soit un PC = Software en 3
parties = Windev mobile Smartphone + windev mobile Tablette + Windev
Desktop sur PC.


Cette partie ne pose aucun problème pour un système comme WXReplication.

- Il n'est pas question d'installer une BD sur les PC de la société = le
but est que le poste client soit léger et aucune installation ou
configuration,


Il va bien falloir installer le soft, non ?
Si oui, le soft local peut utiliser une base HF classique locale (donc
sans aucune config) et faire sa réplication avec.

================================
3) plusieurs BD identiques (une par société) :
Je ne l'ai jamais fait :
- Comment générer plusieurs BD sur le Cloud avec une seule Analyse ?
-Comment se connecter à telle BD plutôt qu'à une autre selon le code
société ?
là j'ai une idée : tous les accès à la BD se font par des Web services
Windev : je peux centraliser le changement de base dans
une fonction du web service qui recevra le code société. mais je n'ai
pas d'exemple de code pour changer de BD.


Comme le disait Philippe : gros volume + Webservice + accès en temps
réel = problème.

Par contre, en réplication, plus de soucis, vu que les accès donnés sont
fait en local et transmis au serveur quand c'est possible.

================================
4) Garder la Méga BD unique mais décider de dégraisser les grosses tables :
càd que je peux décider d'archiver les lignes anciennes de plusieurs
mois dans des tables d'archives.
donc des tables en ligne moins grosses.
Mais il faut que je modifie mon code pour que :
les requêtes interrogent des données récentes et éventuellement proposer
d'aller interroger des données plus anciennes.


Si ton code et tes requêtes sont bien faits, l'augmentation de taille de
la BD n'augmentera pas les temps de réponse. Je dis bien -SI- !

=====================
DONC MES QUESTIONS :
=====================
- Quelqu'un a déjà une expérience d'interrogation de grosse base de
données sur le Cloud PC Soft ? et si oui quelles stats sur les temps de
réponse ? quels conseils ?


Pas spécifique au cloud de pcsoft que je n'ai jamais testé, mais en HF,
SI ton code et tes requêtes sont bien faits, les temps de réponse
n'augmentent pas de manière significative avec la taille de la BD.

Donc, la, je dis faux problème

- Avez vous d'autres solutions à me proposer ?
- que pensez vous de mes propositions de solutions ?


Perso, je ferais :
- réplication partout. Ca résoud le problème des volumes de données qui
sont écrites sur le serveur quand c'est possible, ca ne transmets -QUE-
les données modifiées, ce qui réduit les besoins en bande passante, et
même si tu as une seule BD, tu ne vas bien sur répliquer que les données
du clients en descente.

- de ce fait, à la base, une seule base de données serait nécessaire...
Mais en fonction des volumes, ca pourrait changer.

- Ce changement peut être du au fait de l'augmentation du volume des
connections (trafic) et pas des données.

- si changement nécessaire, voila comment je résous ce genre de problèmes :
1. Le client (mobile ou windows, peut importe) se connecte une première
fois. Il lui faut donc un identifiant pour indiquer quel
client/groupe/BD est concerné
2. Le serveur de base (adresse fixe), une fois que le client est
identifié, lui renvoie UNE ou DES adresses IP de serveur secondaires à
utiliser.
3. Le client conserve ces infos dans sa bases et utilise cette ou ces
adresses dans le futur.
4. La possibilité d'avoir PLUSIEURS adresses IP permets de faire du load
balancing soft entre plusieurs serveurs répliqués entre eux. Ca permet
aussi de passer à un autre serveur si l'un d'entre eux est en maintenance.
5. Si aucune des adresses IP secondaires ne répond, le client se
reconnecte au serveur de base et signale le problème + demande d'autres
IP. Si c'était juste un changement de serveur, il les obtient, si
c'était une panne, il est mis en attente.

Ce système permet une modification en temps réel des accès aux
serveurs/bases en fonction de l'EVOLUTION des besoins.

Et bien sur, c'est de l'overkill total dans certains cas (dont peut être
le tien, encore une fois).

Pour info, ce système n'est PAS implémenté dans la version actuelle de
WXReplication. Il est implémenté dans un projet privé basé sur
WXReplication.

Voila, quelques pistes de réflexion.

Cordialement


--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International

A votre disposition : WXShowroom.com, WXReplication (open source) et
maintenant WXEDM (open source)

Plus d'information sur http://fabriceharari.com

Merci d'avance de vos avis.

Chouaib

--
Chouaïb
Membre enregistré
248 messages
Popularité : +1 (1 vote)
Posté le 13 juin 2017 - 14:58
Merci Fabrice pour cette longue et complète réponse.
=================================
Je ne suis pas tout à fait pour la réplication car :
=================================

Je n'ai pas beaucoup de mises à jour sur les Smartphones et les tablettes.

Exemples de traitements
==================================
1) A un instant t : dans une société : il peut y avoir jusqu'à 1500 collaborateurs qui signalent leur présence par une connexion qui dure une minute.
Chaque collaborateur va générer une ligne ajoutée dans une table.

2) Possibilité qu'à cet instant t, plusieurs collaborateurs de plusieurs sociétés (par exemple 50 sociétés : 50 x 1500 connexions et 50 x 1500 lignes ajoutées)

3) le reste du temps, un collaborateur peut une ou deux fois par jour : interroger son planning ou voir les commentaires de ses clients :
on ramène au maximum 100 lignes sur le Smartphone. s'il reste 5 min à regarder ses lignes c'est un max.

4) Les tablettes utilisées dans la société en interne : ont besoin d'avoir en instantané, le signalement des présences des collaborateurs.
Donc il n'est pas possible d'avoir un temps de latence même de quelques minutes?

Les tablettes ne servent qu'à vérifier ces présences 2 à 4 fois par jour. chaque tablette interroge un département à la fois (50 collaborateurs maxi.)
Donc interrogation de 50 lignes maxi et mise à jour de 50 lignes maxi.

5) Les PC : dans une société, il y aura au maximum 4 personnes qui interrogent et mettent à jour la BD :
Justifier des absences, ajouter des commentaires. Pas de mises à jour lourdes.

6) Les Photos des collaborateurs et les justificatifs ne sont pas amenés immédiatement sur les tablettes ou sur les PC :
Par exemple : lorsque j'amène des infos sur 50 collaborateurs dans une table graphique sur tablette, j'attends que le user sélectionne un collaborateur, pour aller chercher sa photo par WS,
=====================
TRES IMPORTANT AUSSI :
=====================
Aucune Appli (Smartphone ou Tablette ou PC) ne lance des requêtes SQL sur la BD directement.
Elles appellent des fonctions du WS en passant des paramètres. La fonction du WS renvoie une chaine variable (plusieurs sous chaînes séparées par RC)
Donc c'est le WS qui se trouve sur le Cloud qui lance des requêtes sur la BD HyperFile qui est elle même sur le Cloud.

=======================
DONC mon vrai souci est :
========================
Est ce qu'une requête stockée sur le cloud et qui est exécutée sur la BD du Cloud : deviendra trop lente au fur et à mesure que les tables grossissent
Evidemment, je mets des clés uniques et en doublon sur les critères de recherche de ma requête.
========================
Comme je l'ai dit au début du post :
JE VAIS CREER UN JEU D'ESSAI avec des tables de 200 000 ou 300 000 lignes et les interroger par Smartphone / tablette et voir.

=======================
J'espère que j'ai apporté des éléments à la discussion.

N'hésitez pas à relever des problèmes ou contradictions dans mon argumentation ou me donner plus de conseils.

Merci d'avance pour votre aide que j'espère peut aussi aider d'autres.

Cordialement

--
Chouaïb
Posté le 13 juin 2017 - 15:51
Bonjour,


ok then... on dirait que tu as déjà pris tes décisions et que tu cherche
des gens qui sont d'accord avec toi...

Je vais essayer, mais je promets rien :

Le 6/13/2017 à 6:58 AM, ChouLAGH a écrit :
Merci Fabrice pour cette longue et complète réponse.
=================================
Je ne suis pas tout à fait pour la réplication car :
=================================

Je n'ai pas beaucoup de mises à jour sur les Smartphones et les tablettes.

Exemples de traitements
==================================
1) A un instant t : dans une société : il peut y avoir jusqu'à 1500
collaborateurs qui signalent leur présence par une connexion qui dure
une minute.
Chaque collaborateur va générer une ligne ajoutée dans une table.

2) Possibilité qu'à cet instant t, plusieurs collaborateurs de plusieurs
sociétés (par exemple 50 sociétés : 50 x 1500 connexions et 50 x 1500
lignes ajoutées)

3) le reste du temps, un collaborateur peut une ou deux fois par jour :
interroger son planning ou voir les commentaires de ses clients :
on ramène au maximum 100 lignes sur le Smartphone. s'il reste 5 min à
regarder ses lignes c'est un max.

4) Les tablettes utilisées dans la société en interne : ont besoin
d'avoir en instantané, le signalement des présences des collaborateurs.
Donc il n'est pas possible d'avoir un temps de latence même de quelques
minutes?

Les tablettes ne servent qu'à vérifier ces présences 2 à 4 fois par
jour. chaque tablette interroge un département à la fois (50
collaborateurs maxi.)
Donc interrogation de 50 lignes maxi et mise à jour de 50 lignes maxi.

5) Les PC : dans une société, il y aura au maximum 4 personnes qui
interrogent et mettent à jour la BD :
Justifier des absences, ajouter des commentaires. Pas de mises à jour
lourdes.

6) Les Photos des collaborateurs et les justificatifs ne sont pas amenés
immédiatement sur les tablettes ou sur les PC :
Par exemple : lorsque j'amène des infos sur 50 collaborateurs dans une
table graphique sur tablette, j'attends que le user sélectionne un
collaborateur, pour aller chercher sa photo par WS,
=====================
TRES IMPORTANT AUSSI :
=====================
Aucune Appli (Smartphone ou Tablette ou PC) ne lance des requêtes SQL
sur la BD directement.
Elles appellent des fonctions du WS en passant des paramètres. La
fonction du WS renvoie une chaine variable (plusieurs sous chaînes
séparées par RC)
Donc c'est le WS qui se trouve sur le Cloud qui lance des requêtes sur
la BD HyperFile qui est elle même sur le Cloud.


Tu as annoncé 200 000 écritures par jour, ca a l'air d'être en
contradiction avec ce que tu décrit maintenant.

Ceci dit, avec ce que tu décris, qui est maintenant devenu très léger,
un accès en direct devrait être possible à travers ton webservice.


=======================
DONC mon vrai souci est :
========================
Est ce qu'une requête stockée sur le cloud et qui est exécutée sur la BD
du Cloud : deviendra trop lente au fur et à mesure que les tables
grossissent


Pas si la structure de la base, les clés, et les requêtes utilisées sont
bien faîtes. J'ai travaillé sur des bases de plusieurs 10zaines de GO
sans aucun ralentissement.

Bien entendu, si dans tes traitements tu DOIS faire des calculs sur
l'ensemble des enreg d'un fichier, il faudra mettre en place un système
de calculs intermédiaires pour ne pas avoir des temps de traitement qui
augmentent...

Encore une fois, ca dépend de toi.

Evidemment, je mets des clés uniques et en doublon sur les critères de
recherche de ma requête.


Ce qui n'est PAS la solution optimum. La solution optimum est de créer
une clé COMPOSEE utilisable par la requête avec un maximum de
discrimination et de ne PAS avoir de clé unique et doublon en plus sur
les différents critères, de manière à FORCER le moteur à utiliser la clé
qui est optimale pour la LOGIQUE de ton projet.


Cordialement


--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International

A votre disposition : WXShowroom.com, WXReplication (open source) et
maintenant WXEDM (open source)

Plus d'information sur http://fabriceharari.com

========================
Comme je l'ai dit au début du post :
JE VAIS CREER UN JEU D'ESSAI avec des tables de 200 000 ou 300 000
lignes et les interroger par Smartphone / tablette et voir.

=======================
J'espère que j'ai apporté des éléments à la discussion.

N'hésitez pas à relever des problèmes ou contradictions dans mon
argumentation ou me donner plus de conseils.

Merci d'avance pour votre aide que j'espère peut aussi aider d'autres.

Cordialement

--
Chouaïb
Membre enregistré
248 messages
Popularité : +1 (1 vote)
Posté le 14 juin 2017 - 15:58
Merci encore Fabrice pour tes réponses.

================================
1) Non les 200 000 enreg que j'ai annoncés restent toujours valables et même dépassés.
J'ai raisonné sur 1500 collaborateurs de 50 sociétés et un signalement de présence par jour.
Or cela peut devenir (si le produit marche bien) :
100 sociétés x 1500 collaborateurs x 4 signalements par jour = 600 000 lignes !!!
================================
2) Non je n'ai pas de calculs complexes : donc ce n'est pas un facteur aggravant
================================
3) J'ai appris quelque chose sur les clés composées.
Moi je les utilise pour faire une unicité sur plusieurs rubriques.
Mais si cela en plus optimise les requêtes : alors oui, je vais modifier mes requêtes.
===============================
4) DONC les idées deviennent plus claires pour moi :
J'aurai une grosse BD sans trop de calculs complexes, des requêtes effectuées sur le Cloud et pas sur les postes clients, des interrogations
ou mises à jour qui ne concernent pas des centaines de lignes,
Donc je vais augmenter au fur et à mesure les ressources sur le Cloud (capacité stockage, vitesse de transfert, nombre de connexions,....)
et optimisez mes requêtes
================================
5) Je vas bientôt procéder à un test avec un jeu d'essais pour simuler une grosse BD
Je reviendrai donner les résultats de mes tests,
Soit pour en discuter, Soit pour laisser une trace pour d'autres développeurs.

Encore Merci Fabrice pour le temps que tu as bien voulu accorder à ce sujet.

--
Chouaïb
Posté le 14 juin 2017 - 16:25
Bonjour,

3) J'ai appris quelque chose sur les clés composées.
Moi je les utilise pour faire une unicité sur plusieurs rubriques.
Mais si cela en plus optimise les requêtes : alors oui, je vais modifier
mes requêtes.


Sur ce point, il faut précise que la construction de ta clé composée
dépend directement des conditions de ta requête...

Pour optimiser la vitesse de lectures de données, le premier champ de la
clé composée doit être le plus discriminant possible, donc :
- si possible une condition de type =
- et si il y a plusieurs conditions =, celle qui logiquement retournera
le moins de réponses (par exemple =date est mieux en général que =vrai
ou faux, sauf bien sur si il n'y a que 3 faux dans le fichier et que la
requête demande TOUJOURS = faux

De la même manière, le choix du deuxième élément doit aussi être fait
pour discriminer au maximum.

Ce qui prend du temps et qu'on peut éliminer, c'est de parcourir les
arbres binaires de l'index pour éliminer les enregs qui ne correspondent
pas aux autres conditions...

En forçant le moteur de la base à utiliser une clé composée très
discriminante sur les premiers champs, on fait exactement ça.

Cordialement


--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International

A votre disposition : WXShowroom.com, WXReplication (open source) et
maintenant WXEDM (open source)

Plus d'information sur http://fabriceharari.com
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 14 juin 2017 - 17:04
Bonjour,

Là en l'occurrence, le problème que tu vas rencontrer n'est pas la taille de la base, mais le nombre de connexions entrantes sur ton WS. C'est là que ça peut coincer, donc si tu fais les tests seul, même sur une base d'1 To, tu ne simuleras pas le nombre de connexion réelles.

--
Cordialement,

Philippe SAINT-BERTIN
Géode Informatique
Membre enregistré
248 messages
Popularité : +1 (1 vote)
Posté le 14 juin 2017 - 17:17
Oui c'est vrai.
Y a t il une solution qui permet les simulations de connexions ?

--
Chouaïb