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 , los ingenieros necesitan tener un conocimiento profundo de la arquitectura subyacente para poder . 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. Elasticsearch ingerir datos en streaming de manera eficiente 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 , lo que reduce la CPU necesaria para procesar inserciones, actualizaciones y eliminaciones. mutabilidad a nivel de campo En este blog, compararemos y contrastaremos cómo manejan la ingesta de datos y brindaremos técnicas prácticas para usar estos sistemas para análisis en tiempo real. Elasticsearch y Rockset 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. 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. Ingrese datos de una base de datos relacional en Elasticsearch utilizando el complemento de entrada Logstash JDBC. Logstash es una canalización de procesamiento de eventos que ingiere y transforma datos antes de enviarlos a Elasticsearch. Logstash ofrece un 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. complemento de entrada JDBC 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. . 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. Ingerir datos de Kafka en Elasticsearch utilizando Kafka Elasticsearch Sink Connector Confluent y Elastic se asociaron en el lanzamiento de , disponible para empresas que utilizan las ofertas administradas de Confluent Kafka y Elastic Elasticsearch. El conector requiere instalar y administrar herramientas adicionales, Kafka Connect. Kafka Elasticsearch Service Sink Connector 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 para Logstash para enviar datos a Elasticsearch. complemento Kafka de código abierto Elasticsearch ofrece la posibilidad de utilizar 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 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. Ingerir datos directamente desde la aplicación en Elasticsearch utilizando la API REST y las bibliotecas cliente bibliotecas cliente compatibles, colas y contrapresión Actualizaciones, inserciones y eliminaciones en Elasticsearch Elasticsearch tiene una 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. API de actualización 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, , 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. Bol.com Eliminaciones y desafíos de fusión de segmentos en Elasticsearch En Elasticsearch, pueden surgir desafíos relacionados con la y la recuperación de espacio. eliminación de documentos antiguos Elasticsearch completa una 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. combinación de segmentos Esto se debe a que Elasticsearch asume que todos los documentos tienen 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. un tamaño uniforme Desafíos de réplica en Elasticsearch Elasticsearch utiliza un 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 cuando se produce una actualización o inserción. modelo de respaldo primario reindexarse 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 . 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. API masiva 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. 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. La reindexación 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 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. API de alias 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: Rockset realiza un escaneo inicial de sus tablas en su base de datos OLTP y luego usa 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 bases de datos OLTP transmisiones CDC Con flujos de datos como 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 flujos de datos Kafka 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. Conectores integrados para lagos de datos y almacenes 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 , 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. base de datos fragmentada de documentos 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 , 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. índice convergente Bajo el capó, , 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 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. Rockset utiliza RocksDB name 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 , 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. las compactaciones remotas 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 permite 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. la ingesta sin esquema 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 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 hoy. migran de Elasticsearch a Rockset prueba gratis
