Actualizaciones, inserciones y eliminaciones de Elasticsearch: comprensión de cómo funcionan y sus limitaciones

Introducción

Administrar la transmisión de datos desde un sistema de origen, como PostgreSQL, MongoDB o DynamoDB, a un sistema posterior para búsqueda y análisis en tiempo real es un desafío para muchos equipos. El flujo de datos a menudo implica herramientas ETL complejas, así como integraciones autoadministrables para garantizar que las escrituras de gran volumen, incluidas las actualizaciones y eliminaciones, no acumule CPU ni afecte el rendimiento de la aplicación final.

Para un sistema como Elasticsearch , los ingenieros necesitan tener un conocimiento profundo de la arquitectura subyacente para poder ingerir datos en streaming de manera eficiente . Elasticsearch fue diseñado para análisis de registros donde los datos no cambian con frecuencia, lo que plantea desafíos adicionales al tratar con datos transaccionales.

Rockset, por otro lado, es una base de datos nativa de la nube, que elimina muchas de las herramientas y los gastos generales necesarios para introducir datos en el sistema. Como Rockset está diseñado específicamente para búsquedas y análisis en tiempo real, también ha sido diseñado para mutabilidad a nivel de campo , lo que reduce la CPU necesaria para procesar inserciones, actualizaciones y eliminaciones.

En este blog, compararemos y contrastaremos cómo Elasticsearch y Rockset manejan la ingesta de datos y brindaremos técnicas prácticas para usar estos sistemas para análisis en tiempo real.

búsqueda elástica

Ingestión de datos en Elasticsearch

Si bien hay muchas formas de incorporar datos en Elasticsearch, cubrimos tres métodos comunes para búsqueda y análisis en tiempo real:

• Ingerir datos de una base de datos relacional en Elasticsearch utilizando el complemento de entrada Logstash JDBC

• Ingerir datos de Kafka en Elasticsearch utilizando Kafka Elasticsearch Service Sink Connector

• Ingerir datos directamente desde la aplicación en Elasticsearch utilizando la API REST y las bibliotecas cliente.

  
  

Ingrese datos de una base de datos relacional en Elasticsearch utilizando el complemento de entrada Logstash JDBC. El complemento de entrada Logstash JDBC se puede utilizar para descargar datos de una base de datos relacional como PostgreSQL o MySQL a Elasticsearch para búsqueda y análisis.

Logstash es una canalización de procesamiento de eventos que ingiere y transforma datos antes de enviarlos a Elasticsearch. Logstash ofrece un complemento de entrada JDBC que sondea una base de datos relacional, como PostgreSQL o MySQL, en busca de inserciones y actualizaciones periódicamente. Para utilizar este servicio, su base de datos relacional debe proporcionar registros con marca de tiempo que Logstash pueda leer para determinar qué cambios se han producido.

Este enfoque de ingesta funciona bien para inserciones y actualizaciones, pero se necesitan consideraciones adicionales para las eliminaciones. Esto se debe a que Logstash no puede determinar qué se ha eliminado en su base de datos OLTP. Los usuarios pueden sortear esta limitación implementando eliminaciones temporales, donde se aplica una marca al registro eliminado y se usa para filtrar datos en el momento de la consulta. O pueden escanear periódicamente su base de datos relacional para obtener acceso a los registros más actualizados y volver a indexar los datos en Elasticsearch.

Ingerir datos de Kafka en Elasticsearch utilizando Kafka Elasticsearch Sink Connector . También es común usar una plataforma de transmisión de eventos como Kafka para enviar datos desde los sistemas de origen a Elasticsearch para realizar búsquedas y análisis en tiempo real.

Confluent y Elastic se asociaron en el lanzamiento de Kafka Elasticsearch Service Sink Connector , disponible para empresas que utilizan las ofertas administradas de Confluent Kafka y Elastic Elasticsearch. El conector requiere instalar y administrar herramientas adicionales, Kafka Connect.

Con el conector, puede asignar cada tema en Kafka a un único tipo de índice en Elasticsearch. Si se utiliza el tipo dinámico como tipo de índice, Elasticsearch admite algunos cambios de esquema, como agregar campos, eliminar campos y cambiar tipos.

Uno de los desafíos que surge al usar Kafka es la necesidad de reindexar los datos en Elasticsearch cuando desea modificar el analizador, el tokenizador o los campos indexados. Esto se debe a que la asignación no se puede cambiar una vez que ya está definida. Para realizar una reindexación de los datos, deberá escribir dos veces en el índice original y en el nuevo índice, mover los datos del índice original al nuevo índice y luego detener el trabajo del conector original.

Si no utiliza servicios administrados de Confluent o Elastic, puede usar el complemento Kafka de código abierto para Logstash para enviar datos a Elasticsearch.

