Búsqueda detallada en un gran conjunto de datos

Tengo aproximadamente 4 millones de registros por día y tengo que mantener 7 años en línea, por lo que estamos buscando 10,2 mil millones de registros que necesito para poder buscarlos. Los usuarios esperan que la búsqueda sea lo suficientemente rápida para una interfaz de usuario, resultados en 3-5s

Debido a políticas fuera de mi control, no puedo usar una solución de base de datos lista para usar porque significa que tendré que entregar la base de datos a otro equipo para que la administre (no pregunte), lo que significa que pierdo la capacidad de optimizar el hardware y software ya que tienen un servicio único para bases de datos y cobran (internamente) por el GB. Estoy seguro de que recibiré comentarios que sugieran que hago el punto, ya tengo y la gerencia entiende que lo que me piden que haga es ridículo.

He estado buscando usar Lucene como el quid de mi solución. Almacenar los datos reales particionados por tipo y por día en archivos planos. Luego, usando un documento de Lucene para indexar algunos de los campos que se buscan, con el único campo "Almacenado" que es la identificación del registro (para que pueda leerlo desde el archivo plano)

No estoy exactamente informado sobre Lucene o los discos duros, pero según tengo entendido, habrá un tiempo inicial de E / S para buscar en el índice, luego, cuando tenga todas las ID de documentos de Lucene, leo los documentos que generarán más IO / buscando tiempo, luego leí el registro real desde el piso plano ... No puedo imaginar, dado el tamaño del conjunto de datos, que esto será muy rápido, ¿por qué estoy un poco preocupado?

Lucene tiene un tamaño máximo de documento de 2.1 billones por índice, por lo que requeriré varias indicaciones aquí.

¿Parece que este enfoque, a primera vista, podría funcionar?

Los datos que estoy almacenando son datos de acción de eventos. La mayoría de las consultas se agruparán por ID de evento y obtendrán los últimos detalles de acción de evento para un evento en particular. Algunas de las consultas analizarán eventos de conjuntos grandes y sus acciones de eventos individuales.

No ha dicho qué tan grandes son los datos, qué tan grandes son los campos individuales o qué presupuesto tiene.

Independientemente del sistema de indexación que elija, considere lanzar hardware al problema. No debería necesitar buscar nada en los discos. Indexe todos los datos, utilizando un esquema que es muy rápido de recorrer (tal vez una lista ordenada o un árbol). Almacene el índice en el disco, pero luego guarde en caché todo el índice en la RAM. Es posible que necesite decenas, o incluso cientos de gigabytes de RAM para hacer eso.

Si los campos individuales son grandes o de tamaño variable, considere indexar hashes de ellos.

El precio para que el servidor haga eso podría ser aterrador.

Ignorando todos los detalles técnicos, este es un problema de organización / administración y debe ser resuelto por la administración de su organización.

Su gerente tiene que estar dispuesto a patear el problema arriba y / o hacer que sus usuarios planteen el problema a un alto nivel.

A su nivel, reúna o solicite un presupuesto para hacerlo con Oracle y hardware de Oracle. Luego, haga una estimación realista de un clúster Hadoop.

A pesar de la exageración, estos clústeres no son baratos (probablemente necesite algo como 18 nodos de procesador con memoria de 64 GB y discos de 4 x 2 TB repartidos en tres bastidores y luego otros 4 nodos para el catálogo, etc.). No subestimar ; si ganas tendrás que implementarlo.

Entonces, primero volvamos a plantear claramente el problema en términos de sus requisitos:

1. El sistema almacenará un mínimo de 4 millones de registros por día.
2. El sistema proporcionará una interfaz de búsqueda para el usuario
   2.1. La capacidad de búsqueda devolverá resultados en un máximo de 3 segundos.
3. El sistema debe ser capaz de buscar un mínimo de 10,2 mil millones de registros.
4. El sistema utilizará una base de datos diseñada a medida
   4.1. El sistema deberá tener hardware y software optimizados para que la base de datos se desarrolle

Probablemente existan requisitos no funcionales adicionales, así como detalles sobre el tamaño de los registros individuales, que probablemente sean relevantes para su situación.

