Conocer la API que selecciona

Puede utilizar Java™, Python, Goo Node.js o algún otro lenguaje o plataforma específico de caso de uso. Lo más probable es que uno de estos lenguajes venga con bibliotecas de lado de cliente útiles que integren perfectamente el acceso de IBM Cloudant, siguiendo las convenciones que espera para sus herramientas. Estos lenguajes son ideales para aumentar la eficiencia del programador, pero también ocultan la visualización de la API.

Esta abstracción es lo que se desea; el principal motivo para utilizar una biblioteca de clientes es ahorrarse repetidas y tediosas operaciones de copiar y pegar. Sin embargo, debe comprender que la API subyacente es vital cuando se resuelven problemas y se informan de ellos. Cuando se informa de un problema sospechoso a IBM Cloudant, será muy útil para ayudarle si nos puede indicar cómo reproducir el problema.

Esta solicitud no significa cortar y pegar una parte considerable del código Java™ literal de la aplicación en una incidencia de soporte, ya que probablemente no podremos compilarlo. Además, el código del lado del cliente introduce dudas en cuanto a dónde puede estar el problema, si en su lado o en el nuestro.

En su lugar, los equipos de soporte de IBM Cloudantsuelen solicitar el conjunto de llamadas de API, idealmente como un conjunto de mandatos curl que pueden ejecutar, lo que demuestra el problema. La adopción de este enfoque para la resolución de problemas como regla también facilita la identificación de dónde se están produciendo los problemas. Si el código se está comportando de forma inesperada, intente reproducir el problema utilizando solo el acceso directo a la API.

Si no puede, el problema no se encuentra en el propio servicio de IBM Cloudant.

Si está investigando un problema de rendimiento, consulte los registros que proporciona IBM Cloud®. Si los registros muestran que IBM Cloudant maneja rápidamente las solicitudes, pero la aplicación es lenta, la causa raíz de este problema reside en el código de aplicación del lado del cliente. Consulte la regla sobre registro y supervisión.

Si sospecha que el problema reside en una biblioteca de cliente soportada oficialmente, intente construir un ejemplo de código pequeño y autónomo que demuestre el problema. En este ejemplo de código autónomo, utilice el menor número posible de dependencias. Si está utilizando Java™, nos resulta útil si puede utilizar un arnés de prueba mínimo para resaltar los problemas de biblioteca.

Ocasionalmente, IBM Cloudant recibe incidencias de soporte que indican que "IBM Cloudant se ha interrumpido porque mi aplicación es lenta" sin más datos de pruebas de soporte. Casi siempre este caso se puede rastrear hasta encontrar problemas en el código de aplicación del lado del cliente, o conceptos erróneos acerca de cómo funciona IBM Cloudant.

No siempre, pero la mayoría de las veces.

Si conoce mejor la API, también ganará experiencia sobre cómo se comporta IBM Cloudant, especialmente en términos de rendimiento. Si utiliza una biblioteca de cliente, debe intentar saber al menos cómo averiguar qué solicitudes HTTP se generan mediante una llamada de función específica. Para obtener más información, consulte los siguientes sitios web:

• IBM Cloudant Documentos de API
• Registro de integración
• Publicación de blog sobre registro

Los documentos deben agrupar datos que en su mayoría cambian juntos

Cuando empiece a modelar los datos, tarde o temprano, se encontrará con el problema de cómo se pueden estructurar los documentos. Ahora sabe que IBM Cloudant no aplica ninguna normalización y que no tiene transacciones del tipo al que está acostumbrado, por ejemplo, Postgres. La tentación puede ser introducir el máximo posible de datos en cada documento, lo que también supondrá un ahorro en el uso de HTTP.

Esta práctica es a menudo una mala idea.

Si el modelo agrupa información que no cambia a la vez, es más probable que aparezcan conflictos de actualización.

Supongamos una situación en la que tenga varios usuarios, cada uno con un conjunto de pedidos asociados. Una forma puede ser representar los pedidos como una matriz en el documento de usuario:

{ // DON'T DO THIS
    "customer_id": 65522389,
    "orders": [ {
      "order_id": 887865,
      "items": [ {
          "item_id": 9982,
          "item_name": "Iron sprocket",
          "cost": 53.0
        }, {
          "item_id": 2932,
          "item_name": "Rubber wedge",
          "cost": 3.0
        }
      ]
    }
  ]
}

