Utilizamos Google AppEngine para ejecutar consultas espaciales / de atributos y el problema principal (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 (ver geohash, geomodel, etc.) pero los conjuntos de polígonos pequeños / grandes agrupados aleatoriamente siempre fueron un problema (y en algunos casos, todavía lo son)
He probado varias versiones diferentes de indexación espacial en GAE, pero la mayoría son solo variantes de dos a continuación. Ninguno era tan rápido como las bases de datos SQL y todos tienen pros / contras. Sin embargo, las compensaciones parecen razonables para la mayoría de las aplicaciones de mapeo basadas en Internet. Además, los dos siguientes deben combinarse con la eliminación de 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 finalmente, confían en las características específicas de GAE, pero estoy seguro de que podría aplicarse a otras arquitecturas (o usar TyphoonAE para ejecutarse en un clúster de Linux, ec2, etc.)
Cuadrículas : empaque todas las características de un área determinada en un índice de cuadrícula conocido. Coloque un pequeño índice espacial en la cuadrícula para navegar rápidamente por el conjunto de características que contiene. Para la mayoría de las consultas, solo necesitará extraer un puñado de cuadrículas, lo que es rápido, ya que conoce la convención de nomenclatura exacta de la cuadrícula y cómo se relaciona con las entidades K / V (obtiene, no consultas)
Pros : bastante rápido, fácil de implementar, sin huella de memoria.
Contras : se necesita un preprocesamiento, el usuario debe decidir el tamaño de la cuadrícula, las grandes geoms se comparten en varias cuadrículas, el agrupamiento puede hacer que las cuadrículas se sobrecarguen, los costos de serialización / deserialización pueden ser un problema (incluso cuando se comprimen a través de buffers de protocolo)
QuadKeys : esta es la implementación actual. básicamente es lo mismo que las cuadrículas, excepto que no hay un nivel de cuadrícula establecido. A medida que se agregan características, son indexadas por la cuadrícula de quadkey que contiene completamente sus límites (o, en algunos casos, se dividen en dos cuando no se puede usar un solo quadkey, piense en la línea de fecha). Después de encontrar el qk, se divide en un número máximo de qk más pequeños que proporcionan representaciones de grano más finas de la característica. un puntero / bbox a esa característica se empaqueta en un índice de cuadrícula liviano (grupo de características) que se puede consultar (un diseño original consultaba las características directamente, pero esto resultó demasiado lento / CPU intensivo en los casos en que el conjunto de resultados era grande)
Polyline Quadkeys http://www.arc2earth.com/images/help/GAE_QKS_1.png
Polygon Quadkeys http://www.arc2earth.com/images/help/GAE_QKS_2.png
La convención de nomenclatura de quadkey utilizada anteriormente es bien conocida y, lo que es más importante, tiende a preservar la localidad (se describe más aquí )
El polígono de arriba se parece a esto: 0320101013123 03201010131212 03201010131213 0320101013132 0320101013133 03201010131302 03201010131303 032010101313002 032010101313003 03201010131131312 032010101313013 0320101010131313 032010101010131312 032010101313013 0320101010131312 032010101313013
Si los límites de la consulta son lo suficientemente pequeños, puede buscarlos directamente a través de qk. Esto es óptimo, ya que es solo una sola llamada RPC por lotes al almacén de datos GAE. si los límites son lo suficientemente grandes como para incluir demasiados qks posibles (> 1000), puede consultar alternativamente con un filtro (por ejemplo: qk> = 0320101013 y qk <= 0320101013 + \ ufffd). La convención de nomenclatura quadkey más la forma en que GAE indexa las cadenas permite que la consulta anterior recupere solo las cuadrículas existentes que caen por debajo de ese valor qk.
Hay otras advertencias y problemas de rendimiento, pero en general, es la capacidad de consultar en los quadkeys lo que lo hace factible.
ejemplos: consulta en condados de EE. UU . : geojson
Pros : bastante rápido, sin configuración de tamaño de cuadrícula, sin huella de memoria, sin cuadrículas superpobladas
Contras : se necesita preprocesamiento, posible sobrecarga en algunos escenarios, sin datos polares
Curvas de relleno espacial : eche un vistazo a la charla de Alfred NextGen Queries en Google I / O este año. La inclusión de curvas de relleno de espacio / tiempo genéricas junto con los nuevos operadores MultiQuery (ejecutados en paralelo) permitirá algunas consultas espaciales realmente geniales. ¿Va a superar el rendimiento tradicional de SQL? Difícil de decir pero debería escalar muy bien. Y nos estamos acercando rápidamente a un futuro en el que los dispositivos móviles siempre activos de todas las formas / tamaños aumentarán drásticamente el tráfico a su sitio / servicio.
Finalmente, también estaría de acuerdo en que debe observar muy de cerca su dominio problemático antes de elegir NoSQL sobre SQL. En nuestro caso, me gustó mucho el modelo de precios de GAE, por lo que realmente no había otra opción, pero si no necesita escalar, ahorre algo de tiempo y simplemente use un sql db estándar