Grosse base sql ou traitement php ?

[jeroen]

Salut à tous,

Je suis en train de réaliser une application web et j'aurai à manipuler un gros paquet d'informations (altitudes françaises avec un maillage de 90m), ce qui représente quelques 80 millions de points. A chaque altitude est associé une latitude et une longitude.

Pour l'heure les infos sont placées dans des fichiers texte selon une grille (1200 pts / 1200 pts), dans laquelle les latitudes/longitudes ne sont pas mentionnées mais peuvent être retrouvées en fonction de la position du point sur la grille. L'avantage est que ça permet de limiter la taille des fichiers (un tiers).

Pour mon application je me posais une question que la façon de stocker/traiter l'info :

A) En la stockant intégralement en base de donnée : 1 ligne= 1 point (champs lat/lon/alt), mais avec l'inconvénient d'avoir une base très grosse (300 Mégas ?)
B) En la stockant intégralement en base de donnée, mais en regroupant les infos en grille (champ lat mini / longitude mini / liste ordonnée d'altitudes). Avantage : moins d'infos, mais traitement PHP après.
C) En stockant l'info dans des fichiers et en traitant via PHP

Est ce que certains d'entre vous ont déjà travaillé sur de grosses bases, et auraient une opinion sur la question ?

Merci
2/

[skyll]

pour des sites avec des bases de 150Mo en moyenne j'ai pas eu de problèmes
ni de rapidité ni d'autre chose...
peut être que 300 c'est la limite fatidique

après en optimisant tes requetes mysql ou autre ca aide aussi...

[jeroen]

En fait en calculant grossièrement je dois être plus proche de 1,6 Go :

80M de points de la forme 45.12345 5.23456 1234 = 1,6Go

[skyll]

ah oui
la va falloir optimiser trèsssssssss finement
ou trouver un autre moyen (peut etre mathematique) de stocker ou
pour retrouver tes points selon des formules...
enfin réflechir fort en tout cas :-/

[petit-ourson]

Une base de données supporte très bien 1.6 Go de données.

Maintenant faut voir les requête que tu comptes effectuer dessus.

[padawan2]

une base de donnée peut très bien être grosse... des fois on a pas le choix.

C'est juste le serveur qui doit avoir assez de RAM pour la monter en cache, ainsi que les éventuels résultats de requête.

[jeroen]

Les requêtes seront très simples : ce sera uniquement du type
SELECT alt FROM table WHERE lat='' AND lon=''

Vous dites que 1.6 Go ça peut passer ? J'ai peut être interêt à prévoir un traitement post requête via PHP si ça peut limiter la taille de la base non ?

[biddybulle]

Je crois qu'en général, il faut faire attention à ne pas dépasser les 4Go par table et après autour des 55 000 tables si mes souvenirs sont exacts ce qui peut faire en effet de grosses Base de donnée.

[jeroen]

Et un traitement en stockant l'info dans des fichiers ? (dont la taille max serait d'environ 35Mo)

Plus rapide / Moins rapide ?
Plus sollicitant / Moins sollicitant pour le serveur ?

[jcaron]

Je suis en train de réaliser une application web et j'aurai à manipuler un gros paquet d'informations (altitudes françaises avec un maillage de 90m), ce qui représente quelques 80 millions de points. A chaque altitude est associé une latitude et une longitude.|/quote]

C'est bizarre un maillage à 90m. Ca correspond à une fraction de degré particulière dans nos latitudes? Sinon évidemment, c'est plutôt à un couple latitude,longitude qu'est associée une altitude (il n'y a pas qu'un seul point en France qui ait une altitude donnée).

Pour l'heure les infos sont placées dans des fichiers texte selon une grille (1200 pts / 1200 pts), dans laquelle les latitudes/longitudes ne sont pas mentionnées mais peuvent être retrouvées en fonction de la position du point sur la grille. L'avantage est que ça permet de limiter la taille des fichiers (un tiers).

Je suppose qu'il y en a plusieurs des fichiers de 1200x1200, parce que sinon tu ne couvres pas toute la France avec une précision de 90m. Au delà, suivant le format du fichier ça peut être plus ou moins rapide (idéalement chaque "point" doit avoir une longueur fixe, comme ça on peut faire un seek direct au bon endroit pour lire ce qu'on cherche). Encore mieux, un stockage binaire plutôt que textuel permet d'y gagner énormément. Si en plus tu n'as pas besoin de l'altitude au mètre près mais à 20m près par exemple, tu peux carrément coder chaque point sur un octet.

Pour mon application je me posais une question que la façon de stocker/traiter l'info :

A) En la stockant intégralement en base de donnée : 1 ligne= 1 point (champs lat/lon/alt), mais avec l'inconvénient d'avoir une base très grosse (300 Mégas ?)

Ca dépend beaucoup de la précision voulue et du type de stockage. Si tu as 80M de points, soit environ 9000 x 9000, tu peux stocker sur 3 champs entiers de 16 bits plutôt que des lat/long en virgule flottante par exemple. Mais tu auras les index et le reste de l'overhead de la bdd en plus.

B) En la stockant intégralement en base de donnée, mais en regroupant les infos en grille (champ lat mini / longitude mini / liste ordonnée d'altitudes). Avantage : moins d'infos, mais traitement PHP après.
C) En stockant l'info dans des fichiers et en traitant via PHP

En fait, tout dépend de ce que tu fais avec tout ça:
- les requêtes (interrogation d'un point à la fois, de plusieurs points, jointures, opérations de groupe...)
- la mise à jour ou non des données, et le rythme de ces mises à jour

Dans le cas présent, la réponse à la 2e question est probablement "pas de mises à jour". Reste donc à savoir si tu as des opérations complexes à effectuer (auquel cas tu peux avoir envie de les "sous-traiter" à ta base SQL) ou pas. Si tu n'en as pas, un fichier binaire de 160 Mo et un coup de seek (je ne sais pas comment il s'appelle en php) et hop.

Jacques.

[rikew]

Pourquoi stoquer latitude et longitude pour chaque point ?
Ca me paraît inutile puisque tu sais que chaque points est distant de 90 m.
Il suffit de connaître la latitude et longitude du premier point (en bas a gauche par exemple) et ensuite tu peux retrouver rapidement les coordonnées du point.
D’après moi ta table doit contenir uniquement 2 champs :
- ID (numéro du point)
- Altitude

[jeroen]

Merci pour vos réponses, je commence à y voir plus clair.

Le fichiers natifs sont des fichiers qui couvrent 1degré*1degré d'angle, et qui contiennent 1201*1201 points, ce qui représente à peu près 90m de précision à l'équateur. Ces fichiers sont en binaire TIFF, mais j'ai la possibilité de les passer en format .txt (une appli me fait ça)

Je me posais la question de les passer en base de donnée pour des question de rapidité. Si je laisse les données sous forme de fichiers, quelle serait la taille à ne pas dépasser à votre avis pour avoir une réponse rapide (appli PHP)

Effectivement en laissant les fichiers en binaire je pourrai gagner de la place, mais je ne sais pas décoder un fichier en binaire via PHP. Vous auriez des pistes ?

Il me faut de la précision, donc pas de codage sur un octet.

Merci

[jcaron]

Ben le TIFF ça veut dire que c'est une image, donc? L'avantage c'est la compression, l'inconvénient c'est que tu n'as pas accès direct à n'importe quel point, il faut lire tout le fichier pour arriver ou tu veux.

Le fait de passer ça dans une base SQL ne va pas forcément t'amener grand chose en rapidité: ça aurait un intérêt si un index était utile, mais ici tu peux vraiment accéder où tu veux très facilement, donc un fichier binaire c'est probablement l'idéal.

En utilisant 2 octets par point, (soit des valeurs de 0 à 65535m au mètre près), ton fichier va faire grosso-modo 160 Mo (80 millions de points x 2 octets). Et tu peux accéder au point voulu en allant directement à l'offset (ligne * longeur ligne + colonne) * 2.

Pour l'accès aux fichier, je pense qu'il faut que tu regardes du côté des fonctions dio_*. En bref: dio_open, dio_seek, dio_read, dio_close. Ensuite, il suffit de faire un coup de unpack pour transformer les 2 octets que tu viens de lire en un entier.

En termes de temps d'accès, ben en supposant que les inodes amenant à ton fichier et les zones d'indirection pour le fichier (qui donnent la liste des blocs du disque où il se trouve) soient en cache, et que le fichier lui-même ne le soit pas du tout, ça va te prendre un accès disque et un seul par accès, et une quantité de CPU négligeable. Si des zones sont plus observées que d'autres elles seront en cache. Quoi qu'il arrive ça ira plus vite qu'une base SQL.

Jacques.

[2dm]

Tout dépend en fait de la façon dont tu vas accéder à tes points.

Je ne pense pas que tu puisse écarter la longitude/lattitude pour tous les points (la France n'est pas un carré, les frontières peuvent aussi définir des zones concaves). Par contre, en sortant du bon algo de derrière les fagots tu peux t'en sortir très bien.

Après tout dépend de ce que tu veux faire et du temps que tu veux y consacrer.

Tu es en 2D, les structures d'arbres type KD-Tree sont tes amies.
Si tu te fais pas chier, tu fais un KD-tree global que tu divises en sous-arbre (en stockant les index).
Si tu veux optimiser le biniou, tu dois différencier les zones concaves des autres (l'échelle va dépendre de la taille des sous-arbres que tu veux). Tu auras donc une structure KD-Tree pour les points situés en bordure et une structure telle que décrite par Jacques pour les autres.