Hola, yo estoy trabajando con un portal[1] para la visualización temporal de datos, principalmente coberturas forestales. Aquí[2] puedes ver el despliegue de una versión antigua, con su barra de tiempo arriba a la izquierda.
Internamente tenemos un PostGIS y GeoServer (un servidor de mapas), algo esto último que no has mencionado y que si no conoces tal vez te interese. Una de las operaciones más comunes es pedirle la extensión del mapa a dibujar y el servidor de mapas hace las queries a PostGIS para devoverte la imagen del mapa. Con esta pila de software, basta con introducir un campo fecha en la tabla de posiciones en PostGIS (sin extensiones de tiempo), decirle a GeoServer qué campo representa el instante de ese registro[3] y listo. Hay un usuario que está haciendo con esto seguimiento de cóndores, más o menos lo que necesitas pero con un volumen de datos menor. Respecto al volumen de los datos, +1 a lo que dice Ivan y Luis Franco. La redundancia se elimina con una tabla para la info de los barcos referenciada desde la tabla de posiciones. Y la gran cantidad de puntos tal vez no sea problema si se crea un índice espacial (y tal vez uno sobre el campo fecha). Saludos. [1] https://github.com/nfms4redd/portal/ [2] http://rdc-snsf.org/portal/ [3] Sólo el punto "Preparación y publicación de capas vectoriales": http://snmb-admin.readthedocs.org/en/latest/portal_temporal.html 2015-03-31 21:16 GMT+02:00 Luis Franco Vázquez <[email protected]>: > Hola: > > que gran idea la de que exista un departamento como el tuyo. En la > universidad donde estoy soy yo quien hace eso para mi grupo y si tuviera que > dirigirme a los técnicos la respuesta a tu pregunta sería si he probado a > reiniciar. ;) > Sobre tu pregunta. Tienes un problema de dimensión en tu base de datos. > Supongo que cuando dices 1 billón te refieres a mil millones, como hacen en > los países sajones. ¿Cuánto ocupan tus datos en este momento?. Si exceden > los 32Tb ya tienes un problema: http://www.postgresql.org/about/ pero me > imagino que aún no llegas a eso. Luego seguiría estos pasos: > a)Aprende todo lo que puedas de optimización de los parámetros del servidor > postgresql. Los parámetros que debes poner dependerán de tu hardware, tus > datos y tus consultas por lo que es aventurado decirte nada pero debes estar > familiarizada con ellos. En la wiki de postgresql tienes algunos recursos > para comenzar: https://wiki.postgresql.org/wiki/Performance_Optimization > b)Aprende todo lo que puedas de índices, optimización de consultas y > características auxiliares de postgresql como el cluster de tablas. Unos > índices bien definidos hacen milagros. Yo he podido mover sin problemas > bases de datos espaciales de 500Gb con un servidor de apenas 16Gb de > memoria. > c) Con tablas tan grandes debes tener muy claro qué consultas vas a hacer y > qué pretendes obtener con ellas. Me explico. Si almacenas esos puntos como > nodos de una línea tendrás una geometría única (la línea) pero aunque > provenga de nodos con una cuarta dimensión espacial no podrás hacer una > consulta del tipo: SELECT trozo_recorrido FROM recorridos WHERE fecha < > algo. Tendrías que localizar el punto del recorrido más próximo a la fecha, > cruzarlo con los recorridos y "cortar" por ahí. La aparente comodidad de > tener una sola tabla de recorridos acaba de implicar que tengas tu tabla de > puntos + tabla de recorridos + optimizar su cruce. Como dice Iván, estás > intentando resolver un problema que aún no sabes cuál es. > > El 31 de marzo de 2015, 20:17, Wilder Castelo <[email protected]> escribió: >> >> Entiendo que estas en la etapa de modelamiento de la base de datos.. >> verdad? >> si es así, podrías manejar hasta 2 tablas: una de linea y otra de puntos. >> En la lineas, vas cargando el recorrido, así la consultar sera siempre >> sera al mismo y único registro y en cuanto a los puntos ya no seria del todo >> necesario a menos que requieras alguna información puntual del recorrido. >> >> Saludos, >> >> 2015-03-31 13:06 GMT-05:00 Mauricio Miranda <[email protected]>: >>> >>> 2015-03-31 15:04 GMT-03:00 Mauricio Miranda <[email protected]>: >>>> >>>> m (mesure) >>> >>> >>> *measure >>> >>> >>> _______________________________________________ >>> Spanish mailing list >>> http://lists.osgeo.org/mailman/listinfo/spanish >>> http://es.osgeo.org >>> http://twitter.com/osgeoes >> >> >> >> _______________________________________________ >> Spanish mailing list >> http://lists.osgeo.org/mailman/listinfo/spanish >> http://es.osgeo.org >> http://twitter.com/osgeoes > > > > _______________________________________________ > Spanish mailing list > http://lists.osgeo.org/mailman/listinfo/spanish > http://es.osgeo.org > http://twitter.com/osgeoes _______________________________________________ Spanish mailing list http://lists.osgeo.org/mailman/listinfo/spanish http://es.osgeo.org http://twitter.com/osgeoes
