Conjunto de datos geoespaciales grandes (> 22 billones de elementos) con rendimiento de consulta de lectura rápida (<1s)

Estoy en el proceso de diseñar un nuevo sistema para un gran conjunto de datos geoespaciales que requerirá un rendimiento de consulta de lectura rápida. Por lo tanto, quiero ver si alguien cree que es posible o tiene experiencia / consejos sobre DBMS adecuados, estructura de datos o métodos alternativos para lograr el rendimiento requerido en la siguiente situación:

Los datos se producirán continuamente a partir de datos de radar satelital procesados, que tendrán cobertura global. Basado en la resolución satelital y la cobertura terrestre del mundo, calculo el conjunto de datos completo para producir valores en 75 mil millones de ubicaciones discretas en el mundo. Durante la vida útil de un solo satélite, la salida producirá hasta 300 valores en cada una de estas ubicaciones (por lo tanto, un conjunto de datos total de> 22 billones de valores). Esto es para un satélite, y ya hay un segundo en órbita, con otros dos planeados en los nuevos años. ¡Entonces habrá muchos datos! Un solo elemento de datos es muy simple y solo consistirá en (longitud, latitud, valor), pero debido a la cantidad de elementos, calculo que un solo satélite producirá hasta 100TB.

Los datos escritos nunca deberían necesitar actualización, ya que solo crecerán a medida que se procesen nuevas adquisiciones de satélites. El rendimiento de escritura no es importante, pero el rendimiento de lectura es crucial. El objetivo de este proyecto es poder visualizar los datos a través de una interfaz simple como una capa sobre los mapas de Google, donde cada punto tiene un valor de color basado en su promedio, gradiente o alguna función a lo largo del tiempo. (demostración al final de la publicación).

A partir de estos requisitos, la base de datos debe ser escalable y es probable que busquemos soluciones en la nube. El sistema debe ser capaz de manejar consultas geoespaciales como "puntos cerca (lat, lon)" y "puntos dentro (recuadro)", y tener un rendimiento de lectura de <1s para localizar un solo punto y polígonos que contengan hasta 50,000 puntos (aunque sería preferible hasta 200,000 puntos).

Hasta ahora tengo un conjunto de datos de prueba de ~ 750 millones de elementos de datos en 111 millones de ubicaciones. He probado una instancia de postgres / postGIS, que funcionó bien, pero sin la posibilidad de fragmentar, no puedo hacer esto a medida que crecen los datos. También he probado una instancia de mongoDB, que nuevamente parece estar bien, así que lejos, y con el fragmentación puede ser suficiente escalar con el volumen de datos. Recientemente he aprendido un poco sobre Elasticsearch, por lo que cualquier comentario sobre esto sería útil, ya que es nuevo para mí.

Aquí hay una animación rápida de lo que queremos lograr con el conjunto de datos completo:

Este gif (de mi prueba de postgres) está sirviendo (6x3) mosaicos ráster precalculados, cada uno con ~ 200,000 puntos y tomando ~ 17s para generar cada uno. Al hacer clic en un punto, el gráfico se realiza al extraer todos los valores históricos en la ubicación más cercana en <1s.

Disculpas por la larga publicación, todos los comentarios / consejos son bienvenidos.

Podrías fragmentar por ubicación. Divida el globo en una cuadrícula y tenga cada cuadrado en esa cuadrícula en un servidor. Como mencionó la nube, eso sería adecuado para la nube. Por supuesto, deberá fusionar manualmente los resultados de varios servidores.

De esa manera, puede usar cualquier solución de base de datos que desee. No necesita ser escalable por sí solo.

Los cuadrados individuales tendrán diferentes cantidades de datos. Puede usar máquinas de diferentes tamaños para ellos (ya que esto es nube), o puede poner varios fragmentos pequeños en la misma máquina.

Este esquema de fragmentación es ideal para el tipo de consultas que realiza porque cada consulta solo tendrá que tocar muy pocas particiones. La fragmentación por tiempo es peor porque todos los fragmentos de tiempo se deben tocar para cada consulta. Fragmentación aleatoria tiene el mismo problema.

En general, este es un caso de fragmentación fácil porque el patrón de consulta se ajusta muy bien al esquema de fragmentación.

En realidad, me pregunto si necesitas una base de datos para esto. Tal vez pueda dividir el mundo en mosaicos de 1000x1000 o más pequeños y tener un archivo plano en el almacenamiento de blobs para cada mosaico. El almacenamiento de blobs no le importa en absoluto los blobs de 1M.

Ejecutar una consulta es conceptualmente muy fácil con este esquema de almacenamiento. También puede almacenar los datos de forma redundante en múltiples resoluciones de cuadrícula.

¿Qué tan actualizadas deben ser sus consultas de lectura?

Puede dividir la base de datos por tiempo si el mapa solo necesita mostrar la medición más reciente. Esto reduciría su carga de consultas para el mapa.

Para el historial de un punto dado, puede mantener una segunda tienda con x e y mostrando el historial. Esto podría hacerse con una actualización / actualización nocturna ya que los datos históricos no cambiarán.

Luego, podría calcular previamente los promedios a resoluciones más gruesas para integrarse con mapas en diferentes niveles de zoom. Esto reduciría el número de puntos a recuperar para áreas de mapa grandes (alejar). Se utilizarían resoluciones más precisas para mapas más ampliados que consultaban áreas más pequeñas. Si realmente necesita acelerar esto, puede calcular mosaicos como blobs e interpretarlos en su aplicación.

Debido a que esto implicaría una nueva computación de la información agregada, habría cierta latencia en los resultados de la consulta. Dependiendo de cuánta latencia sea aceptable, podría usar este tipo de enfoque para optimizar sus lecturas.

OK, entonces sus puntos necesitan ser promedios calculados a lo largo del tiempo. Con este cálculo, supongo que sus consultas reales se reducen bastante de 22 billones de elementos, ya que los valores ráster se pueden calcular previamente para realizar consultas.

Parece que hay dos clases de consulta: una para comprender qué ubicaciones se encuentran dentro de la ventana de vista actual y otra para entregar la estadística deseada para esos puntos. Mi sugerencia es utilizar herramientas separadas y especializadas para cada uno.

Supongo que todas las mediciones se relacionan con el mismo conjunto de puntos 75Bn. Estos lat / longs, una vez establecidos, son por lo tanto estáticos. Se pueden agrupar, agregar e indexar a un costo único. Por lo tanto, sugeriría fragmentación por región y nivel de zoom. El tamaño de cada fragmento dependerá del rendimiento que se pueda lograr desde cada instancia de SIG.

El SIG devolverá un conjunto de puntos que se pasan a una base de datos de series de tiempo. Esto contiene los valores medidos y realiza agregados. KDB es uno que conozco. Está dirigido al comercio de valores, que tendrá menos claves pero más puntos de datos por clave que su escenario.

La transferencia de los valores clave del servidor SIG a la base de datos de tiempo tendrá un costo. Mi hipótesis es que este costo será pagado por el procesamiento más rápido en la DB de series de tiempo específicas de la tarea. Según la redacción de la pregunta, parece que una sola instancia no podrá contener todos los datos, por lo que parte del tráfico entre servidores parece inevitable. Dada la velocidad relativa de los componentes, parece probable que enviar un conjunto de claves a un servidor remoto que tenga los datos en caché sea más rápido que leer los datos del disco local.

Si las partes de búsqueda de puntos y cálculo de valor pueden ser locales entre sí, por supuesto, esperaría que la respuesta sea más rápida. Mi comprensión (limitada) es que encontrar los N vecinos más cercanos a un punto dado es una tarea no trivial. Es por eso que sugerí usar un software específico para realizarlo. Si la búsqueda de puntos se puede reducir a

where latitude between x1 and x2
and logitude between y1 and y2

entonces esa parte podría ser manejada por el software de almacenamiento de valor y el SIG eliminado de la arquitectura.

No he implementado tal sistema. Realmente solo estoy pensando en voz alta aquí. En la escala de petabytes no hay soluciones disponibles. Sin embargo, hay muchos proveedores de datos satelitales, por lo que su problema es manejable. Buena suerte.