Evitar conflictos

IBM Cloudant está diseñado para tratar los conflictos como un estado natural de los datos en un sistema distribuido. Esta es una característica potente que ayuda a un clúster de IBM Cloudant a mantener siempre la alta disponibilidad. Sin embargo, se supone que los conflictos siguen siendo razonablemente excepcionales. El seguimiento de conflictos en el núcleo de IBM Cloudant tiene un coste significativo asociado.

Es perfectamente posible (¡pero una mala idea!) ignorar los conflictos. La base de datos continúa funcionando alegremente con la elección de una revisión aleatoria pero determinista de documentos en conflicto. Sin embargo, a medida que crece el número de conflictos no resueltos, el rendimiento de la base de datos entra en un agujero negro, especialmente cuando se realizan réplicas.

Como desarrollador, es su responsabilidad comprobar y resolver conflictos o, incluso mejor, utilizar modelos de datos que hagan que los conflictos sean imposibles.

Si crea conflictos de forma rutinaria, debe tener en cuenta los cambios del modelo: aunque resuelva los conflictos diligentemente, permanecerán las ramas de los conflictos en el árbol de revisión sin una manera fácil de corregirlos. Para obtener más información, consulte los siguientes sitios web:

• Guía de IBM Cloudant para los conflictos
• Guía de IBM Cloudant para las versiones y MVCC
• Series del blog de tres partes sobre los conflictos

La supresión de documentos no los elimina

La supresión de un documento de una base de datos IBM Cloudant no lo elimina. La supresión se implementa escribiendo una nueva revisión del documento que se está suprimiendo, con un campo añadido _deleted: true. Esta revisión especial se denomina una tombstone. Los marcadores de exclusión continúan ocupando espacio y también pasa por ellos el replicador.

Los modelos que dependen de supresiones frecuentes de documentos no son adecuados para IBM Cloudant. Para obtener más información, consulte los Documentos con marcadores de exclusión de IBM Cloudant.

Tenga cuidado con las actualizaciones

Al final es más caro mutar los documentos existentes que crear otros nuevos. IBM Cloudant siempre necesita conservar la estructura del árbol de documentos. Esta regla se aplica aunque se eliminen las cargas útiles de los nodos internos del árbol. Si crea árboles de revisión largos, el rendimiento de las réplicas se resiente. Además, si su frecuencia de actualización es mayor que, por ejemplo, una o dos veces cada pocos segundos, es más probable que se produzcan conflictos de actualización.

Prefiera los modelos que son inmutables.

Cuando lee las secciones siguientes, La supresión de documentos no los suprime y Tenga cuidado con las actualizaciones, provocan una pregunta obvia. ¿El conjunto de datos crece sin límites si mi modelo es inmutable? Si acepta que las supresiones no depuran completamente los datos suprimidos y que las actualizaciones no son rentables en función del crecimiento del volumen de datos, no existe mucha diferencia. La gestión del volumen de datos en el tiempo requiere técnicas diferentes.

La única manera de recuperar verdaderamente el espacio es suprimir bases de datos, en lugar de documentos. Puede replicar solo las revisiones ganadoras de una nueva base de datos y eliminar la antigua para deshacerse de supresiones y conflictos persistentes. O quizás, puede incorporar los datos en el modelo para iniciar regularmente nuevas bases de datos (por ejemplo, "datos anuales") y archivar (o eliminar) datos obsoletos, si su caso de uso lo permite.

La coherencia final es una imposición dura (también conocida como no leer lo que se escribe)

La coherencia final es una gran idea en el papel y un factor clave en la capacidad de IBM Cloudantde escalar en la práctica. Sin embargo, es justo decir que la mentalidad necesaria para el desarrollo con un almacén de datos coherente al final no surge de manera natural para la mayoría de la gente.

A menudo te quedas picado cuando escribes pruebas similares a las siguientes:

