Conocer las ventajas e inconvenientes de la emisión de datos o no en una vista

Como el documento al que hace referencia una vista siempre está disponible utilizando include_docs=true, es posible hacer algo parecido al ejemplo siguiente para permitir búsquedas en indexed_field:

emit(doc.indexed_field, null);

Este ejemplo tiene las ventajas y desventajas siguientes:

• El índice es compacto. Este tamaño de índice es bueno, ya que el tamaño del índice contribuye a los costes de almacenamiento.
• El índice es robusto. Puesto que el índice no almacena el documento, puede acceder a cualquier campo sin pensar en qué almacenar en el índice.
• La desventaja es que recuperar el documento es más costoso que la alternativa de emitir datos en el propio índice. En primer lugar, la base de datos tiene que consultar la clave solicitada en el índice y, a continuación, leer el documento asociado. Además, si está leyendo el documento completo, pero solo necesita un campo, está haciendo que la base de datos lea y transmita datos que no necesita.

Este ejemplo también significa que existe una posible condición de actualización. El documento puede cambiar o suprimirse entre el índice y el documento leído (aunque es poco probable en la práctica).

La emisión de datos en el índice (la llamada "proyección" en términos de álgebra relacional) significa que puede ajustar el subconjunto exacto del documento que necesita. Es decir, no es necesario emitir todo el documento. Emita un valor que represente solo los datos que necesita en la aplicación que sea un objeto reducido con detalles mínimos, por ejemplo:

emit(doc.indexed_field, {name: doc.name, dob: doc.dob});

Si cambia de opinión sobre los campos que desea emitir, debe reconstruir el índice.

Los índices JSON de IBM Cloudant Query utilizan vistas de este modo de manera subyacente. IBM Cloudant Query puede ser una sustitución útil para algunos tipos de consultas de vista, pero no para todos. Tómese el tiempo necesario para entender cuándo utilizar uno u otro.

• Documentos de IBM Cloudant Query
• Guía de IBM Cloudant para utilizar vistas
• Implicaciones de rendimiento del uso de include_docs

Nunca se base en el comportamiento predeterminado de la no indexación de IBM Cloudant Query

Es tentador basarse en la capacidad de consulta de IBM Cloudant Query sin crear índices explícitos. Esta práctica es costosa en términos de rendimiento, ya que cada consulta es una exploración completa de la base de datos, en lugar de una búsqueda indexada. Si los datos son pequeños, esta búsqueda de exploración completa no importa, pero a medida que crece el conjunto de datos, el rendimiento se convierte en un problema para el desarrollador y para el clúster en su conjunto. Es probable que limitemos pronto este recurso. El panel de control de IBM Cloudant proporciona un método para crear índices de una manera fácil.

La creación de índices y la elaboración de consultas de IBM Cloudant Query que los aprovechen requiere algo de talento. Para identificar qué índice está utilizando una determinada consulta, envíe una solicitud POST al punto final de _explain para la base de datos, con la consulta como datos.

Para obtener más información, consulte Documentos de IBM Cloudant Query.

En IBM Cloudant Search (o en los índices de IBM Cloudant Query de tipo texto), limite el número de campos.

Los índices de IBM Cloudant Search y IBM Cloudant Query de tipo text (ambos son Apache Lucene si se analizan en detalle) ofrecen una forma de indexar cualquier número de campos en el índice. Hay algunos ejemplos en los que se abusa de este tipo de indexación deliberadamente o en su mayoría por error. Planifique la indexación para que incluya solo los campos necesarios para las consultas. Los índices ocupan espacio y pueden ser costosos de reconstruir si el número de campos indexados es grande.

También tenemos el problema de qué campos se almacenan en IBM Cloudant Search. Los campos almacenados se recuperan en la consulta sin ejecutar include_docs=true, por lo que las ventajas e inconvenientes son similares a los de la sección Conocer las ventajas e inconvenientes de la emisión de datos o no en una vista. Para obtener más información, consulte Documentos de IBM Cloudant Search.

La gestión de documentos de diseño requiere algo de talento

Cuando el conjunto de datos crezca y el número de vistas aumente, tarde o temprano deberá reflexionar sobre cómo organizar sus vistas en los documentos de diseño. Se puede utilizar un único documento de diseño para formar lo que se denomina un view group: un conjunto de vistas relacionadas por algún tipo de métrica que tiene sentido en su caso de uso. Si las vistas son estáticas, los URL de consulta de vista serán semánticamente similares para las consultas relacionadas. El rendimiento también es mayor en el tiempo de indexación porque el índice carga el documento una vez y genera múltiples índices a partir de él.

