Forum général.cherche-logiciel MySQL ou SQLite pour grosse base de données ?

Posté par  .
Étiquettes : aucune
0
29
sept.
2005
Bonjour,


J'ai l'intention de recycler mes plusieurs PC à mon domicile pour me servir de serveurs de bases de données dans le cadre d'un moteur de recherche amateur thématique (je me decide toujours pas de quoi traité lol). Je code activement mon premier crawler en C depuis quelques semaines.

Ma base de données volumineuse qu'elle sera, sera stoquer dans plusieurs PC dont la capacité des disques dur va de 400Mo à 20Go, le tout sera coordonnées (pour triés les résultats envoyer par les bases de données) par un programme directement implanter sur le serveur du site web en utilisant les sockets pour joindre les bases de données.


Je suis contraint a me décider entre deux logiciels : MySQL ou SQLite.

Voici mes questions:


- Je souhaite savoir quels sont les grandes différences entre ces deux bases de données (taille, développement, fréquence des mises a jours...) ?

- Lequel de ces deux logiciels est le plus fiable/stable et le plus rapide ?

- Vu que je ne me suis jamais servit de SQLite je voudrais par ailleur savoir si vous avez rencontrer des problemes ou des difficultés diverses.

- SQLite OK pour stoquer jusqu'a 20Go sur une base ?



Merci d'avance.

  • # MySQL ou SQLite pour grosse base de données ?

    Posté par  . Évalué à 1.

    Salut,

    Personnelement je laisserai tomber l'utilisation de SQLite.
    Bien que très pratique pour des applications Web->Php, très rapide lorsqu'il sagit de petits scripts.
    Mais si tu t'attaques à un projet d'une telle envergure, SQLite ne te sera pas bien bénéfique.

    SQLite ne permet à différents processus ou thread d'accéder en écriture à la même base de données et n'est donc pas conçu pour gérer de nombreux accès concurrentiels.


    A toi de voir.
    Tu peux toujours tester, mais je crois que tu perdras du temps.

    Voilà mon avis en tout cas ;)
    A bientôt

  • # Logique...

    Posté par  . Évalué à 3.

    Dans SQLlite il y a ... lite aussi ecrit light ce qui en francais signifie, dans ce contexte, leger. Leger par la taille, et supportant des projets legers
    Du coup, la reponse a ta question est tout naturellement: MySQL

    Par contre, pour quoi se focaliser sur MySQL et ignorer PostGreSQL ?

    • [^] # Re: Logique...

      Posté par  . Évalué à 1.

      Salut,

      Merci a vous deux de m'avoir repondut.

      PostGreSQL : Pourqoui pas?! si il est est assez rapide pour ce genre de projet, mais je ne le l'ait jamais utiliser.

  • # Ca depend

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

    (combien de milliard de fois j'ai dit ca moi? :p)
    Si c'est pour un acces avec plusieurs clients alors c'est pas sqlite (pourquoi pas mysql plutot que postgresql?)
    Sinon juste un client en écriture et plusieurs en lecture(en lecture faut faire gaf avec le vérouillage de tables) ca pourait pourquoi pas aller
    SI la table est bien faite (index tel que meme sur les 20giga il trouve en moins de 5s quoi) ca devrait aller
    Enfin bon amuse toi bien :p

  • # elements de réponse

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

    nonobstant le fait que tu puisses trouver dans la RFC 1925 plein d'information essentielle
    ( http://www.ietf.org/rfc/rfc1925.txt(...) ), je te pose qq questions betes :

    sais tu ce qu'est une base de données ?

    sais tu ce qu'est une base relationnelle ?

    la necessité d'user de la 6ieme forme normale dans ton cas ?

    En clair, ta problématique se pose essentiellement dans une approche de d'ensemble de clés multivaluées avec une dependance temporelle forte ( dite dependance de jointure temporelle ).

    A partir de là, SQLite, MySQL, PostgreSQL ne sont pas les outils qu'il te faut puisque tu as un surcout excessif lié à la grammaire "naturelle" de SQL, et aux limitations inhérentes au SQL.

    vu que ta problematique est sur des ensembles et donc est exprimable dans une certaine mesure avec une algebre relationnelle mais avec des ensembles tres precis de clé/valeurs, il me semble preferable de se tourner sur des berkeleydb pour t'entrainer, puis passer sur du cdb ( de D.J. Bernstein ) et des sparsehashes ( https://sourceforge.net/projects/goog-sparsehash/(...) ).

    mais cela c'est si seulement, tu veux de la rapidité serieuse , pas du Buzz techno-marketing autour de la puissance des bases SQL ( je glisse discretement une remarque sur nombre de personnes qui arguent sur le fait que le compilé est plus rapide que l'interprété, et qui a coté vantent les mérites de SQL qui lui est sur-interprété ).

    • [^] # Re: elements de réponse

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

      J'ai pas compris grand chose, mais de ce que j'ai compris je suis pas tout à fait d'accord (en partie quand meme faut l'avouer)
      tu as un surcout excessif lié à la grammaire "naturelle" de SQL, et aux limitations inhérentes au SQL.


      En dehors du fait que c'est interprété (partiellement faux cf plus loin)quels sont les inconvenients?

      et qui a coté vantent les mérites de SQL qui lui est sur-interprété
      Oui mais non
      Un certain nombre (bon au moins sqlite apres j'en sais rien) de base de données supportent la compilation des requete, alors evidement faut compiler au moins une fois à chaque execution (du programme pas de la requete hein), mais bon c'est un surcout négligeable

Suivre le flux des commentaires

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