1. Cree una base de datos.
2. Rellene la base de datos con datos de prueba.
3. Consulte la base de datos para obtener un subconjunto de estos datos de prueba.
4. Verifique que los datos que ha recibido son los datos que esperaba recuperar.

¿Es todo correcto en la prueba? Eso funciona en cualquier otra base de datos que hayas usado, ¿correcto?

Pero no en IBM Cloudant.

Más bien, funciona 99 veces sobre 100.

La razón de esta diferencia es una ventana de incoherencia (en su mayoría) pequeña entre la escritura de datos en la base de datos y el momento en que estos datos están disponibles en todos los nodos del clúster. Dado que todos los nodos de un clúster son iguales, no existe ninguna garantía de que una escritura y una lectura posterior sean atendidas por el mismo nodo. Por lo tanto, en algunas circunstancias, la lectura podría estar llegando a un nodo antes de que lleguen los datos escritos.

Por lo tanto, ¿por qué no incluye un breve retardo en la prueba entre la escritura y la lectura? El retardo hará que sea menos probable que falle la prueba, pero el problema seguirá ahí.

IBM Cloudant no tiene garantías transaccionales. Mientras que las escrituras de documentos son atómicas (se garantiza que un documento puede leerse en su totalidad o no leerse en absoluto), no existe ninguna manera de cerrar la ventana de incoherencia. Existe por diseño.

Un factor clave que todo desarrollador debe tener en cuenta es que no puede asumir con seguridad que los datos que escribe están disponibles para cualquier otra persona en un determinado momento. Algunos desarrolladores pueden tardar en acostumbrarse a este estado si provienen de una tradición de base de datos diferente.

Consejo de pruebas: lo que puedes hacer para evitar la ventana de inconsistencia en las pruebas es probar contra una instancia de un solo nodo de IBM Cloudant o CouchDB ejecutándose digamos en Docker(información de docker). Un solo nodo elimina el problema de coherencia final, pero tenga en cuenta que está probando un entorno que se comporta de forma diferente al entorno de producción. Caveat Emptor.

Las réplicas no son magia

“So let’s set up three clusters across the world, Dallas, London, Sydney, with bi-directional synchronization between them to provide real-time collaboration between our 100,000 clients.”

Núm. Solo... Núm. IBM Cloudant funciona bien con las réplicas. Podría parecer magia, pero tenga en cuenta que no hace ninguna garantía de latencia. De hecho, todo el sistema está diseñado teniendo en cuenta la coherencia final. Tratar la réplica de IBM Cloudant como un sistema de mensajería en tiempo real no termina bien. En este caso de uso, coloque un sistema en medio que se haya diseñado a tal efecto, por ejemplo, Apache Kafka.

Es difícil valorar el rendimiento de las réplicas. La respuesta es siempre "Depende". Los factores que afectan al rendimiento de las réplicas incluyen, pero no se limitan a:

1. Frecuencia de cambios
2. Tamaño de documento
3. Número de trabajos de réplica simultáneos en el clúster en su conjunto
4. Árboles de documentos amplios (en conflicto)
5. Los valores de capacidad de rendimiento reservados

Para obtener más información, consulte los siguientes sitios web:

• Entrada de blog sobre la topología de réplicas
• Guía de IBM Cloudant para las réplicas

Utilizar la API masiva

IBM Cloudant tiene buenos puntos finales de API para la carga masiva (y lectura) de muchos documentos en una sola solicitud. Leer muchos documentos en una sola petición puede ser mucho más eficiente que leer y escribir muchos documentos de uno en uno. El punto final de escritura se muestra en el ejemplo siguiente:

${database}/_bulk_docs

Su principal objetivo es ser una parte central en el algoritmo del replicador, pero también está disponible para su uso y es impresionante.

Con _bulk_docs, además de crear PouchDB, implemente la creación, actualización y supresión incluso de documentos individuales de esta manera para tener menos vías de acceso de código.

El ejemplo siguiente crea un documento nuevo, actualiza un segundo existente y suprime un tercer documento:

