ES:API de Overpass/Detalles técnicos

API de Overpass · Referencia de lenguaje · Guía de lenguaje · Términos técnicos · Áreas · Ejemplos de consultas · Edición dispersa · ID permanente · Preguntas frecuentes · más (español) · Sitio web
Estado de servidores · Versiones · Desarrollo · Diseño técnico · Instalación · Capa de compatibilidad XAPI · Esquemas de transporte público · Aplicaciones · Código fuente e incidencias

Overpass turbo · Asistente · Atajos de Overpass turbo · Hojas de estilo MapCSS · Exportar a GeoJSON · más (español) · Desarrollo · Código fuente e incidencias · Sitio web

Overpass Ultra · Examples · Overpass Ultra extensions · Hojas de estilo MapLibre · URL Params · más (español) · Código fuente e incidencias · Sitio web

En esta página se esbozan algunas consideraciones y conclusiones experimentales en el diseño del software de la API de Overpass que pueden ser relevantes para otras bases de datos de OSM. La primera versión es una traducción del artículo preliminar en las actas de las conferencias (de) del FOSSGIS 2012.

Latencia del disco duro: el verdadero cuello de botella

Nota: La API de Overpass suele funcionar en los SSDs hoy en día.

La primera versión de la API de Overpass en 2008 se basó en una base de datos relacional convencional, el motor MyISAM de MySQL. Esto era dolorosamente lento. La lectura de un millón de líneas de una tabla tomaba unos 600 segundos, incluso después de la optimización con la mejor biblioteca SQL posible de MySQL. Por el contrario, el backend hecho a medida, Template DB, solo necesitó de 3 a 5 segundos para el mismo trabajo.

Para entender esta diferencia se necesita saber más sobre el diseño de los backends de bases de datos: Los datos en sí se almacenan por línea en un lugar específico del disco duro. Las líneas recién insertadas toman los espacios que dejan las líneas eliminadas. Para hacer que algunas docenas o cientos de líneas sean rápidamente accesibles, se almacenan estructuras especiales de datos, los llamados índices, en el disco o en la memoria. Normalmente hay más de un índice para acelerar varios tipos de búsquedas, y la cuidadosa selección de los índices contribuye en gran medida al rendimiento de la base de datos. Para simplificar lo siguiente, asumimos que solo hay un índice. Con múltiples índices, las cosas son de hecho lo mismo o peor.

La cantidad de tiempo dominante se toma saltando a las diversas posiciones del archivo en el disco duro. Por lo tanto, una base de datos relacional está orientada a tener, en el mejor de los casos, una sola operación de búsqueda en el disco por línea. Si cada combinación de líneas es igualmente probable como resultado de una búsqueda, se puede demostrar que esta estrategia es óptima.

Sin embargo, esta suposición es enormemente errónea con los datos de OSM. Por lo general, un gran número de nodos espacialmente cercanos son consultados más a menudo juntos que los nodos dispersos. Por lo tanto, Template BD organiza grupos de nodos cercanos espacialmente juntos en bloques de datos. Dados los tiempos típicos de búsqueda (0.1 segundos) y de lectura (50 MB por segundo), esto es más rápido que el diseño relacional, ¡incluso si solo el 0.1 por ciento de los datos leídos son realmente relevantes para la consulta!

Para hacer accesible la proximidad espacial a OSM, los datos son procesados por una curva envolvente. Por medio de la evaluación comparativa, un tamaño de bloque de 512 KB ha resultado ser el más rápido.

Un afortunado efecto secundario de este diseño de bloques es que es tratado muy suavemente por las estrategias de cacheo de, al menos, el actual Linux: más del 99% de todos los accesos de lectura a los bloques se satisfacen desde el caché en lugar del disco duro. Véase las estadísticas munin: Aunque la relación entre el tráfico de salida y el de entrada es de entre 100 a 1 y 500 a 1, se realizan dos veces más accesos de escritura que accesos de lectura.

Curva envolvente

La resolución de las coordenadas en OpenStreetMap prefiere una cierta implementación: la latitud y la longitud pueden ser almacenadas cada una muy eficientemente en un entero de 32 bits. De hecho, la latitud emplea solo 31 bits, solo la longitud emplea los 32 bits completos. Para hacer una curva envolvente de ello, intercalamos la latitud y la longitud. Como índice, se usan los 32 bits superiores.

• 

  Todos los 316 rangos que han sido creados para el recuadro delimitador (49.0, 49.5, 7, 7.5), que coinciden con la curva envolvente de orden Z

• 

  Detalle de la curva envolvente

Para indexar también los objetos con extensión espacial, es decir, las vías y las relaciones, este concepto tiene que ampliarse ligeramente. Con este fin, el bit superior se emplea para marcar un índice como índice compuesto; el índice tomado es aproximadamente el ángulo suroeste del recuadro delimitador del objeto, y los bits inferiores del índice llevan información sobre el tamaño del recuadro delimitador. Así pues, cada vía se almacena en relativa proximidad a los nodos a los que se refiere. Por lo tanto, solo se deben buscar en pocos lugares del disco duro las características que pueden estar presentes en un determinado lugar.

Organización por tipo

Otro factor de 2 a 10 proviene de la separación de diferentes tipos de datos en un objeto. La API de Overpass solo puede tener un propósito generalizado si almacena todo tipo de datos de OSM. Pero diferentes tipos de consultas requieren diferentes subconjuntos de datos totales: la geometría de renderizado no requiere ni etiquetas ni metadatos, y varios casos de uso de procesamiento posterior como el renderizado general, el enrutamiento y la búsqueda al menos no requieren metadatos. Pero estos hacen la mayoría de todos los datos por volumen (base de datos a 23 de febrero de 2012):

• 29% son datos estructurales (geometría y membresía de elementos)
• 7% de datos de la etiqueta
• 47% de metadatos (marca de tiempo, versión, identificadores de conjunto de cambios, identificadores de usuario)
• 18% de datos auxiliares para hacer algunas consultas más rápidas

La separación de los metadatos ha llevado a una aceleración de un factor de 3 donde no se necesitaba. De la misma manera, separar los datos de la etiqueta del resto trajo una aceleración significativa. Esta observación es la razón para mantener separados los diferentes tipos de datos.

Transaccionalidad

La API de Overpass garantiza la transaccionalidad, es decir, que una consulta siempre se basa en un conjunto de datos coherentes, mediante copias en la sombra.

El diseño del sistema de gestión con un solo proceso de ejecución permite un solo proceso de escritura en paralelo, porque eso basta para el sistema de replicación de OSM.

Otros temas que vale la pena documentar

• Plantilla DB: archivos de mapa/bin, archivos de índice, compresión. Grupos, segmentos, estrategias de asignación, manejo de vacíos
• Algoritmo de cálculo de índices, vías <> nodos de navegación padre-hijo
• Consultas de áreas/polígonos: algoritmo
• Distribuidor: arquitectura, limitación de la tasa, resumen del comando de apoyo de alto nivel
• Backend: actualizaciones de la base de datos, incluyendo Attic, nodo, vía, relación, metactualizaciones, fusión
• Consulta de la ejecución de la línea

References

Traducción revisada por colaboradores del Wikiproyecto Traducción en español. Revisión: 2023-05-01.