Utilizamos Google AppEngine para ejecutar consultas espaciales/de atributos y el principal problema (desde el primer día) es cómo indexar grandes conjuntos de líneas/polígonos de tamaño arbitrario. Los datos de puntos no son demasiado difíciles (véase geohash, geomodel, etc.), pero los conjuntos de polígonos pequeños/grandes agrupados aleatoriamente siempre han sido un problema (y, en algunos casos, lo siguen siendo).
He probado varias versiones diferentes de indexación espacial en GAE, pero la mayoría son sólo variantes de dos de ellas. Ninguna es tan rápida como las bases de datos SQL y todas tienen ventajas e inconvenientes. Además, los dos siguientes deben combinarse con la selección de la geometría en memoria (a través de JTS, etc.) para eliminar cualquier característica que no se ajuste a los parámetros de búsqueda finales y, por último, se basan en las características específicas de GAE, pero estoy seguro de que podría aplicarse a otras arquitecturas (o utilizar TyphoonAE para ejecutar en un clúster de Linux, ec2, etc.)
Rejillas - Empaquetar todas las características de una zona determinada en un índice de cuadrícula conocido. Coloque un pequeño índice espacial en la cuadrícula para poder navegar rápidamente por el conjunto de características que contiene. Para la mayoría de las consultas, sólo tendrá que sacar un puñado de cuadrículas, lo cual es rápido, ya que conoce la convención exacta de nomenclatura de las cuadrículas y su relación con las entidades K/V (obtiene, no consulta)
Pros - Bastante rápido, fácil de implementar, no ocupa memoria.
Cons - es necesario el preprocesamiento, el usuario tiene que decidir el tamaño de la cuadrícula, los geoms grandes se comparten en varias cuadrículas, la agrupación puede hacer que las cuadrículas se sobrecarguen, los costes de serialización/deserialización pueden ser un problema (incluso cuando se comprimen mediante búferes de protocolo)
QuadKeys - Esta es la implementación actual. Básicamente es lo mismo que Grids, excepto que no hay un nivel de rejilla establecido. a medida que se añaden características, se indexan por la rejilla quadkey que contiene completamente sus límites (o en algunos casos, se divide en dos cuando una sola quadkey no se puede utilizar, piense en la línea de tiempo). Una vez encontrada la qk, se divide en un número máximo de qk más pequeñas que proporcionan representaciones de grano más fino de la característica. un puntero/caja a esa característica se empaqueta entonces en un gridindex ligero (grupo de características) que puede ser consultado (un diseño original consultaba las características directamente pero esto resultó ser demasiado lento/intensivo para la CPU en los casos en que el conjunto de resultados era grande)
Polilínea Quadkeys http://www.arc2earth.com/images/help/GAE_QKS_1.png Polígono Quadkeys http://www.arc2earth.com/images/help/GAE_QKS_2.png
La convención de nomenclatura quadkey utilizada anteriormente es bien conocida y, lo que es más importante, tiende a preservar la localidad (descrita más aquí )
El polígono anterior tiene un aspecto similar al siguiente: 0320101013123 03201010131212 03201010131213 0320101013132 0320101013133 03201010131302 03201010131303 032010101313002 032010101313003 032010101313012 032010101313013 03201010131312 03201010131313 032010101313102 ...
si los límites de la consulta son lo suficientemente pequeños, se puede obtener directamente a través del qk. esto es óptimo, ya que es sólo una llamada rpc por lotes al almacén de datos de GAE. si los límites son lo suficientemente grandes como para incluir demasiados qks posibles (>1000), entonces se puede consultar alternativamente utilizando un filtro (por ejemplo: qk >= 0320101013 y qk <= 0320101013 + \ufffd ). La convención de nomenclatura quadkey y la forma en que GAE indexa las cadenas permiten que la consulta anterior obtenga sólo el existente rejillas que están por debajo de ese valor qk.
hay otras advertencias y problemas de rendimiento, pero en general, es la capacidad de consulta en las quadkeys lo que hace que sea factible
ejemplos - consulta sobre los condados de Estados Unidos: geojson
Pros - Bastante rápido, sin configurar el tamaño de la rejilla, sin ocupar la memoria, sin abarrotar las rejillas
Cons - se necesita un preprocesamiento, posible sobrecarga en algunos escenarios, no hay datos polares
Curvas de llenado de espacios - Echa un vistazo a Charla de Alfred sobre NextGen Queries en Google I/O este año. La inclusión de curvas genéricas de llenado de espacio/tiempo junto con los nuevos operadores MultiQuery (que se ejecutan en paralelo) permitirán realizar algunas consultas espaciales realmente interesantes. ¿Superará el rendimiento del SQL tradicional? Es difícil de decir, pero debería escalar muy bien. Además, nos acercamos rápidamente a un futuro en el que los dispositivos móviles de todas las formas y tamaños aumentarán drásticamente el tráfico de su sitio o servicio.
Por último, también estoy de acuerdo en que hay que analizar muy bien el dominio del problema antes de elegir NoSQL en lugar de SQL. En nuestro caso, me gustó mucho el modelo de precios de GAE, así que realmente no había elección, pero si no necesitas escalar, ahórrate algo de tiempo y utiliza una base de datos sql estándar.