Ingerir datos directamente desde la aplicación en Elasticsearch utilizando la API REST y las bibliotecas cliente Elasticsearch ofrece la posibilidad de utilizar bibliotecas cliente compatibles, incluidas Java, Javascript, Ruby, Go, Python y más, para ingerir datos a través de la API REST directamente desde su aplicación. Uno de los desafíos al usar una biblioteca cliente es que debe configurarse para funcionar con colas y contrapresión en el caso de que Elasticsearch no pueda manejar la carga de ingesta. Sin un sistema de colas, existe la posibilidad de que se pierdan datos en Elasticsearch.

Actualizaciones, inserciones y eliminaciones en Elasticsearch

Elasticsearch tiene una API de actualización que se puede utilizar para procesar actualizaciones y eliminaciones. La API de actualización reduce la cantidad de viajes de red y la posibilidad de conflictos de versiones. La API de actualización recupera el documento existente del índice, procesa el cambio y luego indexa los datos nuevamente. Dicho esto, Elasticsearch no ofrece actualizaciones ni eliminaciones in situ. Por lo tanto, aún es necesario reindexar todo el documento, una operación que requiere un uso intensivo de la CPU.

En el fondo, los datos de Elasticsearch se almacenan en un índice de Lucene y ese índice se divide en segmentos más pequeños. Cada segmento es inmutable por lo que los documentos no se pueden cambiar. Cuando se realiza una actualización, el documento antiguo se marca para su eliminación y un documento nuevo se fusiona para formar un nuevo segmento. Para utilizar el documento actualizado, es necesario ejecutar todos los analizadores, lo que también puede aumentar el uso de la CPU. Es común que los clientes con datos en constante cambio vean que las fusiones de índices consumen una cantidad considerable de su factura informática general de Elasticsearch.

Dada la cantidad de recursos necesarios, Elastic recomienda limitar la cantidad de actualizaciones en Elasticsearch. Un cliente de referencia de Elasticsearch, Bol.com , utilizó Elasticsearch para la búsqueda de sitios como parte de su plataforma de comercio electrónico. Bol.com recibió aproximadamente 700.000 actualizaciones por día de sus ofertas, incluidos cambios de contenido, precios y disponibilidad. Originalmente querían una solución que se mantuviera sincronizada con los cambios a medida que se producían. Pero, dado el impacto de las actualizaciones en el rendimiento del sistema Elasticsearch, optaron por permitir retrasos de 15 a 20 minutos. El procesamiento por lotes de documentos en Elasticsearch garantizó un rendimiento de consultas consistente.

Eliminaciones y desafíos de fusión de segmentos en Elasticsearch

En Elasticsearch, pueden surgir desafíos relacionados con la eliminación de documentos antiguos y la recuperación de espacio.

Elasticsearch completa una combinación de segmentos en segundo plano cuando hay una gran cantidad de segmentos en un índice o hay muchos documentos en un segmento que están marcados para su eliminación. Una combinación de segmentos se produce cuando los documentos se copian de segmentos existentes en un segmento recién formado y los segmentos restantes se eliminan. Desafortunadamente, Lucene no es bueno para dimensionar los segmentos que deben fusionarse, lo que podría crear segmentos desiguales que afecten el rendimiento y la estabilidad.

Esto se debe a que Elasticsearch asume que todos los documentos tienen un tamaño uniforme y toma decisiones de fusión en función de la cantidad de documentos eliminados. Cuando se trata de tamaños de documentos heterogéneos, como suele ser el caso en aplicaciones multiinquilino, algunos segmentos crecerán en tamaño más rápido que otros, lo que ralentizará el rendimiento para los clientes más grandes de la aplicación. En estos casos, el único remedio es reindexar una gran cantidad de datos.

Desafíos de réplica en Elasticsearch

Elasticsearch utiliza un modelo de respaldo primario para la replicación. La réplica principal procesa una operación de escritura entrante y luego reenvía la operación a sus réplicas. Cada réplica recibe esta operación y vuelve a indexar los datos localmente. Esto significa que cada réplica gasta de forma independiente costosos recursos informáticos para volver a indexar el mismo documento una y otra vez. Si hay n réplicas, Elastic gastaría n veces la CPU para indexar el mismo documento. Esto puede exacerbar la cantidad de datos que deben reindexarse cuando se produce una actualización o inserción.

Desafíos de colas y API masivas en Elasticsearch

Si bien puedes usar la API de actualización en Elasticsearch, generalmente se recomienda realizar cambios frecuentes por lotes usando la API masiva . Al utilizar Bulk API, los equipos de ingeniería a menudo necesitarán crear y administrar una cola para agilizar las actualizaciones en el sistema.

Una cola es independiente de Elasticsearch y será necesario configurarla y administrarla. La cola consolidará las inserciones, actualizaciones y eliminaciones en el sistema dentro de un intervalo de tiempo específico, digamos 15 minutos, para limitar el impacto en Elasticsearch. El sistema de cola también aplicará un acelerador cuando la tasa de inserción sea alta para garantizar la estabilidad de la aplicación. Si bien las colas son útiles para las actualizaciones, no son buenas para determinar cuándo hay muchos cambios de datos que requieren una reindexación completa de los datos. Esto puede ocurrir en cualquier momento si hay muchas actualizaciones en el sistema. Es común que los equipos que ejecutan Elastic a escala tengan miembros de operaciones dedicados a administrar y ajustar sus colas diariamente.

Reindexar en Elasticsearch

Como se mencionó en la sección anterior, cuando hay una gran cantidad de actualizaciones o necesita cambiar las asignaciones de índice, se produce una reindexación de datos. La reindexación es propensa a errores y tiene el potencial de eliminar un clúster. Lo que es aún más aterrador es que la reindexación puede ocurrir en cualquier momento.

Si desea cambiar sus asignaciones, tiene más control sobre el momento en que se produce la reindexación. Elasticsearch tiene una API de reindexación para crear un nuevo índice y una API de alias para garantizar que no haya tiempo de inactividad cuando se crea un nuevo índice. Con una API de alias, las consultas se enrutan al alias o al índice anterior a medida que se crea el nuevo índice. Cuando el nuevo índice esté listo, la API de alias se convertirá para leer datos del nuevo índice.

Con la API de alias, sigue siendo complicado mantener el nuevo índice sincronizado con los datos más recientes. Esto se debe a que Elasticsearch solo puede escribir datos en un índice. Por lo tanto, deberá configurar la canalización de datos ascendente para escribir dos veces en el índice nuevo y antiguo.

conjunto de rocas

Ingestión de datos en Rockset

Rockset utiliza conectores integrados para mantener sus datos sincronizados con los sistemas de origen. Los conectores administrados de Rockset están ajustados para cada tipo de fuente de datos para que los datos puedan ser ingeridos y consultables en 2 segundos. Esto evita canalizaciones manuales que agregan latencia o que solo pueden ingerir datos en microlotes, digamos cada 15 minutos.

A alto nivel, Rockset ofrece conectores integrados para bases de datos OLTP, flujos de datos, lagos y almacenes de datos. Así es como funcionan:

Conectores integrados para bases de datos OLTP Rockset realiza un escaneo inicial de sus tablas en su base de datos OLTP y luego usa transmisiones CDC para mantenerse sincronizado con los datos más recientes, y los datos están disponibles para consultas dentro de los 2 segundos posteriores al momento en que fueron generados por el sistema fuente.

Conectores integrados para flujos de datos Con flujos de datos como Kafka o Kinesis, Rockset ingiere continuamente cualquier tema nuevo mediante una integración basada en extracción que no requiere ajustes en Kafka o Kinesis.

Conectores integrados para lagos de datos y almacenes Rockset monitorea constantemente las actualizaciones e ingiere cualquier objeto nuevo de lagos de datos como depósitos S3. Generalmente encontramos que los equipos quieren unir transmisiones en tiempo real con datos de sus lagos de datos para realizar análisis en tiempo real.

Actualizaciones, inserciones y eliminaciones en Rockset

Rockset tiene una arquitectura distribuida optimizada para indexar datos de manera eficiente en paralelo en múltiples máquinas.

Rockset es una base de datos fragmentada de documentos , por lo que escribe documentos completos en una sola máquina, en lugar de dividirlos y enviar los diferentes campos a diferentes máquinas. Debido a esto, es rápido agregar nuevos documentos para insertarlos o ubicar documentos existentes, según la clave principal _id para actualizaciones y eliminaciones.

Al igual que Elasticsearch, Rockset utiliza índices para recuperar datos de manera rápida y eficiente cuando se consultan. Sin embargo, a diferencia de otras bases de datos o motores de búsqueda, Rockset indexa los datos en el momento de la ingesta en un índice convergente , un índice que combina un almacén de columnas, un índice de búsqueda y un almacén de filas. El índice convergente almacena todos los valores de los campos como una serie de pares clave-valor. En el siguiente ejemplo puede ver un documento y luego cómo se almacena en Rockset.

Bajo el capó, Rockset utiliza RocksDB , un almacén de valores clave de alto rendimiento que hace que las mutaciones sean triviales. RocksDB admite escrituras y eliminaciones atómicas en diferentes claves. Si llega una actualización para el campo name de un documento, se deben actualizar exactamente 3 claves, una por índice. Los índices de otros campos del documento no se ven afectados, lo que significa que Rockset puede procesar actualizaciones de manera eficiente en lugar de desperdiciar ciclos actualizando índices de documentos completos cada vez.

