Discussion :

[C0PT3R]

Bonjour à tous,

Ces derniers temps, j'occupe mes temps libres à la conception d'un système qu'on pourrait comparer à une bibliothèque qui contiendrait quelques centaines de livres, voir plus. Chacun de ces "livres" serait contenu dans un fichier individuel, et son contenu divisé en "pages". L'application client serait en mesure de requérir ces pages seulement une à la fois, car le serveur doit appliquer à chacune d'elles certaines transformations, dépandemmant des données transmises par le client.

Sachant que ces livres seraient lus simultanément par plusieurs clients, je me demande s'il serait préférable de stocker ces fichiers en mémoire (php://memory, les fichiers étant chargés au besoin et dotés d'une date d'expiration) plutôt que de relire le fichier intégral sur le disque à chaque requête d'un client, seulement pour en extraire une "page".

J'espère que mes explications sont suffisamment claires. Au besoin, n'hésitez pas à demander plus d'information. Je tiens à dire que je ne suis pas programmeur professionnel. S'il-vous-plait, soyez indulgents.

Merci d'avance.

[Djakisback]

Bonjour,
je pense que c'est assez compliqué de définir la solution la plus efficace des deux car cela dépend de beaucoup de facteurs : performances/config serveur, nombre de connexions simultanées, fréquences de connexion sur une même page d'un livre, ...
S'il y a des centaines de livres, il est possible que cela ne soit pas rentable, les clients ayant peu de chance de consulter le même livre simultanément. D'autre part, la RAM d'un serveur est assez précieuse et le stockage de nombreux fichiers textes peut très vite la saturer, pour se retrouver au final avec un fichier "temporaire" sur disque et non plus stocké en RAM.
De mon point de vue, il faudrait partir sur une solution basique en premier lieu et penser à des optimisations uniquement s'il y a des problèmes. Sachant qu'il faudrait sans doute tout de même mieux préparer les données, à savoir, peut-être découper les fichiers par page, ce qui réduirait les coûts de lecture ou utiliser une base de données ce qui permettrait de décharger un peu le processus (si la BDD est sur une autre machine, c'est encore mieux évidemment).

[C0PT3R]

L'idée de stocker les données dans une BD mySQL m'a effectivement traversé l'esprit, cependant, dites-moi si je me trompe, il me semble que chaque entrée d'une même table requiert un espace disque similaire défini dans la structure de la table, et cela peu importe le contenu qu'on y insère. Comme je l'ai mentionné, les documents en question ne sont pas à proprement parler des livres, et la taille des "pages" peut varier de quelques octets à plusieurs kilo-octets, ce qui résulterait en un gigantesque gaspillage d'espace disque. Si c'est le cas, je vais plutôt essayer de séparer chaque fichier en portions plus petites, comme vous l'avez suggéré.

Si vous avez d'autres suggestions ou conseils, je suis preneur. Merci beaucoup.

[Djakisback]

Non, en fait tout dépend du type de structure choisi, par exemple sous MySql, effectivement un CHAR prendra toujours 256 octets mais pas un VARCHAR qui prendra la taille réelle plus 1 octet pour stocker la taille. On choisit la structure plutôt en terme de capacité maximale. Par exemple, dans votre cas il pourrait s'agir du type TEXT permettant de stocker 65Ko maximum. Mais en passant par une base le mieux, a priori, serait de découper également les pages, à voir...

[RunCodePhp]

Salut

La description que tu donne me surprend un peu, car à mon sens ce n'est ni plus ni moins la description de quasi tous les sites Web.

Si on prend ce forum, chaque sujet (ou topic) serait un livre qu'un membre peu créer, et que par la suite n'importe quel internautre pourra consulter/lire.
Le topic peu contenir plusieurs pages (ici on parle de post, mais c'est pareil).
Chaque post peut être modifiés, voir supprimés.

Tous ces contenus sont stockés dans une Bdd, et si ce n'était pas le cas, ce serait tout simplement ingérable.

L'énorme avantage d'une Bdd comparé à de simples fichiers, c'est la gestion de tous ces contenus : Ajout, modification, suppression.
Rajoutons à cela la recherche parmi ces contenus, à ne surtout pas négliger.
Puis bien souvent on souhaitera faire des statistiques (les livres les plus lus, etc, etc ...).

Une Bdd ce n'est pas juste un élément de stockage, c'est avant tout de la gestion, le langage SQL est très puissant pour extraire des données.
Je pense que tu auras d'énorme difficultés à en faire autant sur de simples fichiers (voire ne pas réussir du tout), bien souvent ça débouchera sur des REGEX de ouf, qui à mon sens ne sera pas loin de vouloir réinventer le SQL.


Pose bien ton projet, défini le bien.
Rien empêche de gérer tes contenu en partie dans une Bdd, une autre dans des simples fichiers.

N'oublie pas non plus qu'il existe pas mal de système de cache :
Navigateur, Apache (Serveur Web), Php, Bdd.
Si tout cela est bien maitrisé/exploité, on peu gérer une énorme quantité de donnée + un gros trafique, cela quelque soit la manière dont ils seront stockés.

Ne pas perdre de vu que quelque soit la manière dont sera stocké les contenus, au bout un internaute demandera une page Web, donc du HTML.

[C0PT3R]

La différence est que sur le système en question, les "pages" peuvent être très courtes, et un "livre" peut ne contenir que des pages courtes, et donc on peut les "lire" rapidement. Il en résulte un taux de requêtes grandement supérieur à celui d'un forum ou d'un site moyen. Ça pourrait donc être une bonne chose que toutes les données d'un livre soient prêtes à être traitées immédiatement, surtout si le document est très populaire.

Au début, j'avais pensé envoyer tout le contenu d'un document donné en une fois et faire faire le traitrement par le client, mais il s'avère que celui-ci doit impérativement être fait par le serveur. J'avais tout de même prévu une base de données, qui est d'ailleurs déjà en place, pour stocker des informations sur les documents. Seul le contenu devait être dans des fichiers.

Mais bon, après quelques lectures sur le fonctionnement de MySQL, j'ai choisi d'utiliser un système de base de données. Il me semble que ça conviendrait assez bien, pour commencer. J'aurais bien voulu vous en dire plus sur le projet que j'ai en tête, mais le monde étant ce qu'il est, je dois m'abstenir.

Merci à vous. Au plaisir.