La respuesta corta es que tiene un problema de requisitos. Si observa estos requisitos, tres de ellos (los primeros tres) se aplican correctamente al sistema para definir su función y comportamiento. El último requisito no es un requisito válido desde una perspectiva purista, pero he visto este tipo de requisitos en declaraciones de trabajo.

Entonces, la forma en que se resuelve este problema es estimar el costo del cuarto requisito, dados los otros tres. Una vez que haga eso, preséntelo como el costo de su solución. La gerencia entrará en pánico e inmediatamente le preguntará por qué el problema no puede resolverse a un precio razonable. Ese es el punto de entrada para su discusión sobre lo que debe suceder. Tenga una alternativa asequible disponible y lista para presentar.

Esto está en contraste con lo que está haciendo en este momento, lo que supone que los otros tres no pueden cumplirse dado el último. La gerencia no lo entiende, porque todo lo que ven son signos de dólar.

Si estuviera en su lugar, comenzaría con una implementación muy razonable, por escrito, utilizando nada más que un RDBMS regular, incrustado en la aplicación, para que no sientan que tienen que soportar algo. SQLite, H2 o cualquier otra base de datos incrustada alternativa debe hacer lo siguiente: sin archivos planos especiales, sin índices exóticos, sin nada: solo una aplicación directa de prácticas estándar para resolver el problema en cuestión, en su mayor parte sin tener en cuenta la inmensidad de los datos. (Por supuesto, elegiría un número entero lo suficientemente grande como clave, y eso es todo, más o menos).

Mientras trabajaba en él, probablemente se me ocurrirían un par de ideas más sobre cómo hacer que funcione más rápido sin recurrir a nada exótico.

Luego, probaría esto para ver cómo funciona, y demostraría los resultados, junto con la solución de trabajo, a los "poderes del ser" en su organización.

1. Existe la posibilidad de que su implementación directa se realice dentro de las restricciones requeridas, por lo que estará bien allí, sin necesidad de hacer nada más, sin desperdicio de recursos.

2. Si el rendimiento de la implementación directa está fuera, pero no muy lejos de las restricciones requeridas, los "poderes del ser" podrían decir "bueno, esto es lo suficientemente cerca, no queremos hacer nada más al respecto, así que eso es lo que será ". Nuevamente, cero recursos desperdiciados.

3. Si el rendimiento de la implementación directa es externo, pero dentro del mismo orden de magnitud, de las restricciones requeridas, les diría que solo compren hardware mejor, más grande y más rápido. Lo más probable es que lo hagan y caso cerrado.

4. Si no quieren comprar un hardware mejor, más grande y más rápido, les recomendaría que reconsideren su requisito de abstenerse de usar un RDBMS grande y escalable. Si son razonables y usted ha demostrado que también lo es, es probable que lo reconsideren.

5. Si los poderes del ser no quieren seguir ninguna de las vías razonables, y en cambio quieren que juegues el papel de un mago, entonces y solo entonces comenzaría a preocuparme por las soluciones exóticas. Hay muchas posibilidades de que las cosas no lleguen a ese punto. Pero incluso si lo hacen, la cantidad de trabajo que habrá realizado en vano hasta ese momento será relativamente pequeña, y vale la pena la apuesta que podría ser suficiente.

Pensando desde el frente ...

Si separa sus tipos de búsqueda en la interfaz de usuario, es posible que pueda tener restricciones más razonables.

Parece que un tipo de búsqueda son datos recientes de acción de evento en un evento, lo que le permite aislar por tiempo en su búsqueda de datos. Esto quizás proporcione un conjunto de datos mucho más pequeño, con la expectativa probable de que un usuario los recupere algo pronto.

A otros tipos de búsqueda, en los que se deben realizar grandes conjuntos de datos o búsquedas de marcos de tiempo anteriores, se les puede dar una interfaz de usuario diferente (o varias interfaces de usuario), con un buen spinner para indicar ... pensando ahora. Como el usuario puede entender que se trata de un conjunto de requisitos más laborioso, cabe esperar razonablemente paciencia. Y, por supuesto, realistamente necesario.

No sé si tiene alguna capacidad para impactar el diseño frontal, pero si puede transmitir las restricciones con las que está trabajando, es de esperar que quienes manejan la interacción del usuario respondan con comprensión (al menos algunas).