Forum Programmation.SQL choix d'une nouvelle DB

Posté par  .
Étiquettes : aucune
0
27
juil.
2010
Bonjour à tous

Il y a maintenant près d'un an, j'ai commencé à développer une application en PyQt4 + Sqlite pour la gestion d'un réseau social.
A l'époque, j'avais des besoins simples, aussi le couple python + sqlite était idéal, à la fois léger et performant.

Cependant, 2 problèmes...
Le syndrome du "ce serait sympa si....", qui m'a amené en enrichir l'application. Ma base se voit augmentée de nouvelles tables, mais toujours pas de soucis majeurs.
Après un an, j'ai atteint les 3 millions d'entrées, et une base sqlite de pres d'1Go.
Les requêtes se font plus longues, et il s'avère que je n'ai pas besoin de la totalité de ma base pour beaucoup d'opérations très simples.

Tentation n°1 :
Plutôt que d'avoir une grosse application qui fait tout (et une tâche à la fois, vu que les threads et moi ça fait 2...), séparer le tout en plusieurs applications dédiées, plus légères et indépendantes. Toutes auraient cependant une table nécessaire en commun, la plus grosse, et une ou plusieurs tables dédiées.

Problème n°1 :
Sqlite et les accès concurrents, c'est pas vraiment ça, et le problème de passage à l'échelle reste, donc je pensais migrer vers une autre base un peu plus à l'aise de ce côté là. J'ai entendu parler de Mysql Embedded dans mes lectures sur Amarok, mais pas vraiment trouvé de tutos, ni de liens de téléchargement... tout au plus un paquet ubuntu, ce qui ne m'aide pas vraiment sous Arch...

Tentation n°2 :
J'abandonne le côté embarqué, et je décide de passer la base en ligne.

Problème n°2 :
J'ai maintenant plusieurs utilisateurs, chacun avec sa base qui prend de l'ampleur, et je me vois mal mettre tout ça en ligne...
Un utilisateur = une base locale, c'était séduisant...

Tentation n°3 :
Ca m'énerve et je refais tout en C++ et Qt...

Problème n°3 :
Oui mais non, ça ferait vraiment trop de boulot !

Je conçois que j'ai quelques problèmes d'architecture, mais vu que ce n'est pas vraiment (mais du tout) mon métier à la base...
Quoiqu'il en soit, si quelqu'un connait une base :
- facile à déployer sur Windows, Linux, MacOS (sans embêter l'utilisateur avec de l'admin... de ce point de vue sqlite était top !)
- qui gère bien les accès concurrents
- qui ne mets pas 2 minutes pour rapatrier les 50.000 résultats d'une requête de rien du tout dans ma plus grosse table (bien indexée qui plus est)
- qui fonctionne avec Sqlalchemy, ou du moins Python