curl -XPOST 'https://ACCT.cloudant.com/DB/_bulk_docs' \
     -H "Content-Type: application/json" \
     -d '{"docs":[{"baz":"boo"}, \
         {"_id":"463bd...","foo":"bar"}, \
         {"_id":"ae52d...","_rev":"1-8147...","_deleted": true}]}'

También puede captar muchos documentos en una sola solicitud emitiendo un POST a _all_docs (también existe un punto final relativamente nuevo denominado _bulk_get, pero este punto final probablemente no es el que desea. Está ahí para un propósito interno específico).

Para captar un conjunto fijo de documentos utilizando _all_docs, POST con un cuerpo keys, ejecute el mandato siguiente:

curl -XPOST 'https://ACCT.cloudant.com/DB/_all_docs' \
     -H "Content-Type: application/json" \
     -d '{"keys":["ab234....","87addef...","76ccad..."]}'

IBM Cloudant (en el momento de la escritura) impone un tamaño máximo de solicitud de 11 MB. Las solicitudes de _bulk_docs que superan este tamaño se rechazan con un 413: Payload Too Large error.

Para obtener más información, consulte los siguientes sitios web:

• Documentos de operaciones masivas de IBM Cloudant
• Límites de tamaño de documentos y solicitudes de IBM Cloudant

No cambie Q, R y N a menos que sepa realmente lo que está haciendo

No cambie Q, R y N a menos que realmente sepa lo que está haciendo. los parámetros de quórum y fragmentación de IBM Cloudant, después de descubrirlos, parecen opciones tentadoras para cambiar el comportamiento de la base de datos.

Para aumentar la coherencia, ¿no puedo establecer el quórum de escritura en el recuento de réplicas?

¡No! Recuerde que no hay ninguna manera de cerrar la ventana de incoherencia en un clúster.

No insista. El comportamiento puede ser mucho más difícil de entender, especialmente durante las particiones de red. Si utiliza "el servicio Cloudant", los valores predeterminados son correctos para la mayoría de los usuarios.

A veces, ajustar el recuento de fragmentos para una base de datos es fundamental para conseguir el mayor rendimiento posible. Si no sabe por qué, es probable que empeore su situación.

IBM Cloudant tiene un límite de tarifa - deje que este límite de tarifa informe a su código

"El servicio Cloudant" (a diferencia de Basic CouchDB) se vende en un modelo de "capacidad de producción reservada". Esto significa que usted paga por el derecho a utilizar hasta un determinado caudal, en lugar del caudal que acaba utilizando. El método de derecho de uso tarda un tiempo en surtir efecto. Una comparación poco convencional puede ser la de un contrato de teléfono móvil donde paga un determinado número de minutos, independientemente de si los utiliza o no.

Aunque la comparación con el contrato de telefonía móvil no captura toda la situación, no existe ninguna restricción en la suma de solicitudes que puede realizar a IBM Cloudant en un mes. La restricción está en la rapidez con la que realiza las solicitudes.

Es realmente una promesa que usted hace a IBM Cloudant, no una que IBM Cloudant le hace. Promete no hacer más solicitudes por segundo de lo acordado por adelantado. Un límite de velocidad máximo, si lo prefiere. Si transgrede el límite, IBM Cloudant hace que las solicitudes fallen con un estado 429: Too Many Requests. Es su responsabilidad vigilar este caso, y gestionarlo, lo que puede ser difícil cuando existen varios servidores de aplicaciones. ¿Cómo pueden coordinarse para mantenerse colectivamente por debajo del límite de peticiones por segundo?

Las bibliotecas de cliente oficiales de IBM Cloudanttienen un suministro incorporado para este caso de uso que se puede habilitar, siguiendo una estrategia de "apagado y reintento".

Esta provisión incorporada está desactivada de forma predeterminada para forzarle a pensar en ella.

