IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

NoSQL Discussion :

Choix d'outil pour l'analyse de données


Sujet :

NoSQL

  1. #1
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut Choix d'outil pour l'analyse de données
    Bonjour

    Je cherche quel outil choisir pour faire des tableaux de bord quotidien, hebdo, mensuel, annuel, etc. sur une base Mongo contenant des "document" d'activité (qui a fait quoi et quand).
    Chaque document est un ensemble de clefs et valeurs de type time, string, int (des types simples)
    il existe un groupe de clefs communes à tous les documents
    et des clefs dépendant de l'activité tracée.

    Mon besoin est de produire des tableaux de bord généraux (concernant les éléments communs dans tous les documents) par exemple un graphe donnant le nombre d’événements par minutes, origine, et nature.

    J'ai déjà ce genre de chose sous oracle, mais le relationnel n'est clairement pas le bon choix. La table des événements ne peut contenir que les colonnes communes, les autres étant dans une table id parent nom de clef valeur
    la volumétrie est telle que même avec des partitions par date origine, etc nous sommes contraints de garder que 12 jours. (on ne refait pas l'histoire)
    Reprendre mon code java qui fait ça à partir d’Oracle pur le faire à partir de mongo n'est et pas un problème.

    Mais je pense que ce n'est pas une bonne approche.
    Coder en java des tableaux de bord n'offre pas beaucoup de souplesse.

    Cela ne permet pas de répondre à des besoins plus occasionnels
    Si je prends par exemple le circuit de la logistique chaque application impliquée va remonter des événements sur sa propre activité dans tous ces événements s'il concerne une commande il y a un champ N° commande présent

    Il serait intéressant de pouvoir retracer toutes les activités datées de toutes les applications qui ont fait quelque chose concernant une commande.

    En temps normal on ne fait pas de tableau de bord pour un élément, mais dans certaines circonstances ...

    Bref des outils dédiés à analyser les données sont plus en adéquation avec les besoins occasionnels qui surgissent souvent.
    Le besoin est donc très général. Il concerne environ 1000 applications qui travaillent de concert dans des métiers très variés.

    Le besoin est de pouvoir fournir des tableaux de bord qui montre l'évolution générale du système, mais aussi de pouvoir extraire des éléments très détaillés comme tracer le parcours d'un objet.

    Je ne suis pas un spécialiste de ce genre d'outils. Le choix de la base n'est pas arrêté, mais il est clair que pour stoker des paquets de JSON le relationnel n'est pas le plus adapté.
    La production des données d'événement et leur stockage ne sont absolument pas un problème, c'est plutôt le choix des outils d'exploitation qui déterminera le choix du stockage.

    Merci de votre aide.
    A+JYT

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    As tu essayé sous SQL Server avec des tables in memory ou de l'indexation verticale columstore ?

    J'ai sauvé récemment un projet comme cela.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 352
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 352
    Points : 20 359
    Points
    20 359
    Par défaut
    Citation Envoyé par sekaijin Voir le message
    Mais je pense que ce n'est pas une bonne approche.
    Coder en java des tableaux de bord n'offre pas beaucoup de souplesse.
    regarder l'API ODBC et donc JDBC c'est une API très performante.
    Citation Envoyé par sekaijin Voir le message
    Le besoin est donc très général. Il concerne environ 1000 applications qui travaillent de concert dans des métiers très variés.
    il serait temps de fusionner tout cela sous un ERP

  4. #4
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    bonjour et merci
    sorry pour la réponse tardive.

    Il est clair que SQL n'est pas la solution même avec des bases en mémoire.

    JDBC est performant mais ce qui bloque ce n'est pas la communications entre le soft et la base c'est la base elle même.

    Faire du clef/valeur dans une base relationnelle n'a pas beaucoup de sens. et quand la volumétrie devient gigantesque c'est un frein térible.

    Donc le choix du NoSQL sur une base clef::valeur ou document est bien plus pertinante. déjà à l'écriture nous avons un raport de 1 à 10000 ce qui est logique là ou ont génère un id pour un insert dans la table principale puis on génère N id pour chaque clef uis on insère l'élément dans la table principale puis on insère chaque couple clef valeur
    on insère 1 document.

    Reste à exploiter les données.

    @Mat.M Je ne connais pas un seul ERP capable de rémplacer les applications métier de touts les métiers.

    A+JYT

Discussions similaires

  1. Réponses: 4
    Dernier message: 03/02/2011, 15h15
  2. [Projet BI] Choix des outils pour un projet BI
    Par Medmidou dans le forum Approche théorique du décisionnel
    Réponses: 2
    Dernier message: 07/04/2009, 20h06
  3. recherche d'un sujet pour une analyse de donnée
    Par Sarah! dans le forum Statistiques, Data Mining et Data Science
    Réponses: 8
    Dernier message: 08/01/2009, 19h18
  4. [REQ] Choix d'outil pour dév. C sous Windows
    Par emit-fr dans le forum Autres éditeurs
    Réponses: 2
    Dernier message: 19/12/2008, 09h23
  5. Choix d'outils pour package Web
    Par Paul-nexance dans le forum Général Conception Web
    Réponses: 1
    Dernier message: 03/07/2006, 02h24

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo