Aide sur choix persistance

Version imprimable

Bonjour,

Je cherche le moyen le plus performant pour stocker/lire de très gros volumes de données, voici ma problématique plus en détail...

J'ai donc en entrée des fichiers xml openStreetMaps, qui sont structurés ainsi:
-1ere partie, des déclarations de nœuds de localisation ("node"), qui sont composés d'un id, d'une latitude et d'une longitude (et d'autres attributs qu'on ne veut pas stocker).
-2eme partie , des polygones ("way") qui utilisent les nœuds cités plus haut, en les référençant par leur id.

Un exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 <?xml version="1.0" encoding="UTF-8"?> <osm version="0.6" generator="CGImap 0.0.2"> <bounds minlat="43.5726470" minlon="3.9335430" maxlat="43.5729650" maxlon="3.9341380"/> <node id="959395420" lat="43.5728302" lon="3.9339762" user="maouth-" uid="322872" visible="true" version="1" changeset="6125245" timestamp="2010-10-21T13:06:28Z"/> <node id="959368838" lat="43.5727916" lon="3.9337729" user="maouth-" uid="322872" visible="true" version="1" changeset="6125245" timestamp="2010-10-21T12:47:41Z"/> <node id="959376852" lat="43.5728178" lon="3.9339493" user="maouth-" uid="322872" visible="true" version="1" changeset="6125245" timestamp="2010-10-21T12:53:25Z"/> <node id="959362732" lat="43.5726572" lon="3.9340831" user="maouth-" uid="322872" visible="true" version="1" changeset="6125245" timestamp="2010-10-21T12:44:13Z"/> <node id="959379795" lat="43.5728174" lon="3.9337521" user="maouth-" uid="322872" visible="true" version="1" changeset="6125245" timestamp="2010-10-21T12:55:35Z"/> <node id="959370195" lat="43.5728916" lon="3.9339189" user="maouth-" uid="322872" visible="true" version="1" changeset="6125245" timestamp="2010-10-21T12:48:24Z"/> <node id="959358463" lat="43.5726708" lon="3.9341107" user="maouth-" uid="322872" visible="true" version="1" changeset="6125245" timestamp="2010-10-21T12:42:41Z"/> <node id="959359821" lat="43.5728677" lon="3.9339398" user="maouth-" uid="322872" visible="true" version="1" changeset="6125245" timestamp="2010-10-21T12:43:13Z"/> <way id="82416819" user="maouth-" uid="322872" visible="true" version="1" changeset="6125245" timestamp="2010-10-21T13:21:37Z"> <nd ref="959379795"/> <nd ref="959368838"/> <nd ref="959359821"/> <nd ref="959370195"/> <nd ref="959379795"/> <tag k="building" v="yes"/> <tag k="note:import-bati" v="v0.3"/> <tag k="source" v="cadastre-dgi-fr source : Direction Générale des Impôts - Cadastre. Mise à jour : 2010"/> </way> <way id="82415652" user="maouth-" uid="322872" visible="true" version="1" changeset="6125245" timestamp="2010-10-21T13:17:23Z"> <nd ref="959358463"/> <nd ref="959395420"/> <nd ref="959376852"/> <nd ref="959362732"/> <nd ref="959358463"/> <tag k="building" v="yes"/> <tag k="note:import-bati" v="v0.3"/> <tag k="source" v="cadastre-dgi-fr source : Direction Générale des Impôts - Cadastre. Mise à jour : 2010"/> </way> </osm>
Étant donné que je parse les documents avec Sax, il faut que je stocke les noeuds quelque part pour pouvoir les utiliser quand j'arrive aux polygones.
Ca marche très bien en mémoire tant que la jvm a assez de mémoire pour stocker les noeuds, il me faut donc un autre mode de stockage pour les fichiers trop gros.

J'ai testé hsqldb en mode text .csv, ça marche bien mais c'est assez lent, et sur des fichiers vraiment trop gros ça a l'air de se casser la gueule au bout d'un moment.

Niveau volumétrie, sur de gros fichiers on tape sur plusieurs millions de noeuds à stocker, et donc plusieurs millions de requetes select à la suite.

J'ai testé hier avec mysql, les perfs sont catastrophiques, pires qu'avec hsqldb 8O

Si quelqu'un à une idée pour ce genre de problématique je suis preneur :ccool:

Merci.

17/05/2011, 12h42
tchize_

le moyen le plus performant serait de faire votre traitement à la volée lors de votre lecture.

Reste pour ça à savoir quels sont les algorithme concerné et si ils sont adaptable dans cette problématique. Pour trouver ce qui est performant, il va falloir qu'on sache ce que vous voulez faire de ces données.
17/05/2011, 12h56
Malone

La finalité est de lire les noeuds "way" qui sont donc des définitions de polygones , et de les écrire après x transformations dans un fichier texte.

Je fais ce traitement à la volée , mon problème est que les nœuds de localisation lat/long qui sont nécessaires à l'écriture des polygones sont définis en entête du fichier, et vu que je parse le fichier avec sax je ne peux plus y accéder une fois dans la partie déclaration des polygones, d’où mon obligation de stocker ces nœuds lat/long quelque part.
17/05/2011, 17h37
tchize_

un solution a priori performante serait

1) injecter dans une table les noeuds, dans une autre les polygones, en mettant biens les index sur les colonnes! Faites du batch avec un preparedstatement pour accélérer l'écriture

2) fait un select avec jointure pour récupérer les polygones

3) faire le traitement à la volée sur les polygones au fur et à mesure de leur lecture.

vu la structure, si vous ne pouvez pas garder tous les points en mémoire, vous n'aurez pas d'autre choix que de passer par le stockage disque, ce qui est de facto moins rapide que la mémoire :-)

Un autre possibilité, vu que le style semble s'y prêter, c'est de préalablement découper votre ensemble de points en plusieurs "régions", et de ne traiter que les polygones correspondant à la région, et travailler une réguion à la fois. Vu que ce sont des données cadastrale, je suppose que souvent ce sont des points très proches (50m) qui font partie d'un polygone alors que l'ensemble des points forme une matrice de plusieurs kms....

Citation:

Envoyé par Malone

Si quelqu'un à une idée pour ce genre de problématique je suis preneur :ccool:

Merci.

FYI

Parmi les solutions du type NoSQL, il existe ElasticSearch qui permet de faire des requêtes géo-localisées et qui a un mode d'insertion "bulk".
(la communication se fait en REST au format JSON)

En partant de vos données XML, l'insertion pourrait donc se faire via une transformation XSLT.

Pour une idée des performances un query demandant les records dans un rayon de 100m autour d'un point sur un dataset de ± 540.000 entrées :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
{
   "query" : 	{
	    "filtered" : {
	        "query" : {
	            "match_all" : {}
	        },
	        "filter" : {
	            "geo_distance" : {
	                "distance" : "0.1km",
	                "geoloc" : {
	                    "lat" : 46.20,
	                    "lon" : 6.10
	                }
	            }
	        }
	    }
	}
}

(dans cet exemple geoloc est le nom du champ contenant latitude et longitude, les autres mots font partie de la syntaxe du query)

s'exécute en

Code:

1
2
3
4
 
real	0m0.060s
user	0m0.003s
sys	0m0.003s

les résultats ressemblent à ceci :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
{
  "took" : TIME_TAKE_ON_SERVER,
  "timed_out" : false,
  "_shards" : {
    "total" : TOTAL_NUMBER_OF_SHARDS,
    "successful" : NUMBER_OF_SHARDS_HAVING_RETURNING_OK,
    "failed" : NUMBER_OF_SHARDS_HAVING_RETURNING_ERROR
  },
  "hits" : {
    "total" : NUMBER_OF_HITS,
    "max_score" : 1.0,
    "hits" : [ 
… un record JSON par document avec les champs définis…
    ]
  }
}

Vous pouvez aussi faire de la geo partition :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
{
   "query" : {
       "match_all" : {}
   },
   "facets" : {
       "geo1" : {
           "geo_distance" : {
               "geoloc" : {
                   "lat" : 46.20,
                   "lon" : 6.10
               },
               "ranges" : [
                   { "to" : 10 },
                   { "from" : 10, "to" : 20 },
                   { "from" : 20, "to" : 100 },
                   { "from" : 100 }
               ]
           }
       }
   }
}

cela retournera les records par distance (ici ≤ 10km, de 10 à 20, de 20 à 100, au-delà de 100km…)

19/05/2011, 13h05
Malone

Merci pour les infos , je vais regarder tout ça.