Elasticsearch es un motor de búsqueda y análisis distribuido y de código abierto basado en creado con Apache Lucene para proporcionar una funcionalidad de búsqueda rápida en tiempo real. Es un almacén de datos NoSQL orientado a documentos, escalable y sin esquemas de forma predeterminada. Elasticsearch está diseñado para funcionar a escala con grandes conjuntos de datos. Como motor de búsqueda, proporciona capacidades de búsqueda e indexación rápidas que se pueden escalar horizontalmente en múltiples nodos. JSON Enchufe descarado: es una base de datos de indexación en tiempo real en la nube. Crea automáticamente índices que están optimizados no solo para la búsqueda sino también para agregaciones y uniones, lo que hace que sea rápido y fácil para sus aplicaciones consultar datos, independientemente de dónde provienen y en qué formato se encuentran. Pero esta publicación trata de resaltar algunas soluciones , en caso de que realmente desee realizar uniones de estilo SQL en Elasticsearch. Rockset ¿Por qué son importantes las relaciones de datos? Vivimos en un mundo altamente conectado donde el manejo de las relaciones de datos es importante. Las bases de datos relacionales son buenas para manejar relaciones, pero con los requisitos comerciales en constante cambio, el esquema fijo de estas bases de datos genera problemas de escalabilidad y rendimiento. El uso de almacenes de datos NoSQL se está volviendo cada vez más popular debido a su capacidad para abordar varios desafíos asociados con los enfoques tradicionales de manejo de datos. Las empresas se enfrentan continuamente a estructuras de datos complejas en las que se requieren agregaciones, uniones y capacidades de filtrado para analizar los datos. Con la explosión de datos no estructurados, hay un número creciente de casos de uso que requieren la unión de datos de diferentes fuentes con fines de análisis de datos. Si bien las uniones son principalmente un concepto de SQL, también son igualmente importantes en el mundo NoSQL. Las uniones de estilo SQL no son compatibles con Elasticsearch como ciudadanos de primera clase. Este artículo analizará cómo definir relaciones en Elasticsearch utilizando diversas técnicas, como desnormalización, uniones del lado de la aplicación, documentos anidados y relaciones entre padres e hijos. También explorará los casos de uso y los desafíos asociados con cada enfoque. Cómo lidiar con las relaciones en Elasticsearch Debido a que Elasticsearch no es una base de datos relacional, las uniones no existen como funcionalidad nativa como en una base de datos SQL. Se centra más en la eficiencia de la búsqueda que en la eficiencia del almacenamiento. Los datos almacenados prácticamente se aplanan o se desnormalizan para impulsar casos de uso de búsqueda rápida. Hay varias formas de definir relaciones en Elasticsearch. Según su caso de uso, puede seleccionar una de las siguientes técnicas en Elasticsearch para modelar sus datos: Relaciones uno a uno: mapeo de objetos Relaciones uno a muchos: documentos anidados y el modelo padre-hijo Relaciones de muchos a muchos: desnormalización y uniones del lado de la aplicación Las asignaciones de objetos uno a uno son simples y no se discutirán mucho aquí. El resto de este blog cubrirá los otros dos escenarios con más detalle. Administrar su modelo de datos en Elasticsearch Existen cuatro enfoques comunes para gestionar datos en Elasticsearch: Desnormalización Uniones del lado de la aplicación Objetos anidados Relaciones entre padres e hijos Desnormalización La desnormalización proporciona el mejor rendimiento de búsqueda de consultas en Elasticsearch, ya que no es necesario unir conjuntos de datos en el momento de la consulta. Cada documento es independiente y contiene todos los datos necesarios, eliminando así la necesidad de costosas operaciones de unión. Con la desnormalización, los datos se almacenan en una estructura aplanada en el momento de la indexación. Aunque esto aumenta el tamaño del documento y da como resultado el almacenamiento de datos duplicados en cada documento. El espacio en disco no es un bien caro y por lo tanto no es motivo de preocupación. Casos de uso para la desnormalización Al trabajar con sistemas distribuidos, tener que unir conjuntos de datos a través de la red puede introducir latencias significativas. Puede evitar estas costosas operaciones de unión desnormalizando los datos. Las relaciones de muchos a muchos se pueden manejar mediante el aplanamiento de datos. Desafíos de la desnormalización de datos La duplicación de datos en documentos acoplados requiere espacio de almacenamiento adicional. La gestión de datos en una estructura plana genera una sobrecarga adicional para los conjuntos de datos que son de naturaleza relacional. Desde una perspectiva de programación, la desnormalización requiere una sobrecarga de ingeniería adicional. Deberá escribir código adicional para aplanar los datos almacenados en varias tablas relacionales y asignarlos a un único objeto en Elasticsearch. Desnormalizar datos no es una buena idea si sus datos cambian con frecuencia. En tales casos, la desnormalización requeriría actualizar todos los documentos cuando cualquier subconjunto de datos cambiara y, por lo tanto, debería evitarse. La operación de indexación lleva más tiempo con conjuntos de datos aplanados, ya que se indexan más datos. Si sus datos cambian con frecuencia, esto indicaría que su tasa de indexación es mayor, lo que puede causar problemas de rendimiento del clúster. Uniones del lado de la aplicación Las uniones del lado de la aplicación se pueden utilizar cuando es necesario mantener la relación entre documentos. Los datos se almacenan en índices separados y las operaciones de unión se pueden realizar desde el lado de la aplicación durante el tiempo de consulta. Sin embargo, esto implica ejecutar consultas adicionales en el momento de la búsqueda desde su aplicación para unir documentos. Casos de uso para uniones del lado de la aplicación Las uniones del lado de la aplicación garantizan que los datos permanezcan normalizados. Las modificaciones se realizan en un solo lugar y no es necesario actualizar constantemente sus documentos. Con este enfoque se minimiza la redundancia de datos. Este método funciona bien cuando hay menos documentos y los cambios de datos son menos frecuentes. Desafíos con las uniones del lado de la aplicación La aplicación necesita ejecutar múltiples consultas para unir documentos en el momento de la búsqueda. Si el conjunto de datos tiene muchos consumidores, deberá ejecutar el mismo conjunto de consultas varias veces, lo que puede provocar problemas de rendimiento. Por lo tanto, este enfoque no aprovecha el poder real de Elasticsearch. Este enfoque resulta en complejidad a nivel de implementación. Requiere escribir código adicional a nivel de aplicación para implementar operaciones de unión para establecer una relación entre documentos. Objetos anidados El enfoque anidado se puede utilizar si necesita mantener la relación de cada objeto en la matriz. Los documentos anidados se almacenan internamente como documentos Lucene separados y se pueden unir en el momento de la consulta. Son uniones en tiempo de índice, donde se almacenan múltiples documentos de Lucene en un solo bloque. Desde la perspectiva de la aplicación, el bloque parece un único documento de Elasticsearch. Por tanto, la consulta es relativamente más rápida, ya que todos los datos residen en el mismo objeto. Los documentos anidados tratan con relaciones de uno a muchos. Casos de uso para documentos anidados Se prefiere la creación de documentos anidados cuando sus documentos contienen matrices de objetos. La Figura 1 a continuación muestra cómo el tipo anidado en Elasticsearch permite indexar internamente matrices de objetos como documentos Lucene separados. Lucene no tiene concepto de objetos internos, por lo que es interesante ver cómo Elasticsearch transforma internamente el documento original en campos aplanados de valores múltiples. Una ventaja de utilizar consultas anidadas es que no realizará coincidencias entre objetos, por lo que se evitan resultados de coincidencias inesperados. Es consciente de los límites de los objetos, lo que hace que las búsquedas sean más precisas. Figura 1: Matrices de objetos indexados internamente como documentos Lucene separados en Elasticsearch utilizando un enfoque anidado Desafíos con objetos anidados El objeto raíz y sus objetos anidados deben reindexarse completamente para poder agregar/actualizar/eliminar un objeto anidado. En otras palabras, una actualización del registro secundario dará como resultado la reindexación de todo el documento. No se puede acceder directamente a los documentos anidados. Sólo se puede acceder a ellos mediante su documento raíz relacionado. Las solicitudes de búsqueda devuelven el documento completo en lugar de devolver solo los documentos anidados que coinciden con la consulta de búsqueda. Si su conjunto de datos cambia con frecuencia, el uso de documentos anidados generará una gran cantidad de actualizaciones. Relaciones entre padres e hijos Las relaciones padre-hijo aprovechan el para separar completamente los objetos con relaciones en documentos individuales: padre e hijo. Esto le permite almacenar documentos en una estructura relacional en documentos de Elasticsearch separados que se pueden actualizar por separado. tipo de datos de unión Las relaciones entre padres e hijos son beneficiosas cuando los documentos deben actualizarse con frecuencia. Por lo tanto, este enfoque es ideal para escenarios en los que los datos cambian con frecuencia. Básicamente, separa el documento base en varios documentos que contienen padre e hijo. Esto permite indexar/actualizar/eliminar los documentos principal y secundario de forma independiente uno del otro. Búsqueda en documentos principales y secundarios Para optimizar el rendimiento de Elasticsearch durante la indexación y la búsqueda, la recomendación general es garantizar que el tamaño del documento no sea grande. Puede aprovechar el modelo padre-hijo para dividir su documento en documentos separados. Sin embargo, existen algunos desafíos para implementar esto. Los documentos principales y secundarios deben enrutarse al mismo fragmento para que unirlos durante el tiempo de consulta sea eficiente y en memoria. El ID principal debe usarse como valor de ruta para el documento secundario. El campo proporciona a Elasticsearch el ID y el tipo del documento principal, lo que internamente le permite enrutar los documentos secundarios al mismo fragmento que el documento principal. _parent Elasticsearch le permite buscar desde objetos JSON complejos. Sin embargo, esto requiere una comprensión profunda de la estructura de datos para realizar consultas eficientes desde ellos. El modelo padre-hijo aprovecha múltiples filtros para simplificar la funcionalidad de búsqueda: consulta has_child Devuelve documentos principales que tienen documentos secundarios que coinciden con la consulta. consulta has_parent Acepta un padre y devuelve documentos secundarios que los padres asociados han coincidente. consulta inner_hits Obtiene información relevante sobre los niños de la consulta . has_child La Figura 2 muestra cómo se puede utilizar el modelo padre-hijo para demostrar relaciones de uno a muchos. Los documentos secundarios se pueden agregar/eliminar/actualizar sin afectar al padre. Lo mismo se aplica al documento principal, que se puede actualizar sin volver a indexar los elementos secundarios. Figura 2: Modelo padre-hijo para relaciones de uno a muchos Desafíos con las relaciones entre padres e hijos Las consultas son más caras y consumen mucha memoria debido a la operación de unión. Las construcciones padre-hijo suponen una sobrecarga, ya que son documentos separados que deben unirse en el momento de la consulta. Es necesario garantizar que el padre y todos sus hijos existan en el mismo fragmento. El almacenamiento de documentos con relaciones padre-hijo implica una complejidad de implementación. Conclusión Elegir el diseño de Elasticsearch adecuado es fundamental para el rendimiento y la capacidad de mantenimiento de las aplicaciones. Al diseñar su modelo de datos en Elasticsearch, es importante tener en cuenta los diversos pros y contras de cada uno de los cuatro métodos de modelado que se analizan en este documento. de modelado de datos En este artículo, exploramos cómo los objetos anidados y las relaciones padre-hijo permiten operaciones de unión similares a SQL en Elasticsearch. También puede implementar una lógica personalizada en su aplicación para manejar las relaciones con uniones del lado de la aplicación. Para casos de uso en los que necesita unir varios conjuntos de datos en Elasticsearch, puede ingerir y cargar ambos conjuntos de datos en el índice de Elasticsearch para permitir consultas de alto rendimiento. De fábrica, Elasticsearch no tiene combinaciones como en una base de datos SQL. Si bien existen posibles soluciones para establecer relaciones en sus documentos, es importante ser consciente de los desafíos que presenta cada uno de estos enfoques. Uso de uniones SQL nativas con Rockset Cuando es necesario combinar varios conjuntos de datos para realizar análisis en tiempo real, una base de datos que proporcione uniones SQL nativas puede manejar mejor este caso de uso. Al igual que Elasticsearch, Rockset se utiliza como capa de indexación de datos de bases de datos, flujos de eventos y lagos de datos, lo que permite la ingesta sin esquema de estas fuentes. A diferencia de Elasticsearch, Rockset brinda la capacidad de , incluidas combinaciones, lo que le brinda una mayor flexibilidad sobre cómo puede usar sus datos. realizar consultas con SQL con todas las funciones También publicado . aquí
