Comparemos y contrastemos la indexación de búsqueda con la indexación en tiempo actual indexación convergente y explique qué es la indexación convergente, en qué se parece, en qué se diferencia, cómo se configura la arquitectura y luego revise algunos de los detalles de cómo es diferente en términos de operaciones.
Cuando se habla de sistemas sin servidor y sistemas nativos de la nube, hay una gran ventaja que tenemos en la nube y realmente queremos dedicar un tiempo a hablar sobre la configuración inicial, en términos de operaciones del día dos.
Fondo de indexación
La indexación de búsqueda ha existido por un tiempo. A medida que observamos dónde comenzó la indexación de búsqueda, sus raíces en la búsqueda de texto y luego, con el tiempo, todos los diferentes casos de uso para los que se utiliza, observamos algunos objetivos de diseño en términos de diseñar Rockset y diseñar la indexación convergente de manera un poco diferente.
Uno de nuestros principales objetivos en Rockset es ayudar a nuestros clientes a escalar mejor en la nube. El segundo es más flexibilidad, especialmente ahora en los últimos años con la forma en que han cambiado los datos, cómo la forma de los datos que provienen de muchos lugares diferentes tiende a ser completamente diferente y cómo se utilizan para tipos de aplicaciones muy diferentes. ¿Cómo te damos más? flexibilidad de consulta de esquema? Y el último es de operaciones bajas.
Escala de indexación
En lo que respecta a la velocidad y la escala, estamos viendo nuevos datos que se pueden consultar en aproximadamente dos segundos, con P95 de dos segundos, incluso si ingresan millones de escrituras por segundo. Al mismo tiempo, también queremos asegúrese de que las consultas regresen en milisegundos, incluso en terabytes de datos.
Por supuesto, esto es posible hoy con Elasticsearch. El elástico se utiliza a muy alta escala. El desafío es que administrar datos a esa escala se vuelve muy, muy difícil. Entonces, un mejor escalado significa habilitar este tipo de escalado en la nube y hacerlo muy fácil.
Flexibilidad de indexación
Por flexibilidad. Escuchamos comentarios fuertes y claros de que desea poder realizar consultas mucho más complejas. Desea poder realizar, por ejemplo, consultas SQL estándar, incluidos JOIN, sobre sus datos, independientemente de dónde provengan. Podría ser JSON anidado procedente de MongoDB. Podría ser Avro viniendo de Kafka. Podría ser parquet procedente de S3, o datos estructurados provenientes de otros lugares. ¿Cómo puede ejecutar muchos tipos de consultas complejas sobre esto sin tener que desnormalizar sus datos? Ese es uno de los objetivos del diseño.
operaciones bajas
Cuando crea un sistema nativo de la nube, puede habilitar el escalado de la nube sin servidor y los vectores para los que estamos optimizando son tanto la eficiencia del {hardware} como la eficiencia humana en la nube.
La memoria es muy cara en la nube. Administrar clústeres y escalar hacia arriba y hacia abajo es doloroso cuando tiene muchas cargas de trabajo en ráfagas. ¿Cómo podemos manejar todo eso de manera más easy en la nube?
diferencias
Profundicemos en lo que realmente es la diferencia entre las dos tecnologías de indexación.
Elasticsearch tiene un índice invertido y también tiene un almacenamiento de valores de documentos creado con Apache Lucene. Lucene ha existido por un tiempo. Es de código abierto y muchos están íntimamente familiarizados con él. Originalmente se creó para la búsqueda de texto y el análisis de registros y esto es algo en lo que realmente brilla. También significa que tiene que desnormalizar sus datos a medida que ingresa sus datos y obtiene consultas de búsqueda y agregación muy rápidas.
Puede pensar en la indexación convergente como la próxima generación de indexación. La indexación convergente combina el índice de búsqueda (el índice invertido) con un índice basado en filas y un almacén de columnas. Todo esto se basa en una abstracción de clave-valor, no en Lucene. Esto está construido sobre RocksDB.
Debido a la flexibilidad y la escala que le brinda, se presta muy bien para el análisis en tiempo actual y las aplicaciones en tiempo actual. No necesita desnormalizar sus datos. Puede ejecutar búsquedas, agregaciones, consultas basadas en el tiempo realmente rápidas (porque ahora ha creado un índice de tiempo), consultas geográficas (porque tiene un índice geográfico) y sus JOIN también son posibles y muy rápido.
Índice convergente bajo el capó
Hablamos de tener su índice columnar, invertido y de fila en el mismo sistema. Piense en ello como si su documento ingerido se triturara y asignara a muchas claves y valores, y se almacenara en términos de muchas claves y valores.
RocasDB es un almacén de clave-valor incrustado. De hecho, nuestro equipo que lo construyó. Si no está familiarizado con RocksDB, le daré una descripción common de un segundo. Así que nuestro equipo construyó RocksDB en Fb y lo abrió. Hoy encontrará RocksDBs usados en Apache Kafka, se usa en Flink, se usa en CockroachDB. Todos los sistemas distribuidos a escala de la nube modernos utilizan RocksDB.
Rockset usa RocksDB bajo el capó, y es una representación muy diferente a la que se hace en Elasticsearch. Una de las grandes diferencias aquí es que debido a que tiene estos tres tipos diferentes de índices, ahora podemos tener un optimizador de SQL que resolve en tiempo actual cuál es el mejor índice para usar, y luego devuelve sus consultas muy rápido eligiendo el índice correcto. y optimizar su consulta en tiempo actual.
Debido a que se trata de un almacén de valores clave, la otra ventaja que tiene es que todos y cada uno de los campos son mutables. ¿Qué te da esta mutabilidad a medida que escalas? No tiene que preocuparse por volver a indexar si está usando (por ejemplo) flujos de cambio de base de datos, no tiene que preocuparse por lo que sucede cuando tiene muchas actualizaciones, eliminaciones, inserciones, and so on. en su captura de datos de cambio de base de datos. No tiene que preocuparse por cómo se maneja eso en su índice. Cada campo particular person que es mutable es muy poderoso a medida que comienza a escalar su sistema, ya que tiene índices de escala masivos.
Whatnot cambió de Elasticsearch a Rockset para la personalización en tiempo actual debido a los desafíos de administrar actualizaciones, inserciones y eliminaciones en Elasticsearch. Para cada actualización, tenían que probar manualmente cada componente de su flujo de datos para asegurarse de que no hubiera cuellos de botella ni errores de datos.
Conozca las diferencias adicionales entre Elasticsearch y Rockset en este documento técnico de comparación.