Para añadir un pedido, necesito captar el documento completo, desorganizar el JSON, añadir el elemento, organizar el nuevo JSON y enviarlo de nuevo como una actualización. Si soy el único que lo hace, podría funcionar un tiempo. Si el documento se actualiza simultáneamente o se está replicando, es probable que aparezcan conflictos de actualización.

En su lugar, mantenga los pedidos separados como su propio tipo de documento, haciendo referencia al ID de cliente. Ahora el modelo es inmutable. Para añadir un pedido, creo un nuevo documento de pedido en la base de datos, que no puede generar conflictos.

Para poder recuperar todos los pedidos de un determinado cliente, podemos emplear una vista, que describiremos más adelante.

Evite construcciones que se basen en actualizaciones de partes de documentos existentes, siempre que sea posible. Los modelos de datos incorrectos suelen ser difíciles de cambiar después de estar en producción.

El patrón anterior se puede resolver eficientemente utilizando bases de datos particionadas, que se describen en mayor detalle más adelante.

Para obtener más información, consulte la siguiente documentación:

• Guía de IBM Cloudant para el modelado de datos
• Particiones de base de datos

Mantener un tamaño pequeño de los documentos

IBM Cloudant impone un tamaño máximo de documento de 1 MB. Este límite no significa que un tamaño de documento de cerca de 1 MB sea una buena idea. Por el contrario, si está creando documentos que tienen más de un dígito de KB, probablemente necesite revisar su modelo. El rendimiento de varios elementos en IBM Cloudant disminuye a medida que crecen los documentos. Por ejemplo, la decodificación de JSON es costosa.

Veamos las siguientes secciones: Los documentos deben agrupar datos que en su mayoría cambian juntos y Mantener un tamaño pequeño de los documentos. Vale la pena recalcar que los modelos que dependen de las actualizaciones tienen un límite de volumen máximo de 1 MB, que es el límite del tamaño del documento. Este tamaño no es lo deseable.

Evitar utilizar archivos adjuntos

IBM Cloudant tiene soporte para almacenar archivos adjuntos con los documentos, una característica histórica que hereda de CouchDB. Si utiliza IBM Cloudant como programa de fondo para una aplicación web, también puede almacenar iconos pequeños y otros activos estáticos como, por ejemplo, archivos CSS y JavaScript con los datos.

Hoy día, debe tener en cuenta varios aspectos antes de utilizar archivos adjuntos en IBM Cloudant, especialmente si se trata activos más grandes como imágenes y vídeos:

1. IBM Cloudant resulta caro como almacén de bloques.
2. La implementación interna de IBM Cloudant no es eficiente en el manejo de grandes cantidades de datos binarios.

Por lo tanto, es lento y caro.

IBM Cloudant es aceptable para activos pequeños y un uso ocasional. Por regla general, si necesita almacenar datos binarios junto a documentos de IBM Cloudant, es mejor utilizar una solución aparte más adecuada para este propósito. Sólo necesita almacenar los metadatos adjuntos en el documento IBM Cloudant . Sí, eso significa que necesita escribir código adicional para subir el archivo adjunto a un almacén de bloques adecuado de su elección. Verifique que la operación haya sido satisfactoria antes de almacenar la señal o el URL en el archivo adjunto en el documento de IBM Cloudant.

Sus bases de datos son más pequeñas, más baratas, más rápidas y más fáciles de replicar. Para obtener más información, consulte los siguientes sitios web:

• Documentos de IBM Cloudant en los archivos adjuntos
• Desconectando IBM Cloudant adjuntos a Object Storage

Cuantas menos bases de datos, mejor

Si puede, limite el número de bases de datos por cuenta IBM Cloudant a 500 o menos. Aunque este número concreto no es mágico (IBM Cloudant puede manejar más de forma segura), hay varios casos de uso que se ven afectados negativamente por un gran número de bases de datos en una cuenta.

El planificador de replicadores tiene un número limitado de trabajos de réplica simultáneos que está preparado para ejecutar. A medida que crece el número de bases de datos, es probable que la latencia de réplica aumente si intenta replicar todo el contenido de una cuenta.

La otra cara de la misma moneda es el aspecto operativo: el equipo de operaciones de IBM Cloudant depende también de la réplica para moverse en las cuentas. Si reduce en lo posible el número de bases de datos, nos ayudará a ayudarle si necesita cambiar su cuenta de una ubicación a otra.

