Optimizar el rendimiento de las colecciones analíticas externas en Couchbase

Es crucial planificar la optimización del rendimiento y la utilización de recursos ahora que hay soporte para colecciones externas de Couchbase Analytics (AWS S3 y Almacenamiento Azure Blob). Las colecciones externas de Couchbase Analytics leen los datos del almacenamiento externo y no los almacenan localmente, lo que puede ser una operación costosa si no se optimiza.

En este artículo se analizan los factores que afectan significativamente al rendimiento y a la utilización de los recursos cuando se consultan datos de un almacenamiento externo. También veremos un ejemplo detallado para comprobar la eficacia de nuestras optimizaciones.

Tendremos en cuenta los siguientes elementos y discutiremos su impacto en el rendimiento y la utilización de los recursos:

• Ancho de banda de Internet y distancia del almacenamiento externo
• Número de nodos y particiones de Couchbase Analytics y número de archivos en almacenamiento externo
• Prefijos y filtros de inclusión/exclusión

Ancho de banda y distancia de Internet

Dado que los datos externos no se almacenan en el almacenamiento nativo de Couchbase Analytics, cada petición de consulta transfiere la versión actual de los datos a través de la red. Esto hace que el ancho de banda de la red sea un factor significativo en el rendimiento de dichas consultas. La latencia de la red es otro factor-la distancia que los datos tienen que viajar impactará en la latencia. Por lo tanto, se recomienda tener el almacenamiento de destino alojado en una región cercana.

Nota: Algunos proveedores de servicios de almacenamiento no cobran ningún coste de transmisión si la aplicación y el almacenamiento host se encuentran en la misma región, lo que mejora el rendimiento y reduce los costes.

Particiones frente a número de archivos

Cuando se consulta una colección externa de Couchbase Analytics, la carga de trabajo de escaneo de datos se distribuirá uniformemente entre los nodos y particiones de Analytics disponibles para leer los datos en paralelo. (Esto es similar a cómo el almacenamiento interno es leer en paralelo). Para que esta capacidad de lectura paralela se aproveche al máximo, los datos del almacenamiento externo deben almacenarse en varios archivos en lugar de en uno o varios archivos de gran tamaño.

Por ejemplo, supongamos que tenemos tres nodos Analytics con cuatro particiones por nodo. Esta configuración da como resultado un grado paralelo de 12 (12 particiones en total). Cuando se consulta una colección externa de Analytics, debería poder leer 12 archivos en paralelo desde el almacenamiento externo.

Si tenemos los datos organizados en varios archivos, la configuración anterior leerá 12 archivos a la vez, pero si sólo tenemos unos pocos archivos (por ejemplo, cinco archivos grandes), entonces sólo cinco particiones tendrán trabajo que hacer, dejando el resto de los recursos disponibles de Analytics ociosos.

El objetivo de Analytics es distribuir la carga de trabajo de escaneado uniformemente entre el número total de particiones, no entre nodos. En el ejemplo anterior, cada una de las 12 particiones tendrá 1/12 de la carga de trabajo total, y cada nodo tendrá 1/3 de la carga. Si los nodos tuvieran diferentes números de particiones por alguna razón, la carga de trabajo por partición permanecería uniforme, pero los nodos en sí mismos estarían cargados de forma no uniforme. Es por eso que se recomienda tener los datos distribuidos en múltiples archivos para que la carga de trabajo pueda ser distribuida. 

Sin embargo, es igual de crucial evitar tener demasiados archivos pequeños como cientos de miles o millones de archivos, ya que esto podría resultar en un rendimiento pobre debido al manejo de metadatos de archivos y demasiadas operaciones de apertura/cierre de archivos.

Prefijos y filtros de inclusión/exclusión

Organización de datos

Empecemos por ver la estructura de los datos con los que trabajaremos aquí a modo de ilustración. Trabajaremos con tres años de reseñas datos. Organizaremos nuestros datos por año, por trimestre y por mes. Los datos corresponden a los años 2018, 2019 y 2020.

A continuación se muestran ejemplos de la disposición del directorio y de un documento típico:

Muestra de documento:

La estructura anterior nos permitirá tener una granularidad por meses sobre los datos, que utilizaremos en ejemplos posteriores.

Supongamos que el tamaño total de nuestros datos para los tres años es de 720 GB. Esto nos da unos 240 GB de datos al año (tres años) y 20 GB al mes (36 meses en tres años).

¿Cómo funcionan las Colecciones Exteriores?

Dado que la organización de los datos puede afectar significativamente al rendimiento, vamos a revisar cómo Couchbase Analytics lee los datos del almacenamiento externo.

Los datos de las colecciones de análisis externos se almacenan en un almacenamiento externo remoto, como AWS S3, Azure Blob/Data Lake o Google Cloud Storage. Azure Blob Storage y Google Cloud Storage son actualmente en vista previa para desarrolladores. 

Cuando se crean un enlace externo y una colección externa de Analytics, son definiciones de entidades configuradas para leer los datos de la fuente externa, pero los datos no son almacenado en Analytics. Esto permite a Analytics ver siempre las últimas versiones de los datos externos, pero también puede resultar lento. Podemos optimizar el proceso de lectura utilizando prefijos y otros filtros para ahorrar tiempo y recursos.

En el siguiente ejemplo veremos la gran diferencia que puede suponer un filtro si se utiliza con criterio junto con datos bien organizados.

Requisitos

Echemos un vistazo a las siguientes peticiones de consulta sencillas para ver la diferencia de rendimiento con y sin filtrado:

• Obtén el número total de opiniones de clientes para 2018, 2019 y 2020.
• Obtén el número total de opiniones de clientes para el año 2019.
• Obtén el número total de opiniones de clientes para enero de 2020.

Solución no filtrada

Supongamos que ya existe un enlace externo llamado myLink (véase Conjuntos de datos externos: Acceso a AWS S3 en Couchbase Analytics para ver un ejemplo de cómo se crea un enlace). Comenzamos creando una colección externa de Analytics para todos los datos de revisión sin prefijo y sin filtros de inclusión/exclusión. La sintaxis es sencilla:

Con esta colección externa de Analytics creada, vamos a escribir las consultas, que son sencillas y directas, como sigue:

Dado nuestro ancho de banda de Internet y la distancia al proveedor de servicios, podríamos obtener (y de hecho obtuvimos) lo siguiente:

• Estas consultas llevaron 435, 448 y 430 segundos para terminar, lo que demuestra que casi rindieron lo mismo.
• Cada consulta dio como resultado 720 GB de transferencia de datos.

Lo que ocurre es que en cada una de estas consultas se leen todos los registros de datos (es decir, se transfieren todos los datos) y, a continuación, se aplica el filtrado necesario para obtener el resultado correcto. Sin embargo, los datos ya se han transferido en el momento en que se filtran. Este es el principal factor determinante del rendimiento en el ejemplo anterior.

En ausencia de optimizaciones adicionales, todas las consultas contra nuestras revisiones leerán todo el conjunto de datos una y otra vez, lo que puede resultar muy caro. Aunque esto puede ser aceptable para datos externos a los que se accede con poca frecuencia, podemos hacerlo (mucho) mejor si lo deseamos.

Solución filtrada

Ahora, vamos a examinar cómo podemos utilizar el prefijo y incluir/excluir filtros disponibles para las colecciones externas de Analytics y cómo estructuramos nuestros datos para mejorar el rendimiento de nuestras consultas.

La primera consulta requiere leer todos los datos, así que dejémosla como está. Veamos en cambio las consultas 2 y 3.

En la consulta 2, los datos necesarios corresponden únicamente al año 2019, por lo que podemos crear una nueva colección externa de Analytics y utilizar el año como prefijo al hacerlo:

