Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manage external tables for table creation rules #501

Open
marcboulle opened this issue Dec 17, 2024 · 0 comments
Open

Manage external tables for table creation rules #501

marcboulle opened this issue Dec 17, 2024 · 0 comments
Assignees
Labels
Priority/1 To do after P0 Size/Weeks needs some weeks (big) Type/Enhancement New feature or request

Comments

@marcboulle
Copy link
Collaborator

Description

La création d’instances peut entrainer une charge mémoire complexe à prévoir, notamment dans la cas de la création de table, dont le nombre d’instances dépendant des données des bases en entrée.
Le problème de dimensionnement des ressource se pose notamment dans le cas de tables externes, qu'il faut charger intégralement en mémoire, et qui peuvent impliquer des instances créées par des règles de création de tables.

Analyse du problème

Cas des instances des tables externes

  • Le cas des instances de tables externes est complexe, car l’ensemble des instances des tables externes doit être chargé en mémoire, y compris pour leur structure en flocon
    • En effet, une instance d’analyse peut référencer une ou plusieurs instances externes (par exemple une référence à un produit dans chaque log d’achat d’un client)
    • Et depuis cette instance externe accéder potentiellement à ses sous-tables
  • Il est nécessaire de dimensionner a priori la mémoire occupée par le chargement de l’ensemble des table externes
    • Pour dimensionner correctement la tâche en cours : savoir a priori si on peut lancer la tâche, et savoir combien d’esclave on peut lancer simultanément, compte tenu de la RAM disponible
  • Cette estimation est déjà effectuée, avec une fiabilité « raisonnable » compte tenu des usages actuelle des tables externes
    • Cf. classe KWMTDatabase
      • ComputeOpenNecessaryMemory
        • Pilotage du dimensionnement global
      • ComputeSamplingBasedNecessaryMemoryForReferenceObjects
        • Dimensionnement « réaliste » sur la base d’un échantillon des tables externes
      • ComputeNecessaryMemoryForReferenceObjects
        • dimensionnement heuristique sans lecture des données
  • L’implémentation actuelle, bien que précautionneuse, n’est pas robuste au cas d’instance éléphants dans les tables externes, et pourrait échouer en erreur fatale (manque de RAM) si une instance éléphant est présente hors de l’échantillon utilisé pour le dimensionnement
  • Dans le cas de la création de table, ce problème est accru
    • Problème grave (erreur fatale potentielle)
    • Mais rare : table externe peu utilisée, et instances éléphant dans les tables externes peu probables
  • Problème à résoudre néanmoins

Solutions envisagées

Solution par limitation de l’expressivité des dictionnaires des tables externes

  • Il s’agit de contraindre l’expressivité de des calcul dans les tables externes pour en faciliter le dimensionnement
  • Inconvénient : complexe à gérer, à la fois pour les utilisateur de Khiops, et pour l’implémentation

Solution par nettoyage adaptatif

  • exploiter les mécanisme de protection contre les instances éléphants dans le chargement des tables externe
  • garder le dimensionnement heuristique selon l’échantillonnage pour réserver un espace mémoire dédié au chargement des tables externes
  • charger le maximum d’instances externe en mémoire, en ignorant les instances les plus volumineuse, avec warning utilisateur
  • inconvénient pour l’utilisateur : le résultat dépend des ressources mémoires

Solution par auto-adaptation des ressources

  • Suite au dimensionnement heuristique, charger le maximum d’instances externes en mémoire, et s’arrêter quand on a dépassé les ressources
  • Si ceci est effectué dans un esclave par exemple, rendre une nouvelle estimation des ressources nécessaires et recommencer les traitement sur la base du nouveau dimensionnement
  • Inconvénient : complexe à implémenter

Solution retenue

Solution par estimation exacte des ressources nécessaires

  • Dimensionner en utilisant 100% des instances externes, au lieu d’une estimation heuristique basé sur un échantillon
    • Arrêt potentiel si au fur et à mesure si on dépasse toute la RAM disponible
  • Avantage :
    • traitement rigoureux et exacte du problème de dimensionnement
    • coût d’implémentation faible
  • Inconvénient
    • On va charger les tables externes deux fois en mémoire, une fois pour le dimensionnement (dans le maitre), une fois pour les traitements (dans chaque esclave, comme c’est déjà le cas)
    • Mais ce n’est pas trop grave
      • Cas des tables externes volumineuse assez rare
      • Temps de chargement des tables externes faible devant les temps de traitement dans la plupart des cas
      • Au pire, un facteur deux en temps de calcul, si tout le temps est pris par le chargement en mémoire des tables externess
  • Solution retenue
    • Bon compromis entre fiabilité de la solution, simplicité de l’implémentation, et surcoût en temps d’implémentation

Context

  • Khiops version: après V11
@marcboulle marcboulle added Type/Enhancement New feature or request Priority/1 To do after P0 Size/Days Some days of work labels Dec 17, 2024
@marcboulle marcboulle self-assigned this Dec 17, 2024
@marcboulle marcboulle changed the title Manage external tables for table craation rules Manage external tables for table creation rules Dec 17, 2024
@marcboulle marcboulle added Size/Weeks needs some weeks (big) and removed Size/Days Some days of work labels Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority/1 To do after P0 Size/Weeks needs some weeks (big) Type/Enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant