Como todos sabemos, el código es caro de mantener: cuanto más complejo es el código, mayor es el coste de su mantenimiento. Por eso, desde el principio de los tiempos, los desarrolladores de software han trabajado muy duro para lograr el objetivo de reutilización del código.
Couchbase Mobile 3.0 introdujo soporte para consultas SQL++. Como desarrollador, lo primero que se me ocurrió fue compartir las consultas utilizadas en proyectos dirigidos tanto a aplicaciones de Couchbase Server como de Couchbase Mobile.
¿Es una buena idea? Exploremos esa cuestión utilizando datos de muestra y una aplicación móvil de prueba de concepto.
Datos de la muestra
Todo el código de este artículo está disponible en GitHub. Ver el LÉAME para obtener información sobre cómo configurar los proyectos en su ordenador.
Los datos de la muestra proceden del OpenStreetMap y tiene licencia bajo la Open Data Commons Licencia de base de datos abierta (ODbL) por la Fundación OpenStreetMap.
El conjunto de datos contiene todas las tiendas que venden helados en Estados Unidos. A continuación se muestra un documento JSON de ejemplo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
{ "tipo": "Característica", "id": "nodo/472242349", "propiedades": { "addrCity": "Austin", "addrHousenumber": "4477", "addrPostcode": "78745", "addrState": "TX", "addrStreet": "Bulevar South Lamar", "addrUnit": "#790", "amenidad": "helado", "cocina": "helado", "nombre": "Helados de Amy", "teléfono": "+1-512-891-0573", "id": "nodo/472242349" }, "geometría": { "tipo": "Punto", "coordenadas": [ -97.7998856, 30.230688 ] } } |
Como puede ver, se trata de un conjunto de datos versátil para realizar pruebas porque tiene propiedades incrustadas en los documentos.
Ejemplo de aplicación móvil
En ejemplo de aplicación móvil se escribió en SwiftUI con Combine y es una aplicación para iOS/macOS que muestra las distintas tiendas que venden helados en Estados Unidos. La aplicación incluye un base de datos preconstruida con los mismos documentos JSON ya importados en ella para mayor comodidad. Esta aplicación móvil utiliza la última versión del SDK de Couchbase Lite. Puedes abrir el proyecto en XCode desde el archivo del proyecto en la carpeta src para seguir el proceso.
Una simple comparación de consultas
Para empezar nuestras pruebas, podemos escribir una consulta sencilla, para Couchbase Server, que muestre todas las direcciones de las heladerías y las ordene por el nombre de la tienda:
|
1 2 3 4 5 6 |
SELECCIONE id, propiedades.direcciónCiudad, propiedades.addrHousenumber, propiedades.addrPostcode, propiedades.direcciónCalle, propiedades.addrState, propiedades.nombre DESDE helado DONDE propiedades.direcciónCiudad <> "" Y tipo = "Característica" PEDIR POR propiedades.nombre |
Esta consulta tiene un filtro que sólo devuelve los documentos en los que el objeto de la propiedad direcciónCiudad tiene un valor y donde el documento tipo es igual a Característica. Si se pregunta por qué tenemos la direcciónCiudad filtro, se debe a que en este conjunto de datos hay datos sucios o documentos sin nombre o falta información. Utilizando un tipo es común en las aplicaciones móviles para filtrar diferentes tipos de documentos.
Podemos utilizar el Editor de consultas del servidor Couchbase Consola web para ejecutar esta consulta. Cuando lo ejecuté en mi Macbook Pro M1 Max personal, el resultado llegó en 38,4 ms. Esta consulta utiliza el adv_properties_addrCity_type que puede ver haciendo clic en el icono Asesor de índices botón.
Portar la consulta a Couchbase Lite
Veamos ahora esta misma consulta ejecutándose en nuestra aplicación móvil. Para ver la aplicación móvil, puedes usar XCode para abrir el archivo IceCreamLocator.xcodeproj situado en la carpeta src carpeta. Una vez abierta en Xcode, busque la carpeta IceCreamLocationRepository swift en la carpeta Shared\Data carpeta.
En init activa el registro detallado de la base de datos para inspeccionar la información de la consulta. Usando el registro detallado, puedes revisar lo que está pasando dentro de Couchbase Lite, incluyendo el rendimiento de la consulta.
Revisemos la consulta simple de Couchbase Server y veamos cómo funciona en Swift con el nuevo SQL++ Query API. La función para la consulta simple se llama getListByTypeNombreOrdenCiudady el código se muestra a continuación:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
func getListByTypeNombreOrdenCiudad() -> Vacío { do { si deje consulta = pruebe _db?.createQuery("SELECT id, properties.addrCity, properties.addrHousenumber, properties.addrPostcode, properties.addrStreet, properties.addrState, properties.name FROM _ WHERE properties.addrCity \"\" AND type = \"Feature\" ORDER BY properties.name") { var resultados: [IceCreamLocation] = [] deje explique = pruebe consulta.explique() imprimir ("**EXPLAIN** \(explique)") para resultado en pruebe consulta.ejecutar() { si deje datos = resultado.toJSON().datos(utilizando: .utf8){ deje ubicación = pruebe JSONDecoder().descodificar(IceCreamLocation.auto, de: datos) resultados.añadir(ubicación) } } auto.iceCreamLocationList.enviar(resultados) auto.iceCreamLocationList.enviar(finalización: .terminado) } } captura { imprimir("**Error**: \(error)") auto.iceCreamLocationList.enviar(finalización: .fallo(DbError.desconocido)) } } |
Hay varias formas de hacer una consulta SQL++ en Swift. En este ejemplo, usamos la base de datos createQuery para crear la consulta. En Couchbase Lite, estoy usando el carácter de subrayado (_) como nombre de la base de datos antes de la función DESDE sentencia. Cambiar el nombre de la base de datos es uno de los cambios esperados para reutilizar las sentencias SQL++. Además, para escapar de las comillas en la sentencia DONDE tuve que añadir el carácter de escape de cadena Swift (\) antes de cada comilla.
Para probar esta consulta en ejecución, puede abrir el archivo IceCreamListViewModel que se encuentra en el archivo VerModelos carpeta. Localice la carpeta init y descomente la primera línea de ejemplo situada en la parte inferior de la función que llama a la función getListByTypeNombreOrdenCiudad de la función _repositorio variable:
|
1 2 |
//primer ejemplo _repositorio.getListByTypeNombreOrdenCiudad() |
Ahora puedes utilizar Xcode para ejecutar la aplicación en un simulador de iOS o en una aplicación de macOS. A continuación, abra la aplicación Consola de depuración en Xcode haciendo clic en el botón Mostrar depuración en la esquina inferior derecha del editor de Xcode, como se muestra a continuación.
El registro detallado mostrará una gran cantidad de información de registro. Para ayudarle a encontrar la información correcta en los registros, utilice el cuadro de filtro situado debajo de la consola. Por ejemplo, introduzca el texto "Información de consulta" y luego pulsa la tecla intro de tu teclado para ver información sobre la consulta. La consola de depuración filtrará los datos que devuelve Couchbase Lite.
La inspección de los registros le mostrará el Información de consulta y el número de documentos encontrados por la consulta, cuántos bytes y cuánto tiempo tardó la consulta. Recuerda que los números que estás viendo proceden de un simulador, no de un dispositivo real. Para ajustar el rendimiento de las aplicaciones móviles, debes utilizar las herramientas de Apple con un dispositivo real.
La velocidad a la que se ejecuta esta consulta es impresionante. Aún más impresionante, todavía no se ha creado ningún índice, así que esta consulta se ejecuta sin índice y hace un escaneo de tabla, lo que significa que tiene que mirar en la base de datos cada documento para ver si cumple los requisitos de la consulta. Couchbase Lite no requiere índices y hará escaneos de tabla si es necesario, mientras que Couchbase Server sí requiere índices porque los escaneos de tabla pueden matar el rendimiento de todo el cluster.
En varios casos, añadir índices puede mejorar significativamente el rendimiento de las consultas, así que dejemos de ejecutar la aplicación, añadamos el índice adecuado y volvamos a comprobar el rendimiento.
Abra el IceCreamLocationRepository y localice el createIceCreamIndexes función. Descomente el primer bloque de código para crear el primer índice de consulta:
|
1 2 |
deje simpleIndex = ValueIndexConfiguration(["propiedades.nombre", "properties.addrCity", "tipo"]) pruebe _db?.createIndex(simpleIndex, nombre: "idx_location_type_city_name") |
¿Cómo comprobamos si la consulta ha utilizado el índice que hemos creado? En la ventana getListByTypeNombreOrdenCiudad verás dos líneas que imprimen los resultados de la función explain en la consola:
|
1 2 |
deje explique = pruebe consulta.explique() imprimir ("**EXPLAIN** \(explique)") |
La consulta explique ejecutará el equivalente de la función SQLite EXPLICAR EL PLAN DE CONSULTA y almacenar los resultados en una cadena que se envía a la consola mediante la función print. Puede filtrar por TABLA DE EXPLORACIÓN en tu consola de depuración para encontrar los resultados. Cuando revises los resultados, asegúrate de eliminar el filtro anterior de la ventana de la consola. Ahora vuelve a ejecutar la aplicación y mira los registros para comprobar el cambio en el rendimiento.
Debería ver el USO DEL ÍNDICE con el nombre del índice creado, lo que indica que la consulta utiliza el índice adecuado. Ten en cuenta que aunque los índices pueden ayudar a las consultas, también pueden ralentizar la inserción y actualización de documentos. Puedes encontrar más información sobre indexación en el manual de Couchbase Lite documentación.
Otra comparación de consultas
En nuestra segunda comparación, filtramos los resultados sólo para mostrar las heladerías del Estado de Georgia, ordenadas por Ciudad y Estado:
|
1 2 3 4 5 6 7 8 |
SELECCIONE id, propiedades.direcciónCiudad, propiedades.addHousenumber, propiedades.addrPostcode, propiedades.direcciónCalle, propiedades.addrState, propiedades.nombre DESDE helado DONDE propiedades.direcciónCiudad IS NO NULL Y propiedades.addrState = GA Y tipo = "Característica" PEDIR POR propiedades.nombre |
Esta consulta devuelve 15 documentos y utiliza una consulta diferente, ya que utilizamos la función properties.addrState y propiedades.direcciónCiudad atributos en nuestro DONDE cláusula.
Tenga en cuenta que hemos cambiado la forma de comprobar el propiedades.direcciónCiudad y utilizar el atributo IS NOT NULL ahora. Esto demuestra la flexibilidad del lenguaje SQL++ y cómo los desarrolladores pueden utilizar diferentes sintaxis para obtener los mismos resultados.
Ahora, volvamos a nuestra aplicación móvil para ver las diferencias. La función para nuestra segunda consulta se llama getListByStateGeorgiay el código se muestra a continuación:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
func getListByStateGeorgia() -> Vacío { do { si deje consulta = pruebe _db?.createQuery("SELECT id, properties.addrCity, properties.addrHousenumber, properties.addrPostcode, properties.addrStreet, properties.addrState, properties.name FROM _ WHERE properties.addrCity NOT NULL AND properties.addrState = \"GA\" AND type="Feature\" ORDER BY properties.name") { var resultados: [IceCreamLocation] = [] deje explique = pruebe consulta.explique() imprimir ("**EXPLAIN** \(explique)") para resultado en pruebe consulta.ejecutar() { si deje datos = resultado.toJSON().datos(utilizando: .utf8){ deje ubicación = pruebe JSONDecoder().descodificar(IceCreamLocation.auto, de: datos) resultados.añadir(ubicación) } } auto.iceCreamLocationList.enviar(resultados) auto.iceCreamLocationList.enviar(finalización: .terminado) } } captura { imprimir("**Error**: \(error)") auto.iceCreamLocationList.enviar(finalización: .fallo(DbError.desconocido)) } } |
Para probar esta nueva consulta, puede abrir el archivo IceCreamListViewModel. Localice el init y comentar la primera línea de ejemplo situada al final de la función que llama a la función getListByTypeNombreOrdenCiudad de la función _repositorio y descomenta la línea que llama a nuestra nueva función:
|
1 2 3 4 5 |
//primer ejemplo //_repository.getListByTypeNombreDePedido() /segundo ejemplo _repositorio.getListByStateGeorgia() |
Puedes depurar la aplicación usando Xcode y comprobar el área de depuración. Muestra los mismos 15 documentos que fueron devueltos por la consulta ejecutada en Couchbase Server, pero volvemos a hacer un escaneo de tabla que no es el comportamiento que queremos-cambiamos la consulta, pero no creamos ningún índice nuevo todavía.
Para solucionarlo, podemos volver a la función IceCreamLocationRepository y localice el createIceCreamIndexes función. Descomente el segundo bloque de código para crear el segundo índice de consulta:
|
1 2 3 |
deje secondIndex = ValueIndexConfiguration(["propiedades.nombre","properties.addrCity", "tipo", "properties.addrState"]) pruebe _db?.createIndex(secondIndex, nombre: "idx_location_type_city_state_name") |
Descubrimos que podíamos reutilizar el código en estas dos consultas más sencillas, pero tuvimos que añadir los índices para evitar los escaneos de tabla.
Capturas con reutilización de consultas
Couchbase Server y Couchbase Mobile no usan el mismo almacenamiento o motor de consultas. Por lo tanto, es posible que te encuentres con consultas de Couchbase Server que necesiten ligeras modificaciones para ser optimizadas para Couchbase Mobile.
Para obtener más información sobre Couchbase Server, consulte la documentación de la página Optimizador basado en costes que utiliza el motor de consultas. El portal Couchbase Developer también tiene un buen artículo sobre cómo mejorar rendimiento de la consulta en Couchbase Server que pueden explicar por qué algunas consultas se escriben de una manera específica.
Recomiendo leer la documentación de Couchbase Mobile sobre resolución de problemas consultas ya que me ha ayudado a escribir consultas optimizadas y explica mejor la salida del plan de consultas de SQLite.
Resumen
Como se muestra en nuestros ejemplos de código con la versión 3.0 de Couchbase Mobile, es posible reutilizar código SQL++ entre Server y Mobile. Sin embargo, es posible que tengas que modificar las consultas y los índices para obtener un rendimiento óptimo. Por ello, recomiendo encarecidamente leer la excelente documentación de SQL++ para móviles - Diferencias con SQL++ para servidor y Cadenas de consulta SQL. Contiene información valiosa sobre los cambios que podría tener que hacer en sus consultas para utilizarlas en sus aplicaciones móviles.
Estos son algunos de los principales recursos a los que se hace referencia en este artículo:
- Ejemplos de código de GitHub
- Proyecto OpenStreetMap
- Couchbase Mobile - Documentos de la base de datos preconstruida
- Couchbase Lite en Swift - Documentación de inicio rápido
- Couchbase Lite - Indexación de documentos
- Couchbase Server - Optimizador basado en costes docs
- Couchbase Server - Consejos y sugerencias de ajuste
- Couchbase Mobile - Resolución de problemas de consultas