Faire des pages CGI avec des équivalents en C aux fonctions unix ne serait-il pas une bonne idée ?

Effectivement coder directement en C peut être une bonne idée. Cela peut permettre notamment de ne pas avoir à réouvrir le fichier à chaque requête mais de le mmap()er dans le CGI (déjà cela fera moins d'appels systèmes).
Cependant j'ai du mal à croire que vous pouvez être plus efficace qu'une base de données pour la recherche sur ces données. Vu que ce sont des données simples je plaiderais pour des key-value store [https://en.wikipedia.org/wiki/Key-value_database]. Dans le genre j'utilise KissDB [https://github.com/adamierymenko/kissdb], qui est simplissime et probablement peu optimisé, mais c'est ce genre de choses qu'il faut viser, car plus la base de données a de fonctionnalités, plus elle est complexe et donc plus elle est lente.

Merci pour ta réponse.

En fait comme dit précédemment je n'ai pas de base sql en place puisque j'utilise basquement des fichiers texte. Cela dit un site comme crackstation utilise le même principe et arrive à proposer deux téra de base. Après il est vrai que j'essaie de proposer jusqu'à 500 hash par requête tandis qu'il n'en propose que 10. Peut-être qu'il me faut simplement me résoudre à limiter la recherche à une vingtaine de hash par exemple.

Cela dit je reste persuadé que la commande shell_exec (ou exec ou autre équivalent) en php reste un bottleneck assez important. Il est d'ailleurs référencé comme bugué depuis pas mal de temps mais aucun fix n'est venu réparer ça.

J'ai peur de l'usine à gaz en utilisant une base SQL, sachant que vraiment la seule chose que j'ai a stocker c'est un mot et un début de hash ou un offset, en tout les cas c'est très léger. Un index serait-il vraiment utile dans ce genre de cas ?
Dans la dernière version de ma "base" je ne recense que les offsets correspondant aux mots dans un gigantesque fichier. Est-ce que ça n'est pas une "sorte" d'index ?

EDIt : Faire des pages CGI avec des équivalents en C aux fonctions unix ne serait-il pas une bonne idée ?

salut,

Le truc c'est qu'il a des possibilités, comme des structures bien pensée, des index placé la où il faut, mais au final l'ensemble des données fait que celà est lent par essence.
ensuite la division des temps de recherche se fait sur l'infrastructure : cluster de base (sql ou nosql), disque plus rapide (SSD VS HDD) des processeurs plus rapides plus de ram etc. etc.
Je sais que tout cela est (très) coûteux et que ça limite rapidement les possibilités.

Le volume de données que veux traité est quand même très important et une recherche la dedans prend du temps.

"une sorte de sql qui fonctionne en stockant des lignes JSON".

C'est typiquement le cas de mongodb, par exemple, qui gère des documents JSON.

as tu tester ton archi base de données ? (mysql ou postgresql)
as tu posé un index ?
Il existe aussi des optimisations possible sur les index (la faut un vrai DBA).

La solution la plus rapide c'est d'avoir tout en ram mais ce n'est pas possible

@+

Merci pour vos réponses.

Evidemment mon système actuel n'est pas aussi complexe qu'une "vraie" base de données. Toutefois c'est surtout comme je l'ai dit pour des problèmes de rapidité que j'ai arrêté sql pour passer sur des fichiers texte. Je connais un autre site semblable au mien qui est sur base sql, ça lui prend plus e place et les requêtes sont plus longues pour une base moindre. Cela dit c'est peut-être mal optimisé je n'en sais rien.

J'ai eu discuté avec d'autres webmasters qui utilisent, attention je cite "une sorte de sql qui fonctionne en stockant des lignes JSON". Lui possède une base de 10 milliards de lignes environ sur 4 types de hash. Moi j'aimerais avoir 12 milliards sur 7 types de hashs différents donc évidemment ça pose problème.

Sur ma base actuelle j'ai pris de nombreux jours pour créer des fichiers avec une "profondeur" de 16^4, c'est à dire 65536 fichiers de 0000 à ffff. Cela dit ça prend un temps fou à se créer sur un HDD normal. C'est pourquoi je me suis mis à une "profondeur" de 16^3. Peut-être est-ce cela qui me bloque ?

J'imagine qu'il doit bien y avoir une solution du côté des bases SQL. Après tout il existe des sites possédant des bases de 400 milliards, et même une avec 25.000 milliards d'entrées sur plusieurs dizaines de types de hash différents.

Merci pour vos réponses, si je ne trouve aucune façon d'installer une base rapide sur mon dédié, je le résilierais e resterais sur le mutualisé qui m'a l'air plus rapide.

Moi, ça sent l'usine à gaz.

Toutes les DB qui me viennent à l'esprit (NoSQL key/value stores) tournent sur des environnements distribués (Cassandra, Riak), bien qu'ils devraient tourner sur un simple mutualisé.

Pour ce qui est de l'actuel, si les requêtes c'est juste "Va lire telle ligne dans tel fichier", et que les fichiers ont une taille limitée, c'est évident que ça va "assez vite", mais je n’appellerais pas ça une BD. C'est juste une structure de fichiers, et des commandes shell classiques en guise de "requêtes". Et si ça marche, tant mieux.

Concernant mon mutualisé c'est un simple ovh pro, rien de particulier.

Simple pour toi, mais tu ne connais pas l'architecture mise en place par OVH.
Si ça se trouve (et c'est très probable) ils ont un serveur de fichiers ultra-performant pour gérer des centaines de milliers de sites en mutualisé, or il est peut-être sous-utilisé et donc tu bénéficies de toute la puissance de cet équipement.
Alors que sur un dédié, bah tu es limité par les perfs du seul disque dur qu'il y a dans la machine.

Merci pour vos réponses.

Concernant mon mutualisé c'est un simple ovh pro, rien de particulier. Mes bases sur le mutu font environ 200Go, j'ai jusqu'à 20/25 personnes en même temps et pourtant tout répond super bien et les requêtes sont très rapides.

J'aurais besoin d'une lecture rapide, mais aussi d'une écriture pas trop lente pour importer ma base. Par contre exit les plusieurs serveurs, j'ai déjà juste assez pour m'en payer un

Concernant les données c'est une base associative de hashs, donc elle ne contient que de l'hexa et des mots simples. C'est pourquoi j'étais parti sur une flat avec de simples fichiers texte, d'ailleurs je persiste à croire que c'est une bonne solution et jen e comprend pas que ce soit si lent sur un dédié.

salut,

j'ajouterais un truc en plus : suivant la nature des données tu pourrais peux être utiliser une base nosql (genre elastic search s'il ne s'agit que de la recherche). La chose répartie sur plusieurs serveur sera efficace.
Sur du serveur monolitique mysql / mariabd, postgresql ou oracle feront l'affaire. Cela dépends aussi de la façon dont les données sont sollicitées (beaucoup de demande / visite demande plus de gestion de la charge que si c'est utilisé par 10 personnes).

@+

Bonjour,

Vu la taille de ta base, il te faut un vrai DBA pour mettre cela en place et être sûr de la tenue en charge car ça ne s'improvise pas la gestion de ce volume de données.

Pour ton problème de différence de comportement entre le mutualisé et le dédié, il faut que tu regardes aussi la performances des accès disques.
Si tes fichiers pour le mutualisé était sur un fileserver dédié, il est possible que les temps d'accès soient bien + performants.
Si tu prend un dédié avec des disques SSD peut être que tu pourrais avoir une amélioration.
Le système de fichier est aussi un point important dans ton cas car les performances ne sont pas identiques si tu sais que tu va avoir de nombreux accès à de nombreux fichiers...

Bonjour à tous,

Je vous explique briévement mon problème.
Je fournis une base de données assez importante en taille sur internet, pour le moment ma base a environ 15 à 18 milliards d'entrées.

Pour accéder à cette base (qui était en fait une flat donc avec des fichiers texte), j'utilisais un shell_exec en php avec des commandes unix. Sur mon mutualisé ça marchait très bien, et il me fallait environ 45s pour faire 500 requêtes.

Maintenant j'ai voulu sur mon nouveau dédié faire la même chose. Pour les essais j'ai reproduit une partie de ma base et j'ai mis le même système de shell_exec.

Sauf que maintenant ça prend environ 60s pour une trentaine de requêtes, sur un base moins grande en plus. Bref après quelques recherches je me suis rendu compte que shell_exec était ce qui ralentissait, car il crée un shell à chaque appel. Je ne sais pas pourquoi sur mon mutualisé je peux demander 1500 requêtes en 2mn avec shell_exec tandis qu'avec 60 sur mon dédié ça prend autant de temps. Bref.

Donc je me suis dit que j'allais passer à une "vraie" BDD sql. J'en étais revenu à cause des temps de lecture que je trouvais assez longs. A terme je vais avoir une base séparée en plusieurs tables d'environ 120/130Go (avec 12 milliards d'entrées par table), ces même tables seront séparées en 256 sous-section pour faciliter la recherche.

Et donc je viens vers vous pour avoir des informations sur la BDD a utiliser, ainsi que les problèmes auxquels je peux m'attendre en essayant d'importer un bon téra de données sur une base sql.

Ou si vous avez une solution pour améliorer mon shell_exec (peut être créer un cgi ? Mais je devrais l'appeler depuis php je pense).

En vous remerciant par avance pour vos éclaircissements.
Bonne journée