Forum Linux.général temps d'acces fichier ou bdd

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
26
juin
2020

bonjour,
à supposer que j'ai un repertoire bd avec 1 millions de sous-repertoire contenant chacun 20 fichiers
à supposer que j'ai une base de données avec 1 millions d'identifiant uniques liés chacun à 20 tables
est ce que le temps d'accès est plus rapide avec une base de données?
objectivement, pour un programme qui utilise l'un ou l'autre pour des données "intermédiaires" de stockages quel est l'avantage de la base de données?

  • # du bon usage du stockage de données

    Posté par  . Évalué à 1. Dernière modification le 27 juin 2020 à 06:09.

    un sgbd, si j'ai bien compris, compresse les données ( ± les structures en double sont référencées) dans le but de minimiser les temps de recherche/affichage*, ainsi que l'espace de stockage proprement dit.

    *mais c'est proportionnel à la quantité de données stockées :
    peu de données : peu de gain !

    après, un sgbd plutôt qu'un autre…
    sqlite implémente moins d'instructions - ça rend son chargement plus rapide … ?

  • # recherche complex

    Posté par  . Évalué à 4.

    Pour les systemes d'exploitation comme ca prend du temps de tout parcourir, ils ont crée une … bd pour faire des recherche très vite :).

    si tu as un linux tu peux lancer des recherches sur / pour te rendre compte avec un find bien lourd.

    pour faire une analogie un peu foireuse, c'est comme si tu parcourais une grosse ville pour trouver le nom Kr1p sur une boite au lettre pour trouver son adresse, et la bd c'est un annuaire, tu cherche le nom et tu as l'adresse yapluka aller directement à la boite au lettre.

    après dans un petit village de 10 habitant, tu peux faire les trajet a pied sa ira plus vite

    • [^] # Re: recherche complex

      Posté par  . Évalué à 2.

      Salut,

      pour faire une analogie un peu foireuse

      Au risque de te décevoir, je la trouve pas si foireuse que ça, ton analogie.

      Bien sûr, elle n'explique pas tout, mais c'est imagé :)

      Matricule 23415

  • # Modèle relationel, Structuration des données et filtrage

    Posté par  . Évalué à 2.

    J'essaye de vulgariser en ne parlant que du relationnel :

    Une petite base comme SQLLite t'offre des fonctions de qui permettent d'assurer la non redondance d'information, les liens entre les tables, des données structurées par champs pour chaque table, les filtrages avancées des données via SQL et plein d'autre chose comme de la manipulation de données géographique.

    Une base de données comme PostgreSQL permet un accès aux données par plusieurs programme en simultannée, permet la redondance des données sur plusieurs serveur

    Bref, si ton stockage est basique et le restera (tu parles de données intermédiaire), un stockage sur disque est suffisant.

    Si tu sens que tes données seront manipulée et nécessite du contrôle de cohérence et du filtrage avancé, mais qu'un seul process accède uen base donnée fichier comme sqlite peut être une solution

    Si il y a accès par plusieurs process (et redondance et de la perf), fonce sur les base de type postgresql.

    • [^] # Re: Modèle relationel, Structuration des données et filtrage

      Posté par  . Évalué à 2.

      Salut,

      Tout dépend du problème initial. Et là je ne suis pas certain de l'avoir bien lu.

      Du relationnel, ça fait plein de choses bien. Mais si on veut faire de la recherche full text par exemple, il y a d'autres solutions plus spécifiques, souvent à base d'index inversé. ;)

      Matricule 23415

      • [^] # Re: Modèle relationel, Structuration des données et filtrage

        Posté par  . Évalué à 1.

        Oui, bien sur, mais bon le confort d'une petite base de donnée pour persister de la donnée structurée c'est top.

        Effectivement en général, si la donnée est n'est pas structurée (vraiment pas hein, maintenant les bases SGBD arrivent à parser du JSON de nos jours). Le stockage fichier ou une base noSQL est une solution.

        • [^] # Re: Modèle relationel, Structuration des données et filtrage

          Posté par  . Évalué à 2.

          Salut,

          mais bon le confort d'une petite base de donnée pour persister de la donnée structurée c'est top.

          Je dérive un peu (et ça, ça ne répondra pas à la question initiale de l'OP).

          J'aime bien les SGBD pour plein de choses. C'est super puissant de manière générale.

          Mais même si je ne suis pas un spécialiste, il peut y avoir des petits écueils. Comme quand tu arrive dans la phase de modélisation à une relation de type "spatio-temporelle". Là, le moteur peut coincer un peu, il est pas prévu pour ce genre de choses.

          Donc ça dépend du besoin. Parfois un SGBD usuel va faire très bien le boulot, parfois il faut repenser la modélisation de la structure de donnée, parfois il faut passer à des outils spécifiques. ;)

          Matricule 23415

  • # Du bon usage de...

    Posté par  . Évalué à 1.

    Cela va dépendre, comme dis dans d'autres commentaires, de ce que tu veux faire des données (recherche ? croisement ? agrégation ? ) et de comment tu souhaites y accéder (a distance ? plusieurs clients simultanés ? requetes transactionnelles ?), mais dans l'exemple, a supposer qu'un filesystem sache gérer un répertoire contenant 1 000 000 de sous répértoires, un acces unitaire à 20 fichiers sera plus rapide que d'accéder à la BD sous certaines conditions :
    - pas d'accès concurrent (un seul client à la fois)
    - disque dur avec des IO suffisantes
    - pas de gestion des transactions

    Si ce sont des données "intermédiaires", et qu'elles sont plutot volatiles (genre tu les traites et tu les effaces apres), peut etre qu'une BD relationnelle n'est pas faite pour ca (réindexation inutile). Ce genre de "sparse file" est plutot destiné à des FS.

  • # Il manque trop d'informations pour donner une réponse

    Posté par  . Évalué à 3.

    Hello,
    à mon avis c'est quasi impossible de répondre d'un point de vue théorique … et c'est là qu'on entre très rapidement dans un métier : ARCHITECTE base de données ou ARCHITECTE infra.

    Pourquoi parler d'architecture ? hé bien imaginons que tu me confie la mission de rendre le plus rapide possible l'accès à tes données et que mon seul outil est un filesystem je vais donc découper le millions de sous répertoire dans une arborescence qui favorise la recherche SELON le critère de recherche que tu veux.

    Exemple: le stockage du cache de squid

    Et là tu peux voir que s’il y a 5 critères de recherches c'est la merde :) Où que le sous-entendu de "1 million de sous-répertoire" était "un seul niveau d'arborescence" … moi j'ai compris qu'on avait 1 million de sous-répertoires sans "profondeur maximale".

    Mais si tu me dis qu'il y aurait plusieurs critères de recherches là c'est clair et net que soit je me joue la vie à faire des arborescences avec des symlinks et à maintenir à jour l'ensemble de l'arborescence (quand on a pas de base de données on fait avec les moyens du bord) … soit très rapidement je vais créer des fichiers d'index (textes bruts) qui contiendront le nom du fichier et le champ de recherche comme ça pour trouver ton fichier il faudra faire "grep mot-clé index_par_titre" ou "grep mot-clé index_par_rédacteur" et ainsi de suite … faire un fichier d'index sur un filesystem c'est vraiment utiliser des idées de la base de données sans en avoir les outils.

    Idem, quelle quantité de RAM disponible ? si possible de mettre les fichiers d'index en RAMFS ça deviens drôle.

    Ou quel moteur de base de données si tu veux faire de la bdd ?

    Alors voilà à mon avis il n'y a pas de réponse définitive, tout est à mettre entre les mains d'architectes qui sauront trouver la bonne solution adaptée au problème précis.

    Pas de bases de données c'est parfois bien, j'ai souvenir d'avoir éclaté des scores de recherches de fichiers mp3 il y a quasi 20 ans quand on jouait avec le SQL …

    Un exemple, dernièrement j'ai voulu jouer avec des fichiers issus de l'OpenData d'une agence gouvernementale, un fichier CSV de ~5Go avec un peu plus de 20 millions d'entrées. Le 1er import dans MySQL (MariaDB) = 8h … un peu d'optimisation plus tard j'en suis maintenant à moins de 5 minutes … entre les deux le simple fait de passer d'un fichier innodb à myisam a fait exploser les scores … ça tombe bien j'ai pas besoin de ce qu'innodb apporte (pour faire un énorme résumé: aucune contrainte relationnelles entre tables) …

    Donc réponse de normand "ça dépend" :-)

    eric.linuxfr@sud-ouest.org

  • # iep

    Posté par  . Évalué à 2.

    merci de vos réponses.
    En fait je fais une petite appli en python qui, pour chaque utilisateur de l'appli, stocke une vingtaine de fichiers tres légers (quelque kilo octet) dans des sous répertoire du nom de l'utilisateur.
    je souhaite mettre ca en ligne prochainement et je ne sais pas encore gérer les bdd avec python, donc je me pose la question de réecrire le code avec gestion de bdd.
    l'appli est tres rapide sur mon pc et dans mes souvenirs d'utilisations de bdd et sql, j'ai généralement trouvé la manipulation des bdd assez lente (indexation etc), d'où ma question.
    je pense qu'avec vos réponses je devrais m'en sortir
    merci

    • [^] # Re: iep

      Posté par  . Évalué à 4.

      Reste comme ça alors et fais des sous répertoires à plusieurs niveaux pour éviter les effets de bords d'un trop grand nombre de dossier dans un dossier

      Par exemple:

      users/a/ar/art/artoche@domaine.fr/

      ou si tu veux découper sur le nom de domaine des utilisateurs:

      users/d/do/dom/domaine.fr/artoche@domaine.fr/

      (quand je parle des effets de bords c'est pas des limites du système de fichier mais des outils pour les manipuler : par exemple la commande ls devra retourner des millions de résultats si tous tes dossiers sont dans un dossier alors que si tu découpe en paquets tu limite beaucoup, par exemple 1er niveau a-z si on reste en ascii de base, donc réponse = 26 possibilités puis dans /a/ar/ encore que 26 et ainsi de suite)

      eric.linuxfr@sud-ouest.org

      • [^] # Re: iep

        Posté par  . Évalué à 2.

        ok cet effectivement un moyen simple de diviser en paquets.
        vissiblement une autre limitation de sqlite est l'absence de multithreads dans le module python que le gere. ce qui peut etre problématique.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.