Por lo tanto, ¿cuándo debe utilizar una única base de datos y distinguir entre distintos tipos de documentos utilizando vistas y cuándo debe utilizar varias bases de datos para modelar los datos? IBM Cloudant no puede federar vistas en varias bases de datos. Si tiene datos no relacionados que nunca se pueden "unir" o consultar juntos, estos datos pueden ser candidatos para dividirse en varias bases de datos.

Si tiene un conjunto de datos cada vez mayor (por ejemplo, un registro, lecturas de sensores u otros tipos de series temporales), no es una buena idea crear una única base de datos masiva en constante crecimiento. Este tipo de caso de uso requiere una limitación de tiempo, que describiremos en mayor detalle más adelante.

Evitar la base de datos por usuario anti-patrón como la peste

Si está creando un servicio de varios usuarios en la parte superior de IBM Cloudant, es tentador permitir que cada usuario almacene sus datos en una base de datos independiente bajo la cuenta de la aplicación. Eso funciona bien, sobre todo, si el número de usuarios es pequeño.

Posteriormente, añada la necesidad de derivar la analítica entre usuarios. La forma de hacerlo es replicar todas las bases de datos de usuario en una única base de datos de análisis. Todo bien. Esta aplicación se ha convertido de repente en un éxito y el número de usuarios crece en un rango de 150 - 20.000. Tiene 20.000 réplicas solo para mantener la base de datos de análisis actualizada. Si también desea ejecutar una configuración de recuperación tras desastre activa-activa, añade otras 20.000 réplicas y el sistema deja de funcionar.

En su lugar, multiplexe los datos de usuarios en menos bases de datos, o fragmente los usuarios en un conjunto de bases de datos o cuentas, o ambas cosas. De este modo, no es necesario que crear réplicas para proporcionar una base de datos de análisis, pero la autenticación se vuelve más complicada ya que IBM Cloudant solo proporciona autenticación a nivel de base de datos.

Vale la pena aclarar que el enfoque de "base de datos por usuario" es tentador porque los permisos de IBM Cloudant son "por base de datos", pero realmente no es culpa de los usuarios que haya emergido este patrón.

Evitar escribir funciones personalizadas de reducción de JavaScript

Las vistas de MapReduce en IBM Cloudant son impresionantes. Sin embargo, un gran poder conlleva una gran responsabilidad. La parte del mapa de una vista de MapReduce se crea de forma incremental, por lo que un código de mala calidad en el mapa solo afecta al tiempo de indexación, no al tiempo de consulta. La parte de reducción, por desgracia, se ejecuta en el momento de la consulta. IBM Cloudant proporciona un conjunto de funciones de reducción incorporadas que se implementan internamente en Erlang. Estas funciones tienen un rendimiento a escala, mientras que las reducciones de JavaScript hechas a mano no lo tienen.

Si se encuentra escribiendo funciones de reducción, deténgase y considere si puede reorganizar los datos para que no sea necesario escribir funciones de reducción. O si es posible utilizar los reductores incorporados.

Las vistas en bases de datos particionadas no dan soporte a reducciones personalizadas, que es un factor que contribuye a las consultas de aceleración significativas que sólo pueden ofrecer dichas vistas.

Para obtener más información, consulte la documentación de IBM Cloudant sobre reduce.

Utilizar bases de datos con limitación de tiempo para conjuntos de datos cada vez mayores

En general no se recomienda tener una base de datos en constante crecimiento en IBM Cloudant. Es difícil hacer copias de seguridad de las bases de datos grandes, requieren una "refragmentación" para mantener un buen rendimiento a medida que crecen, y experimentan tiempos de generación de índices largos.

Una forma de mitigar este problema es tener varias bases de datos más pequeñas, con un patrón común que es bases de datos con limitación de tiempo: un conjunto de datos grande se divide en bases de datos más pequeñas, donde cada una representa una ventana de tiempo, por ejemplo, un mes.

• orders_2019_01
• orders_2019_02
• orders_2019_02

Los nuevos datos se escriben en la base de datos de este mes y las consultas de datos históricos se pueden direccionar a las bases de datos de meses anteriores. Cuando los datos de un mes ya no son de interés, se pueden archivar en Object Storage, la base de datos de IBM Cloudant mensual se suprime y se recupera el espacio de disco. Para obtener más información, consulte el siguiente sitio web.

• Blog de Time-series Data Storage