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

  1. #1
    Nouveau Candidat au Club
    Quel langage ? Grosse base SQL, jointure, machine learning et data science
    Bonjour à tous !

    Je fais un petit tour ici car j'ai besoin de vos lumières Je vous explique mon problème.

    J'ai accès à une base (SQL) depuis mon poste de travail, en odbc. Je n'ai que les droits de lecture sur cette base. Il s'agit d'une base avec pas mal de tables, de plus centaines de millions, voire milliards de lignes. A partir de cette base, je voudrais faire la chose suivante :
    1. faire quelques jointures sur les tables pour obtenir une table de travail intéressante
    2. A partir de cette table, entamer un travail de statistiques simples ou machine learning, bref, m'amuser avec

    Jusqu'à présent, je réalise la première étape sous SAS. C'est triste, c'est un langage que je n'aime pas trop, mais il répond à mon besoin : il arrive à joindre les tables, à me les ramener, et cela remplit mon étape 1. Alternativement, j'ai essayé Python et R (nettement plus pratiques pour ce que je veux faire après...), mais ils montent la base en RAM, et la RAM, vue la taille des bases, elle sature...

    Ma question (il y en a deux, mais c'est la même):
    - est-ce que je m'y prends mal, et R comme Python sont capables de gérer de grosses jointures sans tout monter en RAM ?
    - sinon, vers quel langage est-ce que je devrais me tourner ? Je lis que Julia semble bien traiter les grosses bases, mais mon problème est dès la création... Ou alors je devrais créer une base SQL sur mon pc, ramener les données dedans ?

    Bref, je suis preneur d'idées ! Pas sûr d'être dans le bon endroit du forum, désolé si je me trompes

    Merci beaucoup par avance pour toute aide !

  2. #2
    Expert éminent sénior
    Citation Envoyé par in_the_dark Voir le message
    - est-ce que je m'y prends mal, et R comme Python sont capables de gérer de grosses jointures sans tout monter en RAM ?
    R et Python n'ont rien à voir là-dedans , les jointures se font grâce au moteur du SGBDR.
    L'interface entre le langage de programmation qui produit du binaire et la base de données c'est ODBC qui permet de réaliser les opérations en base de données ( principalement par des curseurs).
    Après le moteur de requête du SGBDR construit des arbres binaires de recherche en interne mais ça c'est un autre sujet
    Si je fais SELECT customer_name FROM db_customers, Python ne sait pas ce qu'est cet ordre il le délègue au moteur de requêtes de la bdd.
    Ensuite affirmer base SQL ça ne veut rien dire, il faut préciser: Oracle,MySQL, SQL-Server ?
    Citation Envoyé par in_the_dark Voir le message

    - sinon, vers quel langage est-ce que je devrais me tourner ?
    la réponse est évidente il faut utiliser un SGBDR permettant les procédures stockées bref du code s'exécutant côté base de données.
    Et les SGBDR qui permettent cela sont coûteux niveau finance, que ce soit Oracle ou SQL-Server.
    Sous Oracle c'est le PL-SQL sous SQL-Server c'est le Transact-SQL.

    Cependant il peut y avoir des alternatives aux bases étant gérées par des ordres SQL,il y a les bases NoSQL.
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  3. #3
    Nouveau Candidat au Club
    Un grand merci pour cette réponse !

    Quelques questions bonus

    R et Python n'ont rien à voir là-dedans , les jointures se font grâce au moteur du SGBDR.
    L'interface entre le langage de programmation qui produit du binaire et la base de données c'est ODBC qui permet de réaliser les opérations en base de données ( principalement par des curseurs).
    Après le moteur de requête du SGBDR construit des arbres binaires de recherche en interne mais ça c'est un autre sujet
    Si je fais SELECT customer_name FROM db_customers, Python ne sait pas ce qu'est cet ordre il le délègue au moteur de requêtes de la bdd.
    Ok, donc je comprends que R ou Python ne font qu'envoyer une instruction (la même en l'occurence), et qu'ensuite c'est le SGBDR qui travaille. Ce qui m'étonne ceci dit, c'est que ma requête aboutit dans SAS, pas dans R ni Python pour un problème de mémoire. Cependant, si j'ai bien compris, ma table est bien créée (par exemple la table issue de SELECT customer_name FROM db_customers) par le SGBDR, et ensuite le problème que j'ai avec R ou Python c'est qu'il n'arrive pas à la ramener chez moi, c'est ça, alors que SAS y parvient ? ce qui voudrait dire que la solution serait d'avoir les droits d'écriture sur le serveur pour la stocker là bas, ou y a t'il une alternative ?

    Ensuite affirmer base SQL ça ne veut rien dire, il faut préciser: Oracle,MySQL, SQL-Server ?
    a réponse est évidente il faut utiliser un SGBDR permettant les procédures stockées bref du code s'exécutant côté base de données.
    Et les SGBDR qui permettent cela sont coûteux niveau finance, que ce soit Oracle ou SQL-Server.
    Sous Oracle c'est le PL-SQL sous SQL-Server c'est le Transact-SQL.

    Cependant il peut y avoir des alternatives aux bases étant gérées par des ordres SQL,il y a les bases NoSQL.
    D'après ma compréhension (ce n'est pas moi qui gère la base), c'est du SQL-Server derrière. Donc si je comprends bien le moyen le plus rapide serait de taper directement la requête en SQL, en utilisant le transact-SQL c'est ça ? Pas d'alternative pour faire ça depuis autre chose ? Le côté NoSQL nécessiterait un changement de l'organisation de la base c'est bien ça?

    Désolé pour ces questions de béotien, et merci beaucoup !

  4. #4
    Expert éminent sénior
    rebonjour
    Citation Envoyé par in_the_dark Voir le message
    Ce qui m'étonne ceci dit, c'est que ma requête aboutit dans SAS, pas dans R ni Python pour un problème de mémoire.
    je pense que l'explication que l'on peut donner c'est que SAS lance des requêtes dans des threads séparés.
    Ce qui peut être certainement possible avec Python.
    Je ne pense pas que ça soit un problème de mémoire et ce genre de message c'est un message générique
    Citation Envoyé par in_the_dark Voir le message

    Cependant, si j'ai bien compris, ma table est bien créée (par exemple la table issue de SELECT customer_name FROM db_customers) par le SGBDR, et ensuite le problème que j'ai avec R ou Python c'est qu'il n'arrive pas à la ramener chez moi, c'est ça, alors que SAS y parvient ?
    SAS doit gérer les multiconnections de base.
    Les langages lambda comme Python ne le font pas il faut tout créer par soi-même par du code.
    Par contre je ne comprends pas la structure est-ce qu'il y a deux bases de données ?

    Citation Envoyé par in_the_dark Voir le message
    ce qui voudrait dire que la solution serait d'avoir les droits d'écriture sur le serveur pour la stocker là bas, ou y a t'il une alternative ?
    oui certainement
    Citation Envoyé par in_the_dark Voir le message


    D'après ma compréhension (ce n'est pas moi qui gère la base), c'est du SQL-Server derrière. Donc si je comprends bien le moyen le plus rapide serait de taper directement la requête en SQL, en utilisant le transact-SQL c'est ça ? Pas d'alternative pour faire ça depuis autre chose ? Le côté NoSQL nécessiterait un changement de l'organisation de la base c'est bien ça?
    oui avec des procédures stockées ça va plus vite.
    Et passer à du NoSQL revient à changer de base.
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

###raw>template_hook.ano_emploi###