El DDL da como resultado una colección externa de Analytics configurada para leer únicamente los datos del prefijo especificado, es decir, "revisiones/2019". Es importante señalar que esta colección es virtuales sólo otro punto de entrada con nombre a los mismos datos almacenados externamente. (No se está replicando ningún dato, y no se está utilizando espacio adicional debido a la creación de esta colección externa adicional - son sólo metadatos).

Para entender lo que ocurre, veamos lo que sucede internamente. Cuando se consulta una colección externa de Analytics, el motor de consulta empieza por recuperar los metadatos de los archivos, que sólo contienen información acerca de los archivos. El contenido de los archivos no se lee todavía. Parte de la información de metadatos devuelta es el nombre completo/ruta de los archivos y los tamaños de su contenido.

Analytics utiliza esta información para realizar dos pasos:

• Aplica cualquier prefijo, filtrado de inclusión/exclusión en el nombre del archivo, para decidir si incluye cada archivo o lo excluye por completo, con el consiguiente ahorro de recursos.
• Calcula el tamaño global de los datos, lo que lleva a distribuir la carga de trabajo uniformemente entre todas las particiones de los nodos Analytics para su acceso y procesamiento en paralelo.

Aplicando lo anterior, las consultas sobre el Mi colección 2019 sólo leerá los archivos cuyo prefijo sea "revisiones/2019", que sólo incluirá 33% de los datos. La consulta pertinente puede escribirse ahora como:

Ejecutando la consulta anterior, observamos lo siguiente:

• El tiempo total de ejecución es ahora de 160 segundos, frente a los 448 segundos anteriores, es decir, sólo 35% del tiempo original. Era de esperar, ya que sólo hemos leído 33% de los datos.
• La cantidad total de datos transferidos es de 240 GB, por debajo de los 720 GB anteriores.

Esto supone una mejora considerable tanto en rendimiento como en utilización de recursos.

Siguiendo el mismo patrón, utilicemos la capacidad de filtrado de inclusión/exclusión de las colecciones externas. La consulta 3 sólo está interesada en los datos de enero de 2020.

Vamos a crear una colección Analytics externa adecuada de la siguiente manera:

Cuando se lean datos de la colección anterior, sólo se incluirán los archivos cuyo prefijo sea "reseñas/2020"para incluir sólo los datos de 2020 y, a continuación (¡también antes de leer los datos!), Analytics aplicará el filtro de inclusión. Como resultado, la consulta sólo recuperará los archivos que coincidan con el patrón "*/Jan/*.json"y, por tanto, sólo incluirá archivos JSON para enero. Una vez determinados los archivos de destino de la consulta, el motor de consulta distribuirá la carga de trabajo entre las particiones y comenzará a leer los datos.

Ejecutando nuestra 3ª consulta, escrita contra esta nueva colección:

Observamos lo siguiente:

• El tiempo total de ejecución es ahora de sólo 12 segundos, ya que estamos leyendo efectivamente sólo 2,78% de los datos.
• La cantidad total de datos transferidos es ahora de sólo 20 GB.

Tenga en cuenta que los filtros include/exclude también admiten expresiones comodín y que, por ejemplo, se pueden especificar varios filtros a la vez:

De este modo, sólo se incluirán los datos de enero y marzo.

Próximos pasos

Dado que acceder a datos externos puede ser costoso, se recomienda aplicar las mejores prácticas de organización de datos y las correspondientes definiciones de colecciones externas. Esto contribuirá en gran medida a obtener el mejor rendimiento posible al permitir a Couchbase Analytics utilizar los recursos disponibles en paralelo tanto como sea posible y mantener al mínimo los costes implicados en la ejecución de consultas.

Sigue los siguientes enlaces utilizados en este artículo para aprender más sobre Couchbase Analytics:

• Descubra cómo utilizan los clientes Couchbase Analytics en este artículo.
• Uso de las colecciones de análisis con AWS S3 y Almacenamiento Azure Blob.
• Uso de varios discos para acelerar las consultas de Couchbase Analytics
• Análisis JSON - NoETL con NoSQL y Couchbase
• Utilizando SQL++ for Analytics (SQL para JSON)