No obstante, si depende solo de este recurso, es posible que acabe decepcionándose. La estrategia de retroceso y reintento solo es útil en los casos de transgresión temporal, pero no es una contención persistente de los límites de capacidad de rendimiento suministrada.

La lógica empresarial debe poder manejar esta condición. Otra forma de verlo es que recibe la asignación por la que paga. Si esa asignación no es suficiente, la única solución es pagar por una mayor asignación.

La capacidad de rendimiento suministrada se divide en tres grupos diferentes: Búsquedas, Escrituras y Consultas. Una Búsqueda es una "clave primaria" leída, que capta un documento basándose en su _id. Una Escritura almacena un documento o un archivo adjunto en el disco, y una Consulta busca documentos utilizando un índice secundario (cualquier punto final de API que incluya un _design o un _find).

Obtiene diferentes asignaciones de cada grupo y las proporciones entre ellos son fijas. Este hecho se puede utilizar para optimizar el coste. Obtiene 20 Búsquedas por cada Consulta (por segundo). Puede considerar que se acerca principalmente al límite de Consultas, pero que tiene mucho espacio en las Búsquedas. Es posible que pueda reducir la dependencia de las Consultas mediante un remodelado de los datos o quizás aumentando el trabajo en el lado del cliente.

No obstante, el corolario es que no se puede suponer que ninguna biblioteca o infraestructura de terceros se optimiza para el coste antes que para la comodidad. Es poco probable que las infraestructuras del lado del cliente que dan soporte a varias capas de persistencia utilizando plugins sean conscientes de esta situación, o es posible que no puedan realizar estas compensaciones.

Se recomienda comprobar la compatibilidad de una biblioteca o infraestructura de terceros antes de comprometerse con una determinada herramienta.

También es importante entender que las tarifas no son equivalentes directamente a llamadas de punto final de la API HTTP. Por ejemplo, no debe extrañarse de que una actualización masiva cuente de acuerdo con sus escrituras de documentos constitutivas.

• Documentación de IBM Cloudant sobre planes y precios en la nube pública de IBM

El registro permite ver lo que está pasando

los registros de 'IBM Cloudant' que indican cada llamada a la API realizada, qué se solicitó y cuánto tardó en responder pueden enviarse automáticamente a ' IBM Cloud Logs ' para su análisis y elaboración de informes para los servicios basados en ' IBM Cloud. Estos datos son útiles para vigilar los volúmenes de solicitud, el rendimiento y si la aplicación supera la capacidad suministrada para el servicio IBM Cloudant.

IBM Cloud Logs es un servicio medido que ofrece diversos periodos de retención y niveles de consumo de registros. Los niveles permiten conservar los datos para archivarlos en COS, realizar búsquedas en frío o en caliente y recibir alertas con costes variables. Las porciones y agregaciones de los datos se pueden incorporar en paneles de control visuales para ofrecer una visión general del tráfico de IBM Cloudant. Para obtener más información, consulte la siguiente documentación:

• Introducción a IBM Cloud Logs
• Primeros pasos con IBM Cloud Logs Routing
• Optimizador del coste total de propiedad deIBM Cloud Logs

Comprimir el tráfico HTTP

IBM Cloudant comprime sus respuestas JSON si proporciona una cabecera HTTP en la solicitud que indica que el código puede manejar datos con este formato:

Request:

> GET /cars/_all_docs?limit=5&include_docs=true HTTP/2
> Host: myhost.cloudant.com
> Accept: */*
> Accept-Encoding: deflate, gzip

Response:                                                                   

< HTTP/2 200
< content-type: application/json
< content-encoding: gzip

El contenido comprimido ocupa una fracción del tamaño del equivalente descomprimido, lo que significa que tarda menos tiempo en transportar los datos de los servidores de IBM Cloudant a la aplicación.

También puede elegir comprimir los cuerpos de solicitud HTTP utilizando la cabecera de codificación de contenido. Esta práctica ayuda a reducir los tiempos de transferencia de datos cuando se escriben documentos en IBM Cloudant.