Los documentos y matrices anidados también son tipos de datos de primera clase en Rockset, lo que significa que también se les aplica el mismo proceso de actualización, lo que hace que Rockset sea ideal para actualizaciones de datos almacenados en formatos modernos como JSON y Avro.

El equipo de Rockset también ha creado varias extensiones personalizadas para RocksDB para manejar escrituras y lecturas intensas, un patrón común en cargas de trabajo de análisis en tiempo real. Una de esas extensiones son las compactaciones remotas , que introducen una separación clara del cálculo de consultas y el cálculo de indexación en RocksDB Cloud. Esto permite a Rockset evitar que las escrituras interfieran con las lecturas. Gracias a estas mejoras, Rockset puede escalar sus escrituras según las necesidades de los clientes y poner a disposición datos nuevos para consultar incluso cuando se producen mutaciones en segundo plano.

Actualizaciones, inserciones y eliminaciones mediante la API de Rockset

Los usuarios de Rockset pueden usar el campo _id predeterminado o especificar un campo específico como clave principal. Este campo permite sobrescribir un documento o parte de un documento. La diferencia entre Rockset y Elasticsearch es que Rockset puede actualizar el valor de un campo individual sin necesidad de volver a indexar un documento completo.

Para actualizar documentos existentes en una colección usando la API de Rockset, puede realizar solicitudes al punto final de Documentos de parche. Para cada documento existente que desee actualizar, simplemente especifique el campo _id y una lista de operaciones de parche que se aplicarán al documento.

La API de Rockset también expone un punto final para agregar documentos para que pueda insertar datos directamente en sus colecciones desde el código de su aplicación. Para eliminar documentos existentes, simplemente especifique los campos _id de los documentos que desea eliminar y realice una solicitud al punto final de eliminación de documentos de la API de Rockset.

Manejo de réplicas en Rockset

A diferencia de Elasticsearch, solo una réplica en Rockset realiza la indexación y compactación utilizando compactaciones remotas de RocksDB. Esto reduce la cantidad de CPU necesaria para la indexación, especialmente cuando se utilizan varias réplicas para mayor durabilidad.

Reindexación en Rockset

En el momento de la ingesta en Rockset, puede utilizar una transformación de ingesta para especificar las transformaciones de datos que desea aplicar en sus datos de origen sin procesar. Si desea cambiar la transformación de ingesta en una fecha posterior, deberá volver a indexar sus datos.

Dicho esto, Rockset permitela ingesta sin esquema y escribe dinámicamente los valores de cada campo de datos. Si el tamaño y la forma de los datos o las consultas cambian, Rockset seguirá funcionando y no requerirá que los datos se vuelvan a indexar.

Rockset puede escalar a cientos de terabytes de datos sin necesidad de volver a indexarlos. Esto se remonta a la estrategia de fragmentación de Rockset. Cuando aumenta la computación que un cliente asigna en su instancia virtual, un subconjunto de fragmentos se mezcla para lograr una mejor distribución en todo el clúster, lo que permite una indexación y ejecución de consultas más paralelizadas y más rápidas. Como resultado, no es necesario reindexar en estos escenarios.

Conclusión

Elasticsearch fue diseñado para análisis de registros donde los datos no se actualizan, insertan o eliminan con frecuencia. Con el tiempo, los equipos han ampliado el uso de Elasticsearch, utilizando a menudo Elasticsearch como almacén de datos secundario y motor de indexación para análisis en tiempo real de datos transaccionales en constante cambio. Esto puede ser una tarea costosa, especialmente para los equipos que optimizan la ingesta de datos en tiempo real, además de implicar una cantidad considerable de gastos generales de gestión.

Rockset, por otro lado, fue diseñado para análisis en tiempo real y para hacer que los nuevos datos estén disponibles para consultar dentro de los 2 segundos posteriores a su generación. Para resolver este caso de uso, Rockset admite inserciones, actualizaciones y eliminaciones in situ, lo que ahorra en cálculo y limita el uso de la reindexación de documentos. Rockset también reconoce la sobrecarga de gestión de los conectores y la ingestión y adopta un enfoque de plataforma, incorporando conectores en tiempo real a su oferta de nube.

En general, hemos visto empresas que migran de Elasticsearch a Rockset para realizar análisis en tiempo real y ahorrar un 44% solo en su factura de computación. Únase a la ola de equipos de ingeniería que cambian de Elasticsearch a Rockset en unos días. Comience su prueba gratis hoy.