Des idées ???

  • # oops

    Posté par  . Évalué à 1.

    s/qui ne mets/qui ne met

  • # scinder en plusieurs bases sqlite

    Posté par  . Évalué à 3.

    De l'intérêt de prévoir l'avenir :)

    Une solution pourrait être de scinder ta base en plusieurs bases sqlite.
    La principale contient ta table commune et les tables concernant le cœur de ton appli, les autres sont spécialisés (correspondent à tes applis dédiés)

    Je ne suis pas expert sqlite, et je crains que cela impose de scinder tes requêtes selon le découpage des bases (à vérifier), mais ça devrait réduire tes pbs d'accès concurrent.

    Tu peux aussi mettre dans une base spécialisée tout ce qui correspond à du référentiel

    • [^] # Re: scinder en plusieurs bases sqlite

      Posté par  . Évalué à 1.

      Et oui... c'est le problème de faire sa sauce dans son coin et d'avoir quelques personnes qui passent en disant "tiens j'utiliserais bien ton bousin; et en passant si on pouvait rajouter ça, ça et ça...."

      Le fait de scinder la base, pourquoi pas, mais j'aurai toujours le problème des accès concurrents pour la table principale, chose qui a l'air lourdingue avec sqlite...

  • # Il dit qu'il voit pas le rapport

    Posté par  (site web personnel) . Évalué à 2.

    >> Tentation n°3 :
    >> Ca m'énerve et je refais tout en C++ et Qt...

    Je vois pas le rapport.
    Une base de merde, en C++ ou en shell, avec Q ou GTK, ça reste une base de merde. Le langage que tu vas utiliser aura autant d'impact sur ta structure de données que la couleur de ton clavier…

    Je te conseille d'utiliser d'analyser les statistiques d'utilisation actuelles, et de structurer ta prochaine BDD en fonction de ça.
    Passer à C++, ça va surtout t'apporter des segfaults et des failles de sécu supplémentaires…

    • [^] # Re: Il dit qu'il voit pas le rapport

      Posté par  . Évalué à 1.

      Pas de rapport effectivement !
      C'est juste qu'entre temps je me suis pas mal amélioré en gestion de threads et que j'ai envie de me remettre au C++ sur un petit projet...
      Je me demande juste ce que 6000 lignes de Python donneront en C++, j'ai mal rien que d'y penser !

      Dans mon cas, plus que la structure de données, c'est le côté parallèle qui me gêne le plus. Je peux accepter qu'une grosse requête prenne 2 minutes, pourquoi pas. Mais je ne peux pas accepter que mon appli soit en standby pendant tout ce temps à cause d'une requête qui correspond à une tâche que je voudrais en arrière plan

  • # lapin compris

    Posté par  . Évalué à 1.

    c'est une appli de type "reseau social"
    une application en PyQt4 + Sqlite pour la gestion d'un réseau social

    mais avec une base locale à chaque machine ?
    J'ai maintenant plusieurs utilisateurs, chacun avec sa base qui prend de l'ampleur, et je me vois mal mettre tout ça en ligne...
    Un utilisateur = une base locale, c'était séduisant...


    - facile à déployer sur Windows, Linux, MacOS (sans embêter l'utilisateur avec de l'admin... de ce point de vue sqlite était top !)


    on est loin d'un modele "RESEAU Social"
    l'idée de depart etant d'avoir un endroit centralisé qui contient les infos et ou chacun vient y piocher ce qu'il veut ...


    j'espere que les bases "locales" ne sont là que pour stocker les preferences de l'utilisateur ?

    sinon je pense comprendre pourquoi ton appli peut etre lente,
    s'il faut que le client envoie tous les changements de sa base vers le serveur au lancement (pour que les autres clients voient ces changements)

    ca fait beaucoup de mouvement pour pas grand chose au final ;)

    • [^] # Re: lapin compris

      Posté par  . Évalué à 1.

      bon, je n'ai pas été assez clair, mea culpa

      en fait, je ne gère pas de réseau social, mais j'ai une appli qui me permet de l'analyser
      nous ne sommes pas liés au réseau social, juste membres, mais nous avons envie d'avoir des données plus fines que celles disponibles par defaut

      imaginer :
      - un réseau de 20 millions de membres, avec amis, photos, communautés...
      - impossibilité de rechercher les utilisateurs par critère, alors même qu'ils sont publics

      du coup, ce qu'on a fait :
      - on parse comme des malades les infos, et on les stocke
      - ensuite, on lance nos moulinettes "sciences sociales" pour analyser des graphes de connectivité, etc...
      donc chacun stockera dans sa base une partie du site, et après mise en commun des données, en avant les calculs
      de mon côté, j'ai 2.5M d'utilisateurs, mes collègues doivent en avoir a peu près autant à eux 4, d'où un volume croissant...

      • [^] # Re: lapin compris

        Posté par  . Évalué à 2.

        ah ok, donc "sciences sociales" plutot que reseau social.

        et penses tu qu'un extrait du reseau sociale "segementé" entre toi et tes collegues soit une bonne chose ?

        avec les risques de doublons car les croisements vont se faire sur certaines données communes ?

        une seule base centrale ne serait-elle pas plus appropriée ?
        ensuite effectivement tes "clients" peuvent faire des recherces separement sur cette base en fonction des criteres...

        1°) tu n'as plus que l'appli à deployer sur les "clients" (et pas un moteur de base de données avec la maintenance qui va avec)

        2°) les données ou extract du reseau sont centralisés en un point, 2 clients peuvent lancer une meme requete pour comparer leur resultat ou leur analyse.

        Je pense que Python et donc PyQT dois pouvoir se connecter à presque tous les types de bases de données (mysql, postgresql, mais aussi les nouveaux moteurs mongo db, nosql, couchdb...)

        • [^] # Re: lapin compris

          Posté par  . Évalué à 1.

          tant que j'étais seul sur le coup, une base locale ne posait pas de problème
          limite, un serveur m'aurait semblé un peu "overkill" pour ce que je voulais faire
          avec peu d'utilisateurs, et une bonne politique de parsing, pas de doublons, mais une phase de merge qui mange et du calcul et du temps...
          donc effectivement maintenant je me demande si une base centrale ne serait pas mieux

          le problème, on est pas en réseau local, donc la base serait en ligne quelque part, et ca génère des coûts
          là, on s'échange nos bases via Dropbox, une pauvre âme fait le merge et tout le monde se synchronise comme ça
          peu efficace, mais gratuit >_<

          • [^] # Re: lapin compris

            Posté par  . Évalué à 2.

            si tu as deja un serveur en place pour le dropbox,
            doit bien y avoir de la place pour une base de données non ?

            • [^] # Re: lapin compris

              Posté par  . Évalué à 1.

              ben, non, dropbox.com quoi ^^;
              si on avait un FTP encore je dis pas, mais on a juste nos machines perso...

              • [^] # Re: lapin compris

                Posté par  . Évalué à 2.

                15euros par mois pour une dedibox avec 160Go de disque dur

                c'est combien votre abonnement chez dropbox ?

                • [^] # Re: lapin compris

                  Posté par  . Évalué à 1.

                  ahh non, on est radins, on se contente de 1Go gratuit, et pour les cas limites, on passe un des portables en serveur FTP le temps de telecharger...
                  dur dur la jeunesse !

                  • [^] # Re: lapin compris

                    Posté par  . Évalué à 3.

                    jeunesse ? des concepteurs ou de la votre boite d'analyse sociale via les reseaux sociaux ?

                    car ne pas pouvoir mettre 60euros/an chacun (5 euros par mois, 3 personnes dans l'equipe)

                    pour avoir un service efficace, c'est plus de la jeunesse, c'est de la radinerie... ;)

                    • [^] # Re: lapin compris

                      Posté par  . Évalué à 1.

                      qui a dit qu'on etait une entreprise ?
                      non, c'est uniquement fait sur notre temps libre (enfin le mien surtout, vu que je suis le seul a developper), et on en tire zero profit, si ce n'est de pouvoir faire quelques petite manips interessantes avec les donnees (j'avais ete bien inspire par ca aussi ==> http://blog.ted.com/2010/05/the_hidden_infl.php )
                      deja que j'y investis du temps et une partie de mes pauses dejeuner, si en plus je dois y mettre de ma poche ^^

                      • [^] # Re: lapin compris

                        Posté par  . Évalué à 3.

                        donc tu viens d'atteindre une masse critique pour ton logiciel
                        - beaucoup de données
                        - des utilisateurs de plus en plus nombreux

                        et une procedure laborieuse pour avoir les données (echange/merge/dedoublonnage par FTP)

                        il faut donc reflechir à l'avenir de ton logiciel/projet :
                        - peux-tu continuer à faire comme vous faites actuellement ? via FTP, merge et reinjection en FTP
                        - peux-tu continuer à fonctionner en mode "autonome" chacun de son coté
                        (ca marche avec GIT ou chacun bosse de son coté, et les patchs sont integrés dans un depot en particulier) ?
                        - l'investissement de 5euros par mois peut-il etre "interessant" du point de vue temps gagné, electricité economisée ? (ne pas avoir à laisser tourner une machine chez soi pendant 2 jours juste pour merger/dedoublonner les infos avant de les reinjecter)

                        car finalement 5euros, c'est une place de ciné par mois (au tarif etudiant)
                        c'est 3 bieres au pub
                        c'est un paquet de cigarette

                        mais si ca vous fait gagner 2h sur les merges, 1 fois par semaine parceque la base de données est centralisée et permet d'eviter justement les download/merge/tri/upload puis download par les copains.

                        alors je penses que ca peut valoir les 5euros investit de ta poche.

                        (pour une base de données de 2Go, on doit pouvoir trouver moins cher que la dedibox à 15euros par mois, mais c'etait pour dire qu'on trouve maintenant des offres raisonnables à pas trop cher)

                        • [^] # Re: lapin compris

                          Posté par  . Évalué à 1.

                          bon, je dois avouer que tu marques un point... J'avais pense un temps convertir un Mac Mini en serveur base de donnees, mais vu les performances j'ai vite abandonne. Et mon gros QuadCore consomme decidement trop dans son coin.

                          J'en ai profite pour faire quelques tests avec une base Postgresql (pour une raison que j'ignore, il a ete impossible d'installer MySql sur mon poste XP...) et les performances sur les grosses requetes sont bluffantes par rapport a Sqlite. Et les acces concurrents semblent bien marcher au poil.

                          Bon ben, recherche d'hebergeur comme qui dirait !
                          Est-ce que quelqu'un a un retour d'experience sur les dedibox, kimsufi et autres ?

  • # Question:

    Posté par  . Évalué à 1.

    Ne pourrait tu pas sortir des choses de la BD ? Car j'aimerais bien savoir comment tu arrive à des base d'un Gio. Tu met des images dedans ?

    • [^] # Re: Question:

      Posté par  . Évalué à 1.

      non, juste beaucoup d'entrées ^^
      bon, après un VACUUM, je descends à 850MB, mais quand même !

      • [^] # Re: Question:

        Posté par  . Évalué à 1.

        d'ailleurs, ce n'est pas si aberrant quand on y pense, ça ne me fait jamais que 400 octets par record, sachant qu'en plus il y a des index, que le texte stocké est en unicode (japonais oblige), non franchement ça me choque pas plus que ça

  • # des vrais DB sérieuses ?

    Posté par  (site web personnel) . Évalué à 2.

    berkeley db ?
    cdb ?

    il n'y a pas de SQL et tu dois bien reflechir à ton schéma de base ... mais coté performance, selon ce que tu souhaites, c'est super rapide.

Suivre le flux des commentaires

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