Los propios documentos de diseño se leen y escriben utilizando los mismos puntos finales de lectura/escritura que en cualquier otro documento. Con estos puntos finales, puede crear, inspeccionar, modificar y suprimir documentos de diseño desde la aplicación. Sin embargo, incluso pequeños cambios en los documentos de diseño pueden tener efectos significativos en la base de datos. Cuando actualiza un documento de diseño, todas las vistas que contiene dejan de estar disponibles hasta que se complete la indexación. Este retardo puede ser problemático en la producción. Para evitarlo, debe realizar un baile de intercambio de documentos de diseño loco (consulte couchmigrate).

En la mayoría de los casos, este proceso probablemente no es lo que preferiría tener que gestionar. Cuando está empezando, lo más cómodo será tener una política de documentos de una vista por diseño.

Además, en el caso de que no sea obvio, las vistas son código. Las vistas deben estar sujetas a los mismos procesos que utiliza en términos de gestión de versiones de código fuente para el resto del código de aplicación. Cómo conseguir este estándar puede que no sea obvio inmediatamente. Puede aumentar el número de versión para los fragmentos de código JavaScript. A continuación, puede cortar y pegar el código en el panel de control de IBM Cloudant para desplegarlo siempre que se produzca un cambio. Sí, todos recurrimos a esta práctica de vez en cuando.

Existen mejores formas de hacerlo, y tenemos una razón para utilizar algunas de las herramientas que rodean el concepto couchapp . Un couchapp es una aplicación web CouchDB autocontenida que hoy en día no ve mucho uso. Existen varias herramientas de couchapp que están ahí para hacer el despliegue de un couchapp, incluidas sus vistas, de forma crucial, más fácil.

La utilización de una herramienta de couchapp significa que puede automatizar el despliegue de las vistas según sea necesario, incluso cuando no utilice el concepto de couchapp.

• Consulte, por ejemplo, couchapp y situp.
• Guía de IBM Cloudant para la gestión de documentos de diseño.

Las consultas particionadas son más rápidas y baratas

Sí, las consultas particionadas son más rápidas y baratas. Si elige crear una base de datos particionada (en contraposición a una base de datos no particionada), IBM Cloudant utilizará una clave de partición para decidir en qué fragmento reside cada uno de los documentos. Los documentos con la misma clave de partición están en el mismo fragmento de base de datos. Las solicitudes de _all_docs,las vistas de MapReduce, las consultas _find de IBM Cloudant Query y las operaciones de IBM Cloudant Search se pueden dirigir a una sola partición, en lugar de tener que interrogar a todos los fragmentos en un patrón de "dispersión y recopilación", que es el caso con las consultas globales.

Estas consultas particionadas solo utilizan un fragmento de la base de datos. Esta práctica permite que sean más rápidas de ejecutarse que las consultas globales. A efectos de facturación, se clasifican como solicitudes de "lectura", en lugar de como solicitudes de "consulta", que son más caras, lo que aumenta la capacidad utilizable del mismo plan de IBM Cloudant.

No todos los diseños de datos se prestan a un diseño particionado, pero si los datos se pueden moldear en un patrón de <partition key>:<document key>, la aplicación puede beneficiarse en términos de rendimiento y coste.

• Documentación de las bases de datos particionadas
• Bases de datos particionadas-Blog de introducción

Tratar el índice primario como un índice de búsqueda gratuito

Un documento de IBM Cloudant predeterminado _id es una serie de 32 caracteres, que codifica 128 bits de datos aleatorios. El atributo _id se utiliza para construir el índice primario de la base de datos, que utiliza IBM Cloudant para recuperar documentos por _id o rangos de claves cuando el usuario suministra un par de startkey/endkey. Podemos aprovechar este hecho para empaquetar nuestros datos en el campo _id y utilizarlo como un índice "gratuito" que puede consultar rangos de valores.

Consulte algunos ejemplos en la lista siguiente:

• Utilice los ID de documento que se pueden ordenar por tiempo para clasificar los documentos en orden de fecha y hora aproximadas. Esta clasificación facilita la recuperación de las adiciones recientes a la base de datos. Para obtener más información, consulte Time-sortable -IDs.
• Empaquete datos que se pueden buscar en el campo _id, por ejemplo, se puede utilizar <customerid>~<date>~<orderid> para recuperar datos por customer, customer/date o customer/date/orderid.
• En una base de datos particionada, la opción sensata de clave de partición permite que una base de datos completa se reduzca a un puñado de documentos para una clave de partición conocida. Asegúrese de que el esquema de particionamiento resuelva el caso de uso más común.
• En una base de datos particionada, las dos partes de la clave tienen que contener los datos proporcionados por el usuario (no existen _ids generados automáticamente), por lo que es mejor utilizarlo de forma óptima. Por ejemplo, en una aplicación de IoT, <sensorid>:<time-sortable-id> permite ordenar los datos por sensor y tiempo sin un índice secundario. Implemente este esquema con bases de datos con limitación de tiempo para obtener los mejores resultados.