Centro de aprendizaje
El Centro de aprendizaje de IBM® Cloudant® for IBM Cloud® ofrece una serie de vídeos para ayudarle a aprender a utilizar IBM Cloudant. Los vídeos empiezan con los conceptos básicos de la utilización de IBM Cloudant. A continuación, los vídeos le guian a través de la estructura de documentos, la API, la indexación y la consulta, e incluyen un tema Bajo el Hood que resalta la arquitectura que alimenta el servicio.
Puede utilizar la lista de reproducción para pasar por los cursos o navegar directamente al tema que elija.
Vídeo Introducción a IBM Cloudant
Obtenga más información sobre la serie de vídeos IBM Cloudant serie de 17 vídeos que ofrece una visión general de la base de datos como servicio IBM Cloudant.
Script de vídeo Introducción a IBM Cloudant
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 1: ¿Qué es IBM Cloudant?
IBM Cloudant es una base de datos que se ejecuta como un servicio en el IBM Cloud®. Su trabajo es almacenar los datos de su aplicación de forma segura y hacer posible que la recupere de forma rápida y eficiente. Las características clave de IBM Cloudant se muestran en la lista siguiente:
- Base de datos
- Almacena y recupera datos. Más concretamente, es un almacén de datos JSON. JSON proviene de JavaScript y representa objetos simples en un formato de archivo universal.
- "Documento"
- La unidad de almacenamiento en IBM Cloudant. Los documentos se añaden, actualizan y suprimen en su totalidad.
- API HTTP
- Cualquier operación IBM Cloudant puede realizarse utilizando HTTPS. HTTP es el protocolo en el que se basa la World Wide Web y IBM Cloudant es una base de datos creada para la Web. La mayoría de las bases de datos están ocultas en una red privada, inaccesible pero disponible para algunas máquinas. El servicio IBM Cloudant se encuentra (principalmente) en la Internet pública, donde puede acceder a él cualquier persona con conexión a Internet (y permiso para hacerlo).
IBM no ha escrito IBM Cloudant por completo. Se basa en Apache CouchDB, un proyecto de código abierto dirigido por Apache Foundation. IBM Cloudant emplea un número de colaboradores de CouchDB pero por las reglas de Apache, no pueden monopolizar su desarrollo.
Gran parte de lo que se ve en este curso es tan aplicable a Apache CouchDB como a IBM Cloudant. El 99% de sus API son las mismas. Indico cuáles son las diferencias.
IBM Cloudant se puede considerar como CouchDB ejecutado "como servicio". Ingenieros de IBM despliegan fácilmente un servicio IBM Cloudant y los gestionan de manera totalmente ininterrumpida. No hay que instalar ningún programa, gestionar ningún servidor ni entender ninguna configuración. No es necesario que el usuario sea un experto en CouchDB para utilizarlo y gestionarlo.
Puede estar seguro de que la capa de datos no está bloqueada en una plataforma, nube o proveedor en particular porque IBM Cloudant se está creando con una bases de código fuente realmente abiertas. IBM Cloudant se puede utilizar junto con CouchDB para crear aplicaciones híbridas que compartan datos a través de la réplica, como vemos.
Más adelante en el curso vemos Las entrañas para ver cómo funciona IBM Cloudant, pero inicialmente tratamos IBM Cloudant como una "caja negra".
Resumiendo, Cloudant se basa en Apache CouchDB, un proyecto de código abierto. Almacena documentos JSON. Se accede a él con una API HTTP y, por lo tanto, cualquier dispositivo en Internet compatible con HTTP tendrá acceso: código de aplicación, navegador web, dispositivo IoT o teléfono móvil. IBM Cloudant es un servicio gestionado de alta disponibilidad que puede continuar funcionando aunque haya varias anomalías de hardware.
Aquí acaba esta parte. La siguiente parte se denomina El documento.
Vídeo El documento
Obtenga información sobre el funcionamiento de documentos y bases de datos de IBM Cloudant.
Script de vídeo El documento
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este video es la parte 2 - El IBM Cloudant Documento.
En la sección anterior, vimos que IBM Cloudant es un almacén de documentos JSON. Vamos a averiguar qué significa esto en la práctica y en qué se diferencia de otros tipos de base de datos.
La mayoría de las bases de datos almacenan sus datos en colecciones denominadas tablas, en las que cada unidad de datos es una fila, cada una de ellas con columnas fijas idénticas. El esquema de cada tabla está predefinido: una lista de columnas con su nombre, tipo de fecha, restricciones de valor y relaciones con otras tablas definidas con detalle. Cada registro nuevo forma una fila en una tabla.
IBM Cloudant es diferente.
Un servicio de IBM Cloudant incluye colecciones que se denominan bases de datos (en lugar de tablas), cada una de las cuales contiene cualquier número de documentos.
El ejemplo de esta diapositiva muestra los mismos datos que se expresan en una base de datos tabular tradicional y cómo los mismos datos se almacenarían en IBM Cloudant como documentos JSON.
Por lo tanto, si anteriormente trabajaba con bases de datos relacionales: las tablas son "bases de datos" en IBM Cloudant y las filas son "documentos".
Un documento de IBM Cloudant debe ser un objeto JSON, empezar y acabar con llaves y contener diversos atributos clave-valor.
Los objetos JSON deben tener un tamaño menor de 1 megabyte en tamaño y contener cualquier número de series, números, valores booleanos, matrices y objetos. El anidamiento de objetos dentro de objetos se puede prolongar hasta cualquier profundidad.
Las claves que se utilizan pueden ser tan breves o detalladas como desee.
La lista siguiente incluye algunos documentos de ejemplo sencillos que muestran cómo se utiliza cada tipo de datos.
- En el primer ejemplo, se muestra un objeto de persona, que almacena series, valores booleanos y una matriz de etiquetas.
- El segundo ejemplo muestra nombres de atributo breves para guardar en el almacenamiento y representa un suceso web como, por ejemplo, hacer clic en un sitio web.
- El último ejemplo muestra cómo el propio documento puede contener temas.
Un detalle sobre las fechas. JSON no tiene ningún tipo de fecha nativo, por lo que las fechas normalmente se almacenan en formatos 30-octubre-2018 o similares. Volvemos a hablar de las fechas más adelante.
Ahora, para el primer ejercicio práctico, visite www.ibm.com/cloud. Registre una cuenta en IBM Cloud, si aún no dispone de una.
Una vez registrado, puede pulsar servicios, buscar la base de datos Cloudant y suministrar un nuevo servicio.
El servicio de IBM Cloudant Lite
proporciona un plan gratuito para permitir a los usuarios probar IBM Cloudant con capacidad limitada mientras está en desarrollo. Su "hermano mayor", el Standard Plan
, es
un servicio de pago en el que se especifica el número de lecturas, escrituras y consultas por segundo para la aplicación y se reserva esa capacidad para usted. El usuario pagar por la capacidad que suministra y por el uso de almacenamiento
de datos.
El plan Lite funciona de manera similar. Solo tiene una pequeña capacidad de suministro y un tamaño de almacenamiento fijo, pero está bien para probar el servicio de IBM Cloudant.
IBM Cloudant a menudo se conoce como una base de datos "sin esquema", pero debemos tener cuidado en cómo definimos este término.
Es cierto que no es necesario definir el esquema (nombres de campo, tipos, restricciones y relaciones) de antemano en una base de datos IBM Cloudant. Simplemente puede escribir un documento JSON diseñado por usted mismo en una base de datos.
A los desarrolladores les gusta esta flexibilidad porque pueden diseñar sus datos en su código, convertirlo en JSON y escribirlo en la base de datos.
Aun así es importante pensar en la forma de sus datos, especialmente por lo que respecta a cómo va a consultarlos e indexarlos, como veremos más adelante.
Sigue siendo necesario diseñar los datos, pero estrictamente hablando, la base de datos no necesita conocer el esquema.
Supongamos que queremos crear una base de datos de presidentes de los Estados Unidos. Podemos simplemente diseñar nuestro "modelo" de los datos en nuestra aplicación, convertirlo en JSON y escribirlo en la base de datos. En este caso, utilizamos un convenio CouchDB común: el campo "type" indica el tipo de datos del documento.
Si en una fecha futura decidimos añadir más datos a nuestro "esquema", simplemente podemos escribir un objeto nuevo en la base de datos sin inconveniente por parte de IBM Cloudant. Podríamos optar por añadir el objeto "address" solo a los siguientes documentos:
- Documentos que se creen a partir de esta fecha.
- Solo los documentos de los que sabemos las direcciones.
En otras palabras, los documentos del mismo tipo pueden tener los mismos campos o no.
El esquema de la base de datos puede evolucionar con el tiempo para ajustarse a las necesidades de la aplicación. No es necesario (necesariamente) indicar a la base de datos el cambio de esquema: escriba nuevos documentos en el nuevo formato.
Podemos incluso almacenar distintos tipos de documentos en la misma base de datos. En este caso, personas, libros y lugares residen en la misma base de datos. Sabemos cuál es cuál gracias al campo "type" (este campo es una convención y no algo que tenga significado para IBM Cloudant).
Una alternativa a esta configuración es disponer de tres bases de datos (personas, libros y lugares) y mantener cada tipo de datos en su propia base de datos. Los dos enfoques son correctos. Puede elegir tener varios tipos juntos en la misma base de datos si necesita realizar consultas entre tipos o si necesita replicar todos los tipos de datos juntos. De lo contrario, el enfoque de bases de datos independientes podría ser mejor.
Para resumir, aunque IBM Cloudant es "sin esquema", esto no le exime de la necesidad de realizar un diseño detallado de los datos para obtener el mejor rendimiento.
Estos consejos resultan especialmente importante si tiene alguna experiencia en bases de datos relacionales.
- Evite pensar en uniones: un documento de IBM Cloudant debe contener todo lo que necesita sobre ese objeto para que se pueda recuperar en una llamada de API.
- En al almacén de JSON, no se aplica la normalización; se pueden tolerar algunos valores repetidos si se consigue una recuperación de datos más eficiente.
- Aunque tenemos un límite de 1 MB en el tamaño de un documento, los documentos deben ser mucho más pequeños, unos cuantos KB es lo normal.
- Si su aplicación puede adoptar un patrón de diseño de "sólo escritura"*, en el que los datos solo se añaden a una base de datos, esto puede facilitarle la vida. Sin duda, debe evitar patrones que se basen en la actualización del mismo documento una y otra vez dentro de una pequeña ventana de tiempo.
Aquí acaba esta parte. La siguiente parte se denomina El ID de documento.
El vídeo _id
Conozca cómo funcionan los _id
en IBM Cloudant, en qué se diferencian de las bases de datos relacionales y cómo puede definir su propio _id
.
El script de vídeo _id
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 3: El _id
de documento.
En la sección anterior, vimos cómo se almacenan los datos en los documentos de IBM Cloudant con flexibilidad sobre cómo la aplicación almacena objetos JSON en bases de datos de IBM Cloudant. Sin embargo, existen unas cuantas reglas estrictas y rápidas.
Una regla es que cada documento debe contener un identificador exclusivo denominado _id
, que es una serie. Dos documentos de la misma base de datos pueden tener el mismo campo _id
. En otras bases de datos, se debe
especificar qué columna es el identificador exclusivo, pero en IBM Cloudant, siempre es _id
y no se puede cambiar.
Además, a diferencia de las bases de datos relacionales, IBM Cloudant no tiene "ID de incremento automático" es decir, un campo de ID que se empiece 1 y se incremente para cada documento añadido.
El campo _id
de IBM Cloudant es una de las series siguientes:
- Una serie de 32 caracteres generada por IBM Cloudant. El ID es una secuencia sin significado de números y letras que se garantiza que son únicos.
- Una serie definida por usted (si conoce algo único sobre sus datos).
En los ejemplos siguientes se muestra cómo proporcionar su propio _id
de documento:
Usándolo para almacenar algo que usted sabe es único, es decir, la dirección de correo electrónico de un usuario. El mecanismo de registro puede imponer una política de dirección de un usuario por correo electrónico. Algunos usuarios optan
por codificar el tipo de documento en el _id
, por ejemplo, user:56
, book:55
. En el último ejemplo se muestra una serie de 32 dígitos (generada en la aplicación) que se ha diseñado para clasificar en
orden de fecha y hora aproximada. Este método facilita la recuperación de los últimos documentos de la base de datos, sin un índice secundario.
IBM Cloudant toma los _ids
de los documentos y los almacena en un índice (como el índice de un libro). Este índice primario está en orden de _id
y se utiliza para permitir que IBM Cloudant recupere documentos por
su _id
, comportándose así como un almacén de pares clave-valor.
Mediante un diseño minucioso del campo _id
, puede hacer que utilice el índice primario para mantener datos juntos que tengan sentido en el índice primario. Este método permite recuperar esos datos con más rapidez posteriormente.
Hemos visto que el uso de _ids
que se puedan ordenar por tiempo permite recuperar los datos en orden de fecha y hora aproximada.
Veremos un ejemplo más adelante referente a la recuperación de rangos de ID de documento.
En conclusión, cada documento debe tener un campo _id
exclusivo en la base de datos. Puede generarlo automáticamente IBM Cloudant o puede suministrarlo su aplicación, en cuyo caso se debe asumir la responsabilidad de la exclusividad
del campo _id
.
El campo _id
es la base del índice primario de la base de datos, que, como veremos más adelante, se puede utilizar para búsquedas de pares clave-valor y consultas de rango.
Aquí acaba esta parte. La siguiente parte se denomina La señal de rev.
Vídeo La señal de rev
Obtenga información sobre cómo IBM Cloudant crea una señal de revisión cuando añade, edita o suprime un documento.
Script de vídeo La señal de rev
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 4: La señal de rev.
La segunda regla fundamental de IBM Cloudant es que cada revisión de documento obtenga su propia señal de revisión exclusiva. Veamos qué significa.
Nunca es necesario generar una señal de revisión: se crea una automáticamente cuando se añade, actualiza o suprime un documento que utiliza la API.
Una señal de revisión consta de dos partes:
Un número 1, 2, 3, y así sucesivamente, y un hash criptográfico del cuerpo del documento. (Para las personas no iniciadas, un hash es una "huella dactilar" digital de algunos datos. Si los datos cambian, la huella dactilar cambia. No existen 2 huellas dactilares iguales, es decir, no existen 2 documentos con contenido diferente que puedan tener el mismo hash).
Puede ver en el ejemplo de la pantalla que nuestro documento tiene un token de revisión (la clave empieza por _rev
) que empieza por un 1
seguido de un guión. Esto indica que esta revisión es la primera revisión del
documento. Los dígitos que empiezan por 04aa8...
son el hash criptográfico del documento.
Si seguimos el ciclo de vida de un documento, se inicia con un revision 1
. Cuando se modifica más adelante, obtiene un revision 2
, y así sucesivamente. Con cada número de revisión incremental, el hash cambia porque
el contenido del documento también se está modificando.
Un documento puede tener más de una revisión con el mismo número. En este caso, existen dos revision 3s
. Este escenario se conoce como un conflicto y es "normal" en algunas circunstancias. Veremos por qué más
adelante en el curso pero, por ahora, podemos suponer que el número de revisión se incrementa con cada actualización de un documento.
Sigamos el ciclo de vida de un ejemplo de documento de IBM Cloudant:
Cuando se crea un documento nuevo (ya sea con un _id
generado automáticamente o con _id
proporcionado por el usuario), se le asigna un revision 1
. Se le enviará la señal en la respuesta a su solicitud
de API. Normalmente, puede descartar la revisión (a menos que tenga la intención de modificar el documento pronto).
Cuando se modifica un documento cuya _rev
se encuentra en la revision 1
, el documento se guarda y se genera una señal revision 2
y se devuelve a usted en la respuesta de la API. Observe que cambiamos
el nombre en el documento de Liz a Elizabeth.
Hasta ahora, bastante sencillo.
Si eliminamos el documento más tarde, se crea una revision 3
.
A diferencia de casi cualquier otra base de datos, IBM Cloudant mantiene una referencia para los documentos suprimidos. Una supresión es solo otra revisión de documento, una de tipo especial en la que _deleted: true
sustituye
el cuerpo del documento.
De hecho, se mantiene el historial de revisiones recientes del documento (el árbol de revisiones; recuerde que puede haber más de un mismo número de revisión).
No se puede utilizar el árbol de revisiones de IBM Cloudant como sistema de control de versiones para recuperar una revisión anterior o regresar a ella. Una vez sustituida una revisión, se elimina el cuerpo del documento de la revisión anterior y se recupera su espacio en disco en un proceso denominado compactación. La compactación se produce automáticamente en IBM Cloudant, por lo que no es seguro asumir que las revisiones antiguas están disponibles para poder recuperarlas.
En resumen, las señales de revisión las genera la base de datos al añadir, editar y suprimir un documento. (Nunca es necesario que cree sus propias señales de revisión). Generalmente, el número de revisión se incrementa en uno cada vez, pero
son posibles escenarios más complejos (que trataremos más adelante). Los cuerpos de documentos anteriores se descartan o se compactan (no cuente con poder recuperarlos más tarde). Todas las operaciones de IBM Cloudant que cambian un documento
necesitan el _id
del documento y su _rev
(este escenario es diferente al de la mayoría de las bases de datos).
Aquí acaba esta parte. La siguiente parte se denomina Autenticación.
Video Autenticación
Aprenda cómo funcionan la autenticación heredada y la autenticación de IAM. También puede aprender cómo IBM Cloudant genera credenciales y cómo las tres bibliotecas oficiales de IBM Cloudant gestionan la autenticación.
Script de vídeo Autenticación
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 5: Autenticación.
Dijimos anteriormente que IBM Cloudant es un servicio basado en la web en el Internet público. ¿Cómo podemos estar seguros de que nuestros datos están protegidos y de que solo puede acceder a ellos nuestro código? Este escenario es donde entra en juego la autenticación.
IBM Cloudant admite dos tipos de autenticación.
La autenticación heredada es aquella en la que se proporciona un nombre de usuario o una clave api y una contraseña con cada solicitud que utiliza la autenticación básica HTTP o se intercambia por una cookie que utiliza una llamada a la API de sesión única. Una cookie de sesión se renueva periódicamente, por lo que su código de cliente debe capturar la cookie renovada y almacenarla para solicitudes posteriores. La autenticación de IAM es el sistema de gestión de acceso que sustenta todos los servicios de IBM Cloud. Para autenticarse con IAM, necesita una clave de API de IAM y el nombre de host del servicio IBM Cloudant. La clave de API se intercambia por una señal portadora utilizando la API de IAM y la señal portadora se pasa a IBM Cloudant con cada solicitud. La señal portadora solo dura una hora, por lo que debe renovarse con el servicio de IAM periódicamente. Cuando se aprovisiona un servicio IBM Cloudant, se pueden generar credenciales sólo de IAM, o credenciales tanto de IAM como heredadas: tú decides.
¿Cómo se generan las credenciales?
En el panel de control de IBM Cloud bajo el servicio de IBM Cloudant, en el separador Credenciales de servicio, pulse Nueva credencial. Se crea un documento JSON que contiene la clave IAM, el nombre de usuario y la contraseña de autenticación básica y el nombre de host IBM Cloudant.
Consulte el conjunto de ejemplo de credenciales:
Para IAM, necesita la apikey y el host. Tanto para Legacy como para Basic-Auth o ambos, necesita la URL (que contiene el nombre de usuario y la contraseña que están integrados en la URL ).
IBM Cloudant cuenta con tres bibliotecas de cliente oficiales: Java™, Node.js y Python.
Las tres gestionan la autenticación automáticamente. No es necesario que se preocupe por cómo intercambia la clave de API por una señal de sesión o cómo funciona la autenticación de IAM, lo hacen las bibliotecas.
Cuando discutimos la API en la documentación, utilizamos la autenticación básica para comodidad. Sin embargo, le recomendamos que utilice la autenticación de IAM si es posible, ya que permite una mejor integración con la plataforma IBM Cloud y permisos más precisos.
Ahora vamos a realizar nuestro próximo ejercicio práctico.
Inicie sesión en IBM Cloud y busque el servicio Lite IBM Cloudant que creamos la última vez. En el separador Credenciales de servicio, pulse el botón Nueva credencial para generar un conjunto de credenciales
IAM+Legacy
. Toma nota del JSON que devuelve - lo necesitaremos para el próximo ejercicio.
A continuación, visite el URL especificado en el JSON de credenciales; ¿qué observa?
En resumen, las credenciales se generan desde el panel de control de IBM Cloud. Puede haber credenciales de IAM o credenciales Legacy e IAM. Ambos métodos de autenticación implican el intercambio de las credenciales por una señal de tiempo limitado (autenticación); a continuación, la señal se actualiza periódicamente mientras se utiliza el servicio. Las bibliotecas oficiales se encargan de todas estas tareas automáticamente.
Aquí acaba esta parte. La siguiente parte se denomina El panel de control.
Vídeo El panel de control
Obtenga información sobre el panel de control de IBM Cloudant y lo que este ofrece, así como una introducción sobre cómo utilizarlo.
Script de vídeo El panel de control
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 6: El panel de control.
La forma más fácil de empezar, crear bases de datos y añadir documentos es utilizando el panel de control de IBM Cloudant.
El panel de control de IBM Cloudant es una aplicación web integrada en el servicio. Permite realizar la manipulación de datos básica por medio de una interfaz gráfica de usuario: se pueden crear y suprimir bases de datos, añadir, actualizar y suprimir documentos y gestionar trabajos de réplica. También es un lugar práctico para realizar consultas puntuales y para configurar índices secundarios (como veremos más adelante).
También contiene algunas herramientas de supervisión sencillas que visualizan las tasas de solicitud.
Es importante tener en cuenta que cualquier tarea que se pueda realizar por medio del panel de control de IBM Cloudant también se puede llevar a cabo mediante la API HTTP de IBM Cloudant. De hecho, el panel de control de IBM Cloudant simplemente realiza llamadas de API estándar por sí mismo.
Para abrir un panel de control del servicio de IBM Cloudant, inicie sesión en IBM Cloud, busque el servicio de IBM Cloudant y pulse el botón Iniciar el panel de control de IBM Cloudant. Se abre una nueva ventana que inicia la sesión en el panel de control de IBM Cloudant.
Si deja desatendida la ventana del panel de control durante un periodo de tiempo, se cerrará la sesión (por motivos de seguridad) y se debe volver a pulsar Iniciar.
El panel de control tiene varios separadores. Su separador predeterminado, Bases de datos, ofrece una lista de las bases de datos que ha creado en grupos de 20. Cada base de datos muestra el número de documentos que almacena y el espacio que ocupa en disco. Pulse un nombre de base de datos para examinar su contenido.
Para crear una base de datos, pulse Crear base de datos y proporcione el nombre de la base de datos que desee crear.
Tenemos una nueva base de datos vacía. Los documentos de la base de datos se enumerarán aquí por orden de ID. Sin embargo, dado que esta base de datos es nueva, no existen documentos. Para añadir un documento, pulse Crear documento.
El panel de control de IBM Cloudant ha creado una plantilla de documento automáticamente con un _id
generado previamente. Introduzca el resto de los atributos para completar el documento JSON y pulse Crear documento para guardarlo.
Ahora vamos a realizar otro ejercicio práctico. Cree una base de datos denominada books
(libros), y en esa base de datos, cree tres o más documentos con los campos title (título), author (autor), date (fecha), publisher (editorial)
e ISBN, cada uno de los cuales representa un libro de su elección.
Una vez creados, edite uno de los documentos y modifique la fecha de publicación.
A continuación, suprima uno de los documentos.
En resumen, el panel de control de IBM Cloudant es una aplicación web que se crea en el servicio de IBM Cloudant y forma parte de la oferta de código abierto de CouchDB. Se utiliza para gestionar bases de datos, documentos, índices, consultas y trabajos de réplica. También se puede utilizar para supervisar el rendimiento del servicio. El panel de instrumentos es simplemente un cliente de API: todo lo que se puede llevar a cabo con el panel de instrumentos se puede realizar mediante scripts con la API HTTP.
Aquí acaba esta parte. La siguiente parte se denomina Aspectos básicos de la API HTTP.
Vídeo Aspectos básicos de la API HTTP
Obtenga información sobre cómo utilizar la línea de mandatos para realizar solicitudes HTTP y para añadir, editar y suprimir documentos.
Script de vídeo Aspectos básicos de la API HTTP
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 7: Aspectos básicos de la API HTTP.
En la parte anterior, vimos el panel de control de IBM Cloudant, que es una aplicación web que realiza llamadas HTTP a la API de IBM Cloudant. En este paso, utilizamos la línea de mandatos para realizar solicitudes HTTP y para intentar añadir, editar y suprimir algunos documentos desde allí.
Vale la pena comprender la API HTTP desde el principio, aunque tenga la intención de utilizar las bibliotecas de cliente de nivel superior.
La ventaja de una base de datos que disponga de una API HTTP es que cualquier dispositivo en Internet puede leer y escribir datos si usted lo desea. No es necesario ningún software especial. No hay controladores que "hablen" un protocolo personalizado. Solo una biblioteca HTTP estándar. Por ejemplo, todo "habla" HTTP:
- Navegador web
- Cualquier lenguaje de programación
- Herramientas que puede utilizar para escribir scripts desde la línea de mandatos como curl
- Dispositivos móviles
Vamos a aprender los conceptos básicos de la API utilizando curl, una herramienta gratuita de línea de comandos de código abierto que puede distribuir solicitudes HTTP. Curl viene preinstalado en la mayoría de los sistemas operativos de tipo
Unix y Macs. Si no la tiene en su sistema, busque curl
en Google y siga las instrucciones de instalación.
En primer lugar, vamos a utilizar curl para captar una página web: la página de inicio de Google.
-
En un terminal de línea de mandatos, escriba
curl https://www.google.com
.Obtendrá una página de HTML como respuesta.
Si este método funciona, se instala curl y se puede continuar con las tareas siguientes. Ahora, no queremos escribir la URL de nuestro servicio IBM Cloudant cada vez, así que guardemos la URL de IBM Cloudant en una variable de entorno llamada URL. -
Ejecute el mandato
export URL
para crear una variable denominadaURL
, a la que podemos acceder posteriormente.export URL=https://username:password@host
-
Cree un
alias
.alias acurl="curl -sgH 'Content-type: application/json'"
Este
alias
es un acceso directo que se denominaacurl
y que nos evita tener que escribir más. Este mandatoacurl
es un alias para curl pero con la cabecera de tipo de contenido JSON y un par de conmutadores de línea de mandatos útiles. -
Pruebe el
alias
recuperandoacurl $URL/
. Obtenemos JSON de IBM Cloudant.Ha realizado la primera llamada de API de IBM Cloudant. Ahora, nuestro alias
acurl
está configurado. Podemos empezar a explorar la API. Comencemos con el punto final_all_dbs
, que devuelve una lista de bases de datos. -
Escriba
acurl $URL/_all_dbs
para ver una matriz de bases de datos.
Un inciso sobre el formato de JSON en la línea de mandatos. Podemos enviar la salida de nuestro comando acurl
a otra herramienta, que da formato a los datos adecuadamente en el terminal. Se pueden usar las siguientes herramientas:
- Jq disponible en la URL de la página, que es algo más que un simple formateador de JSON: también permite analizar, consultar y manipular JSON.
python -m json.tool
es un formateador JSON sencillo, si Python está instalado en su sistema.
Por lo tanto, acurl $URL/_all_dbs | jq
significa canalizar la salida de acurl a jq y lo que se ve es una salida en color muy bien formateada.
Las vías de acceso de API de IBM Cloudant son jerárquicas: el primer nivel proporciona información sobre el servicio y, luego, cada base de datos se encuentra en un nivel por debajo de este.
Así que acurl $URL/books
nos da información sobre la base de datos de libros que hemos creado antes.
Puede ver información sobre cuántos documentos tiene, cuántos documentos se han suprimido y cuánto espacio de disco ocupa.
No se olvide de canalizar la salida a jq o Python para obtener una salida más atractiva.
Si queremos ver los documentos que contiene la base de datos, podemos utilizar el punto final _all_docs
.
Por lo tanto, acurl $URL/books/_all_docs
significa obtener todos los documentos de la base de datos de libros del servicio de IBM Cloudant en el URL proporcionado.
Los resultados de este mandato devuelven una lista de valores _id
y _rev
de cada documento. Si desea obtener también los cuerpos de los documentos, añada ?include_docs=true
a la llamada de API.
Si queremos captar un solo documento de la base de datos, los documentos se encuentran un nivel por debajo de la base de datos en la jerarquía del URL.
Por lo tanto, acurl $URL/books/id
significa "obtener el ID de documento de la base de datos books
del servicio de IBM Cloudant en el URL proporcionado".
Observe la jerarquía: servicio, base de datos y documento.
Hasta ahora solo hemos utilizado el método HTTP GET
, que es el predeterminado para curl y el que se utiliza cuando se introduce un URL en el navegador web.
La API de IBM Cloudant suele utilizar el método HTTP como verb
para describir la acción que se solicita de la base de datos: GET para captar datos.
Con curl, podemos especificar el método que queremos utilizar con la opción de línea de mandatos -X
.
Por lo tanto, para escribir un nuevo documento en nuestra base de datos books
que utiliza la API, utilizaremos el método POST, pasando un documento como cuerpo de la solicitud HTTP.
acurl -X POST
especifica que estamos utilizando el método HTTP de POST
. -d
especifica el documento que queremos escribir, que se envía como el cuerpo de la solicitud y, por último, el URL al que estamos
escribiendo que es $URL/books
- la base de datos de libros.
Como alternativa, podemos utilizar el método PUT
, si proporcionamos el ID del documento que se está escribiendo. El URL pasa a ser $URL/books/
, seguido del ID que queremos escribir.
Ambos métodos de escritura producen respuestas idénticas. OK:
True para indicar que la escritura se ha realizado correctamente. ID es el ID del documento escrito y rev es la señal de revisión que ha generado la base de datos.
Para modificar un documento, podemos utilizar el método PUT para escribir el nuevo cuerpo en el URL que apunta al ID de documento que queremos sobrescribir. -d
suministra el nuevo cuerpo del documento, y el URL no sólo contiene
la base de datos y el ID del documento, sino la fundamental revisión del documento que pretendemos mutar.
Si olvidamos y omitimos el parámetro rev, obtenemos una respuesta de error.
Los códigos de respuesta HTTP muestran si una solicitud es correcta o no. Las respuestas en el rango de 200 son correctas. Las respuestas en el rango de 400 son errores de usuario (por ejemplo, parámetros no válidos) y las respuestas en el
rango de 500 son errores del lado del servidor. Además, puede ver la solicitud y la respuesta HTTP completa proporcionando la opción de línea de mandatos -v
a curl/acurl
.
Además, las actualizaciones de los documentos se producen en su totalidad o no se producen en absoluto. No existe ninguna construcción API para modificar parte de un documento. Se debe proporcionar un documento completo para sobrescribir una revisión anterior.
Por último, para suprimir un documento, se utiliza el método DELETE, por lo tanto -X DELETE
. Dirigimos la solicitud al URL que incluye el nombre de la base de datos y el documento que se debe suprimir y, esto es muy importante,
también proporcionamos el valor de rev, la revisión del documento que se debe suprimir.
Si omitimos la señal de revisión, se devuelve un error y la solicitud falla.
En resumen, conocer la API HTTP le ayudará a comprender la relación entre el código y el servicio de IBM Cloudant.
Los URL son jerárquicos: service/database/document
o service/database/endpoint
.
Los métodos HTTP actúan como verbs
que definen la acción que se va a realizar.
Todas las acciones se pueden desencadenar utilizando llamadas de API HTTP simples, desde la línea de mandatos o desde el código, por lo que se pueden escribir fácilmente.
Aquí acaba esta parte. La siguiente parte se denomina La API masiva.
Vídeo La API masiva
Aprenda a utilizar dos llamadas de API para realizar todas las operaciones básicas de IBM Cloudant y, al mismo tiempo, realizar acciones en más de un documento por llamada de API.
Script de vídeo La API masiva
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 8: La API masiva.
En la parte anterior, vimos cómo se podían añadir, actualizar, y borrar documentos fácilmente por separado utilizando la API HTTP de IBM Cloudant. En esta parte, vemos cómo se pueden utilizar dos llamadas de API para llevar a cabo todas las operaciones básicas de IBM Cloudant. Esto tiene como beneficio añadido que se puede actuar sobre más de un documento por llamada de API.
Ya hemos hablado sobre el punto final _all_docs
. Lo hemos utilizado para obtener una lista de todos los documentos de una base de datos, pero también tiene otras características.
El parámetro key se puede utilizar para especificar un único documento para obtenerlo, lo que lo hace equivalente a la llamada de API GET /db/id
. De forma similar, el parámetro keys toma una matriz de ID de documentos y los devuelve
todos. Los parámetros startkey
y endkey
captan una porción del índice primario entre los límites proporcionados. Al añadir include_docs=true
se indica a IBM Cloudant que también debe proporcionar los
cuerpos de los documentos. Y limit especifica cuántos documentos deben devolverse en una llamada de API.
El punto final _bulk_docs
permite realizar varias operaciones de inserción, actualización y supresión en una llamada de API. Espera un objeto que contenga una matriz de documentos. Cada elemento de esa matriz es una operación
a realizar en un solo documento. El cuerpo de la solicitud se envía a IBM Cloudant, lo que permite que muchas operaciones se incluyan en una sola llamada de API.
En este ejemplo, el primer documento es una inserción porque no se proporciona ninguna señal de revisión. El segundo documento es una actualización de un documento, porque se proporciona una señal de revisión con un nuevo cuerpo de documento.
El tercer documento es una supresión. Se proporciona una señal de revisión, pero el cuerpo es simplemente _deleted: true
, lo que indica a IBM Cloudant que debe marcar el documento como suprimido.
Es importante tener en cuenta que este escenario no es como una transacción en una base de datos relacional; todas o ninguna de estas operaciones podrían tener éxito o fallar individualmente. Los datos de respuesta a esta solicitud muestran la respuesta para cada operación a su vez.
En resumen, con dos llamadas de API _bulk_docs
y _all_docs
, podemos realizar todas las operaciones de creación, lectura, actualización y supresión en documentos de IBM Cloudant y hacerlo también de forma masiva. _all_docs
recupera documentos por _id
o rangos de ID. _bulk_docs
crea, actualiza y suprime documentos de forma masiva. Por lo general, recomendamos que las escrituras masivas se ejecuten en lotes de 500; más para documentos
muy pequeños y menos para documentos grandes.
Vea una captura de pantalla del uso de IBM Cloudant desde un terminal de línea de comandos:
Aquí acaba esta parte. La siguiente parte se denomina Acceso mediante programación a IBM Cloudant.
Vídeo Acceso mediante programación a IBM Cloudant
Aprenda cómo acceder a IBM Cloudant mediante programación.
Script de vídeo Acceso mediante programación a IBM Cloudant
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 9: Acceso mediante programación a IBM Cloudant.
Hasta ahora, nuestras interacciones con la API se desencadenaron mediante el panel de control o utilizando curl desde la línea de mandatos. En la sección siguiente, vemos cómo se accede a IBM Cloudant mediante programación.
Los ejemplos utilizan Node.js, por lo que si desea probar el código usted mismo, debe instalar el nodo y npm desde nodejs.org.
A continuación, podemos instalar la biblioteca oficial Node.js de IBM Cloudant con npm install @cloudant/cloudant
. (npm es el gestor de paquetes que se incluye con Node.js y que permite acceder a miles de proyectos de código abierto
e integrarlos en la aplicación de forma gratuita).
Una vez instalada la biblioteca de IBM Cloudant, podemos crear código fuente. Veamos este fragmento de código línea por línea:
La URL del servicio IBM Cloudant se obtiene de la variable de entorno que hemos creado anteriormente.
La biblioteca @cloudant/cloudant
se carga en la aplicación Node.js con las funciones incorporadas necesarias. A continuación, creamos una instancia de la biblioteca que está configurada con las credenciales que almacenamos en
la primera línea. Utilizamos el objeto IBM Cloudant para obtener una referencia a la base de datos books
y almacenarla en una base de datos de variables. No hemos realizado ninguna llamada a la API, sólo hemos creado estructuras
de datos que almacenan las credenciales y la base de datos en la que estamos trabajando. La función principal llama a db.list
, que se correlaciona 1-1 con el punto final _all_docs
que vimos anteriormente. Los parámetros
pasados a db.list
deben ser conocidos, como las opciones que _all_docs
espera para limitar el conjunto de resultados y para devolver los cuerpos de los documentos correspondientes a cada ID.
Vea otro fragmento de código que escribe un documento.
Puede ver desde la primera línea que se pueden utilizar objetos JavaScript estándar en el código y se pueden enviar a IBM Cloudant sin conversión, ya que se convierten en JSON de forma nativa en JavaScript.
Escribir un documento es simplemente una cuestión de llamar a db.insert
, que se correlaciona con una llamada de API PUT/POST
o con _bulk_docs
.
En resumen, las bibliotecas oficiales de IBM Cloudant son Java™, Python y Nodejs. Son envoltorios finos alrededor de la API HTTP de IBM Cloudant, por lo que vale la pena conocer la API subyacente para entender todos los parámetros.
Las bibliotecas se encargan de dos cosas por usted, lo cual resulta útil:
- Autenticación
- Intercambio de claves para señales, ya sea autenticación heredada o IAM.
- Lógica de reintentos
- Las bibliotecas se pueden configurar para reintentar las llamadas de API que han excedido la capacidad suministrada. Si se configuran de esta manera, se ponen en pausa y vuelven a intentar la llamada de API varias veces con retroceso exponencial.
Reintentar estas llamadas de API es razonable si se produce un aumento temporal e inesperado del tráfico. Si sobrepasa rutinariamente su capacidad suministrada, no conseguirá realizar el trabajo de la base de datos por muchos reintentos que se lleven a cabo; necesita más capacidad.
Aquí acaba esta parte. La siguiente parte se denomina Consultas.
Vídeo Consultas
Aprenda las distintas formas de consultar datos en IBM Cloudant.
Script de vídeo Consultas
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 10: Consultas.
Hasta ahora hemos realizado operaciones CRUD (crear, recuperar, actualizar y eliminar) desde la línea de comandos, el panel de control y desde código. Estas operaciones utilizan el _id
del documento:
- Obtención de documento por
_id
. - Actualización del documento cuyo
_id
= 'x'. - Supresión del documento cuyo
_id
= 'x'. - Obtención de los documentos del rango de
_id
'a' a 'z'.
Estas operaciones son los pilares de una base de datos, pero no le llevarán más lejos. ¿Qué pasa si necesita devolver un subconjunto de documentos que coincidan en campos dentro del documento? ¿La fecha de nacimiento de una persona? ¿El título de un libro? ¿El valor de un pedido?
Aquí entra la consulta.
IBM Cloudant tiene varios métodos para consultar datos. El primero que vamos a ver se denomina IBM Cloudant Query.
El lenguaje de IBM Cloudant Query se inspiró en el lenguaje de consulta MongoDB. Las consultas se expresan en JSON, donde el atributo selector
describe el subconjunto de datos que se va a devolver. El JSON de consulta se publica
en el punto final _find
de la base de datos para realizar una consulta.
La forma más sencilla de consulta consiste en encontrar documentos en los que un atributo tenga un valor fijo, por ejemplo, donde author == J Smith
.
El segundo ejemplo muestra dos cláusulas en la consulta. Ambas cláusulas deben cumplirse para que un documento se incluya en los resultados de la búsqueda, por ejemplo, cuando isbn === 6725252
Y date = 2018-01-01
.
En el tercer ejemplo, se muestra cómo se pueden añadir operadores lógicos. La operación $gt
significa greater than
(también puede utilizar gte
para mayor que o igual a, y lt/lte
para el equivalente
menor que los comparadores). El operador $or
es una operación OR
, por lo que un documento coincidente debe tener una fecha mayor que la de la consulta, ya sea el autor J Smith O bien el título Murder.
Si necesita acceder a objetos dentro de documentos, puede utilizar la notación de punto estándar, por ejemplo, address.zipcode
para acceder a una serie de código postal dentro de un objeto de dirección.
También podemos añadir los siguientes parámetros:
- Campos
- Especifica los atributos de documento que queremos que se devuelvan (el valor predeterminado es todo el documento).
- Ordenar
- Define cómo se van a ordenar los datos. Sort es una matriz, que permite calcular el orden de acuerdo con muchos atributos.
- Límite
- El número de documentos a devolver.
Si está acostumbrado a las bases de datos relacionales, esta consulta es la consulta SQL equivalente al último ejemplo de consulta de IBM Cloudant.
La cláusula WHERE
es el equivalente de SELECTOR
en la Consulta de IBM Cloudant. ORDER
y LIMIT
son exactamente equivalentes y la lista de Consulta de IBM Cloudant FIELDS
es equivalente
a la lista de atributos separados por comas después de la palabra clave SELECT
.
Acostumbrarse a la sintaxis de JSON puede costar un poco, pero es posible que los usuarios de MongoDB lo encuentren familiar.
Las consultas IBM Cloudant se pueden ejecutar en el panel de control de IBM Cloudant. Seleccione la base de datos con la que está trabajando, por ejemplo, books
y, a continuación, seleccione la pestaña Consulta.
Especifique el JSON de consulta de IBM Cloudant en el recuadro que se proporciona y pulse Ejecutar consulta cuando esté listo. El conjunto de resultados aparece en la página.
El botón Explicar se utiliza para proporcionar una explicación sobre cómo la base de datos interpreta la consulta proporcionada. Esta explicación resulta más importante cuando pasamos a la Indexación en la siguiente parte.
Las consultas también se pueden desencadenar desde curl. El JSON de consulta, en este caso, se almacena en un archivo y enviamos una solicitud POST
al punto final _find
utilizando la sintaxis -d@ command-line
.
El código Node.js es similar. La consulta es un objeto JavaScript estándar, que se pasa a la función db.find
que envía mediante POSTs
al punto final _find
por usted.
Ha llegado el momento para realizar un ejercicio práctico. Diseñe su propia IBM Cloudant Query que busque los títulos de los libros escritos en el siglo XX. La documentación de IBM Cloudant Query está en el URL que aparece en la pantalla por si la necesita.
Detenga la presentación aquí si no desea saber la respuesta...
Consulte una solución:
Uso el operador $and
para combinar dos cláusulas en el atributo de fecha. Una cláusula para localizar documentos cuya fecha es >= 1900
, la otra para encontrar documentos cuya fecha es < the year 2000
.
Ambas cláusulas tienen que ser verdaderas para seleccionar un documento. Como solo necesitamos el título de los libros que coincidan, podemos suministrar un atributo fields en lugar de que se devuelva el documento completo.
En resumen, IBM Cloudant Query es un lenguaje de consulta que se inspira en MongoDB y en el que la sintaxis se expresa en formato JSON.
Las consultas seleccionan subconjuntos de documentos de la base de datos utilizando cláusulas que operan en datos dentro del documento, no solo el _id
del documento.
Las consultas se envían al punto final _find
de la base de datos, ya sea mediante programación, curl o el panel de control.
El selector de la consulta decide qué parte de los datos es necesaria.
Aquí acaba esta parte. La siguiente parte se denomina Indexación.
Vídeo Indexación
Aprenda cómo la indexación puede agilizar el proceso de consulta.
Script de vídeo Indexación
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es parte la 11: Indexación.
Las consultas que ejecutamos en la parte anterior no eran óptimas: para obtener la respuesta, IBM Cloudant tenía que examinar todos los documentos de la base de datos uno por uno para ver si cumplían los criterios de búsqueda.
Para realizar consultas que se ejecutan de forma eficiente y escalable, necesitamos Indexación.
Con IBM Cloudant, puede especificar cualquier cantidad de Índices.
Un índice es una estructura de datos secundaria que se crea a partir de la lista de documentos. Contiene datos que están ordenados por los campos que usted especifique, por ejemplo, libros ordenados por fecha y por título. Si realiza una consulta que solicita datos que coincidan con la fecha y el título de un documento, la estructura de datos indexada se puede utilizar para acelerar el proceso de consulta. En lugar de examinar cada documento uno por uno, IBM Cloudant puede saltar a la parte correspondiente del índice (por ejemplo, la sección de libros del siglo XX) y recuperar los datos mucho más rápidamente.
Los índices de IBM Cloudant Query pueden ser de dos tipos: type=json
y type=text
. Estos índices están respaldados por dos tecnologías de indexación subyacentes que conoceremos en partes posteriores de este curso.
Un índice se define cuando se envía JSON mediante POST
a un punto final _index
de una base de datos.
El objeto index contiene una matriz de campos que especifica qué atributos de documento se deben indexar. Normalmente, los campos que necesitan indexación son equivalentes a los atributos utilizados en el selector
de una consulta
que se utilizará para recuperar los datos. Es decir, si queremos consultar por el campo de fecha, deberemos indexar el campo de fecha.
Aunque el name
de un índice es opcional, es recomendable usarlo y seguimos este convenio. Es conveniente formular una pregunta a IBM Cloudant y especificar el nombre del índice que se desea utilizar. Esta práctica evita a IBM
Cloudant tener que elegir qué índice utilizar de los disponibles, y facilita recordar qué índice es cada uno.
Vamos a crear un índice en nuestra base de datos books
desde el panel de control. Seleccione la base de datos y, a continuación, seleccione el separador Documentos de diseño e Índices de consulta en el menú.
Los índices existentes se enumeran al lado: Debe existir un índice special
que represente el índice primario, basado en el documento _id
.
Complete la definición del índice con el JSON:
Pulse Crear índice cuando haya terminado.
Al pulsar el botón se envía una solicitud POST
al punto final _index
(hay otras llamadas de API disponibles para actualizar y suprimir índices existentes).
Los índices se crean de forma asíncrona mediante IBM Cloudant en segundo plano. En el caso de bases de datos grandes, a IBM Cloudant le puede costar un poco crear el índice por primera vez. El índice no puede utilizar la base de datos hasta que la creación inicial haya finalizado.
Podemos repetir nuestra consulta de libros de el siglo XX. Esta vez especificamos el nombre de índice con el campo use_index
. Se devuelve la respuesta, esta vez basada nuestro índice. Es posible que no note una mejora de la velocidad
en el caso de base de datos pequeña, pero el beneficio se nota sin duda a medida que el tamaño de los datos y el volumen de consulta aumentan. La indexación permite mantener la eficacia de las consultas a medida que crece la aplicación.
Cuando se indica a IBM Cloudant que cree un índice secundario, inicia una tarea en segundo plano que examina todos los documentos uno por uno y crea una nueva estructura de datos en el disco: el índice. El índice es un árbol equilibrado que
empareja las claves (el atributo o atributos que necesita indexar) con el documento _id
del que proceden.
El índice puede utilizarse para buscar claves y rangos de claves conocidos sin tener que volver a explorar toda la base de datos.
Otro truco que se puede emplear en el índice de tiempo es el filtro parcial. Opcionalmente, se puede proporcionar un filtro parcial en la definición del índice. Este selector de IBM Cloudant Query se ejecuta en el momento de la indexación para decidir qué datos de los documentos se incluyen en índice y cuáles se pasan por alto.
En este ejemplo, se emplea un selector que permite incluir en el índice solo las fechas que caen en fin de semana. Los índices más pequeños son más rápidos y eficientes. Si tiene un caso de uso que solo necesite un subconjunto de los datos que se van a indexar, entonces un selector de filtro parcial en el momento de la indexación puede ayudar a que el índice sea más pequeño y más eficiente. Por ejemplo, es posible que desee indexar solo pedidos completados, solo cuentas caducadas o solo publicaciones de blog realizadas.
En resumen, el punto final _index
se utiliza para definir el índice y se puede aplicar un filtro parcial opcional en el momento de la consulta para crear índices más pequeños y dispersos.
Aquí acaba esta parte. La siguiente parte se denomina MapReduce.
Vídeo MapReduce
Obtenga más información sobre MapReduce, que es otra forma de configurar los índices secundarios.
Script de vídeo MapReduce
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 12: MapReduce.
Hemos visto cómo una combinación de los puntos finales _find
e _index
permite realizar consultas sobre el contenido de documentos JSON. Están respaldados por índices secundarios para escalar las consultas a medida
que la aplicación va creciendo.
En esta parte, presentamos otra forma de configurar los índices secundarios, que se conocen como MapReduce.
Antes, MapReduce era la única forma de configurar índices secundarios en CouchDB y sigue siendo una forma popular de consultar datos del cuerpo del documento.
Para crear un índice MapReduce, debe proporcionar a IBM Cloudant una función JavaScript encapsulada en un documento especial que se denomina documento de diseño. Los campos _id
de los documentos de diseño empiezan por _design/
por ejemplo, _design/mydesigndoc
.
Cuando IBM Cloudant recibe el documento de diseño, configura una tarea de indexación de en segundo plano, pasando cada documento de la base de datos a la función JavaScript uno por uno. Los pares clave-valor emitidos por la función JavaScript constituyen la base del índice que persiste.
Veamos algunos ejemplos de funciones JavaScript.
La función acepta un solo parámetro: el documento que el indexador pasa a IBM Cloudant. Cada vez que se emiten las llamadas de función, los parámetros que se pasan forman el par clave-valor del índice.
El primer ejemplo emite una clave de doc.name
, por lo que en este caso, se trata de un índice para búsquedas por el campo de nombre. El valor no contiene nada (es nulo).
En el segundo ejemplo, se preprocesan los datos antes de utilizar emit. Este proceso previo es una forma útil de ordenar series, recortar espacios en blanco, cambiar texto de mayúsculas a minúsculas y viceversa, aplicar valores predeterminados a los datos que faltan o restringir los valores a determinados rangos, etc.
En el tercer ejemplo, se añade lógica: solo se aplicarán al índice los documentos que estén published
. Esta lógica es equivalente al selector de filtro parcial que vimos con IBM Cloudant Consulta.
Los índices se crean de forma asíncrona y no se pueden utilizar hasta que se han creado por completo. Una vez creados, se pueden utilizar para la selección por clave, listas de claves, rangos de claves y agregación de datos. Por ejemplo, Buscar pedidos entre dos fechas y calcular el valor total de los pedidos, que se agrupan por mes.
IBM Cloudant incluye los cuatro reductores incorporados (o cinco si cuenta none
).
_count
- Para contar las cosas.
_sum
- Para la totalización de valores.
_stats
- Para proporcionar recuentos y totales adecuados para calcular medias, varianzas y desviaciones estándar.
_approx_count_distinct
- Para el recuento aproximado de valores únicos de la clave.
La función MAP
del documento de diseño se pasa a un doc
: la función se llama una vez por documento en la base de datos. Los pares de clave-valor que se emit
desde la función MAP
crean el
índice.
La KEY
es el elemento (o los elementos) en los que desea basar la select
(por ejemplo, la fecha).
El valor VALUE
es el elemento en el que se debe basar el informe (por ejemplo, total de ventas).
El Reductor es _sum
de modo que el VALUE
se totaliza para las claves coincidentes (por ejemplo, los pedidos de la misma fecha).
Vea cómo se define un MapReduce en el IBM Cloudant Dashboard.
Cuando se crea la vista MapReduce, se puede consultar para ver cada par KEY-VALUE
almacenado en el índice.
O, si el reductor está activada, el conjunto de resultados se puede agrupar por el valor de cada clave. En este caso, estamos totalizando las ventas de cada día.
En la vista se pueden consultar claves individuales (por ejemplo, ventas en una fecha específica), todas las claves o un rango de claves (por ejemplo, entre dos fechas).
Las vistas MapReduce se crean de forma asíncrona y pueden tardar un poco en estar listas para conjuntos de datos grandes.
Consulte algunas sugerencias:
Utilice la lógica en el JavaScript para incluir solo datos que tengan sentido, por ejemplo, totalizar solo los pedidos completados. Las claves indexadas no tienen que ser series. Un patrón común consiste en utilizar claves de matriz como,
por ejemplo, una matriz de año, mes o día. Estas claves de índice permiten la agrupación en el momento de la consulta por elementos de la matriz. Por ejemplo, puede agrupar pedidos por año, pedidos por año y mes o pedidos por año, mes y
día. Es ideal para informes de resumen que permiten al usuario desglosar los detalles. El valor puede ser una serie, un número o a veces un objeto pequeño que contiene un subconjunto del documento. Se puede el objeto en lugar de añadir include_docs=true
,
que también devolvería el cuerpo del documento en el conjunto de resultados.
En resumen, MapReduce es un medio de bajo nivel de definición de índices que permite la selección y la agregación de datos.
Utilice la lógica de JavaScript para decidir qué datos aplica al índice. Elija cómo se forma el índice emitiendo pares clave-valor.
Resuma los datos con los reductores incorporados. Obtenga informes concisos de montones de datos de forma eficiente.
MapReduce es ideal para consultas de contenedor modelo que la aplicación tiene que hacer una y otra vez. No resulta adecuado para consultas puntuales y ad hoc para la exploración de datos.
Aquí acaba esta parte. La siguiente parte se titula Fechas.
Vídeo Fechas
Obtenga más información sobre las distintas opciones para almacenar una fecha, o un valor de fecha y hora.
Script de vídeo Fechas
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 13: Fechas.
Hemos visto anteriormente en este curso que JSON solo modela de forma nativa series, números, valores booleanos, objetos y matrices. Un caso de uso común consiste almacenar un valor de fecha o de fecha y hora en una base de datos. Vea algunas ideas sobre cómo conseguirlo con IBM Cloudant.
El formato de serie ISO-8601 para representar una hora es el siguiente: y-m-dTh:m:s.msTIMEZONE
, es decir, año, mes, día, un carácter "T", hora, minuto, segundo, milisegundo y huso horario.
Siempre recomiendo almacenar fechas en el huso horario UTC aunque recopile datos de diferentes zonas geográficas. La fecha que se almacena en este formulario se puede transformar fácilmente en el huso horario local en el front-end. Por lo general, es importante almacenar los datos de cada usuario en las "mismas unidades".
Este formato de serie clasifica por orden de fecha y hora (porque las unidades de fecha más significativas están en la parte frontal de la serie) y se puede analizar fácilmente en funciones MapReduce.
Otra opción es almacenar el número de milisegundos desde 01-January-1970. Esta opción también es una forma estándar y legible por máquina de representar una fecha y hora.
También se puede analizar en funciones MapReduce y resulta útil para comparar dos fechas: solo se tiene que tomar una indicación de fecha y hora de otra.
En resumen, no existe ningún formato de fecha nativo en JSON, así que puedes almacenar fechas y horas como quieras. El formato ISO-8601 es compacto, legible y permite ordenar bien, al igual que una indicación de fecha y hora (milisegundos desde 1970).
Si necesita utilizar IBM Cloudant Query en una de las partes del componente, entonces se debería descomponer explícitamente en el documento.
Aquí acaba esta parte. La siguiente parte se denomina Réplica.
Vídeo Réplica
Aprenda lo qué significa la réplica en IBM Cloudant, así como los distintos tipos de réplica, y cómo funcionan.
Script de vídeo Réplica
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 14: Réplica.
La réplica es una característica principal de IBM Cloudant. Se trata de la transferencia de datos de una base de datos (el origen) a otra (el destino).
Las bases de datos de origen y destino pueden residir en el mismo servicio IBM Cloudant o estar separadas geográficamente, por ejemplo, una base de datos de EE. UU. IBM Cloudant que se replica en una en Europa.
El protocolo de réplica de IBM Cloudant se comparte con Apache CouchDB, por lo que las empresas que copian datos de una base de datos basada en la nube suelen utilizar la réplica en un CouchDB que se ejecuta en su propia ubicación.
PouchDB, un clon de CouchDB basado en JavaScript que se ejecuta en las pilas Node.js o en el navegador web, también se puede utilizar para replicar datos entre IBM Cloudant o CouchDB, ya sea de forma ascendente o descendente.
Las bibliotecas de IBM Cloudant Sync son aplicaciones nativas de iOS o Android que sincronizan datos con y desde un servicio IBM Cloudant.
La replicación es una operación unidireccional de origen a destino, que traslada todos los datos (eliminaciones, conflictos, archivos adjuntos, así como documentos) y puede activarse de dos maneras:
- Ejecutar hasta que todos los datos de la fuente alcancen el destino y luego parar.
- Igual que la anterior, pero la réplica se ejecuta continuamente sin parar, transfiriendo nuevos datos de la fuente al destino a medida que van llegando.
La réplica también se puede reanudar desde donde se detuvo por última vez. IBM Cloudant mantiene una nota de checkpoints
entre las partes de la réplica para permitir la reanudación de una réplica preexistente desde su última posición
conocida.
El panel de control de IBM Cloudant incluye un separador de réplica. Se inicia una réplica especificando las bases de datos de origen y de destino que incluyen credenciales de autenticación y si esta réplica es una operación única o continua.
También se puede indicar un nombre a una réplica, lo que resulta útil para realizar un seguimiento de qué trabajo de réplica es cada uno.
Ahora vamos a realizar un ejercicio práctico.
- Vaya al panel de control de IBM Cloudant.
- Cree una base de datos denominada
books2
. - Inicie una réplica continua de
books
abooks2
. - Acceda a la base de datos
books2
para comprobar que los documentos debooks
están ahora enbooks2
. - Añada un documento a la base de datos
books
. - Verifique que el cambio se haya incluido en la base de datos
books2
.
La réplica se puede utilizar para trasladar datos de una base de datos de IBM Cloudant a una instancia local de CouchDB. La réplica se puede controlar mediante IBM Cloudant o CouchDB. Por ejemplo, puede solicitar a IBM Cloudant que envíe sus cambios a CouchDB o puede solicitar a CouchDB que extraiga los cambios de IBM Cloudant. El controlador de réplica debe tener visibilidad de red de ambas API HTTP.
PouchDB también utiliza el mismo protocolo de réplica, por lo que se puede utilizar para transferir datos a y desde PouchDB y IBM Cloudant. Es muy probable que PouchDB sea el controlador de réplica en este caso.
PouchDB suele utilizarse para crear primeras aplicaciones fuera de línea. Estas aplicaciones recopilan datos incluso cuando no están conectadas a Internet, y luego escriben datos en IBM Cloudant cuando vuelven a estar en línea, lo que ofrece a sus usuarios un servicio siempre activo.
La réplica no siempre es necesaria. Si la aplicación necesita almacenar datos y luego escribirlos en IBM Cloudant posteriormente, la réplica no es estrictamente necesaria. Todo lo que se necesita es que los datos se almacenen en el dispositivo y se escriban de forma masiva en IBM Cloudant cuando se restaura la conexión.
Como la réplica es una operación unidireccional, si se necesita una configuración de tipo primario-primario entre dos instancias de IBM Cloudant de distintas regiones, se necesitan dos réplicas en direcciones opuestas.
Los cambios que se produzcan en Londres se envían a Dallas, y viceversa.
También se puede recurrir a topologías más complejas, con datos que fluyen en un anillo alrededor de un servicio de IBM Cloudant establecido.
En resumen, IBM Cloudant la réplica es un mecanismo para copiar datos de una base de datos de origen a una base de datos de destino.
Las réplicas pueden ser puntuales o continuas y, opcionalmente, se pueden filtrar con una función JavaScript o un selector de IBM Cloudant Query y se pueden reanudar desde donde se detuvo una réplica anterior.
Aquí acaba esta parte. La siguiente parte se denomina Bases de datos particionadas.
Vídeo Bases de datos particionadas
Descubra cómo funcionan las bases de datos particionadas en IBM Cloudant, cómo asignar documentos a fragmentos específicos y por qué las bases de datos particionadas mejoran el rendimiento, el coste y la escalabilidad.
Script de vídeo Bases de datos particionadas
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 15: Base de datos particionada.
IBM Cloudant es una base de datos distribuida, que es un concepto que trataremos próximamente. Muchos nodos de almacenamiento constituyen un servicio de IBM Cloudant y los documentos de una base de datos se distribuyen entre los nodos en grupos
denominados shards
. Se dice que una sola base de datos está sharded
o dividida en varias partes.
En una base de datos de IBM Cloudant normal, se asigna un fragmento a un documento de forma algorítmica; los documentos se distribuyen de manera efectiva en torno a los fragmentos aleatoriamente.
En una base de datos particionada, puede definir en qué fragmento se almacenan los documentos suministrando una clave de partición.
Las bases de datos particionadas no se crean con la misma llamada a la API PUT /<database name>
, sino con un parámetro de cadena de consulta adicional: partitioned=true
.
En el primer ejemplo, la base de datos de productos se crea como una base de datos particionada y, en el segundo ejemplo, como una base de datos no particionada estándar.
Al añadir documentos a una base de datos particionada, debe proporcionar un ID de documento (no existe ningún ID de documento generado automáticamente). Un _id
documento tiene dos partes, que están separadas por un carácter de
dos puntos:
- Clave de partición
- Una serie que define en qué partición almacenar el documento.
- Clave de documento
- Una serie que identifica de forma exclusiva un documento dentro de la partición.
En el primer ejemplo, se añade un libro a la partición book de la base de datos de productos.
Luego a se añade otro documento a la partición DVD y un tercero a la partición household.
Esto tiene como efecto que los documentos que comparten una clave de partición residen en el mismo fragmento de las bases de datos. Los documentos de la misma partición se almacenan conjuntamente por orden de clave de documento.
La ventaja se produce al recuperar los datos. Podemos dirigir consultas de IBM Cloudant, solicitudes MapReduce y búsquedas a una sola partición. En este ejemplo, se envía un selector de IBM Cloudant Query a la partición book
.
Esta acción significa que solo se utiliza una fracción de la infraestructura de IBM Cloudant (solo se utiliza el fragmento que aloja la partición book y el resto del clúster permanece desocupado).
Este escenario permite una mayor rapidez de las consultas, la reducción de los costes de las consultas y una mejor escalabilidad.
La clave para obtener un gran rendimiento de consulta particionada es la elección de la clave de partición:
Tiene que ser un valor que se repita dentro del conjunto de datos. Por ejemplo, existen varios elementos en la partición book
. Tiene que haber muchas particiones. Si solo tiene unas cuantas categorías, la categoría es una mala
elección para la clave de partición. Debe ser algo que tenga muchos valores, por ejemplo, deviceId
en una aplicación de IoT o orderId
en un sistema de comercio electrónico. Debe coincidir con las consultas que realiza
la aplicación. Si el caso de uso más común es la búsqueda en una categoría de productos, el particionamiento por categoría podría resultar adecuado. Evite las particiones en caliente; el tráfico debe distribuirse equitativamente entre las
particiones. Si es probable su elección de la clave de partición provoque un gran aumento del tráfico orientado a solo unas pocas particiones, significa que la elección de la clave de partición es inadecuada.
En resumen, las bases de datos particionadas se crean con el distintivo partitioned=true
y los documentos tienen un ID de dos partes donde la clave de partición y la clave de documento se unen con un carácter de dos puntos.
Los documentos de la misma partición se almacenan por orden de clave de documento en el mismo fragmento de base de datos. Conociendo este método de almacenamiento, podemos realizar consultas dirigidas a una sola partición que se ejecuta de manera más rápida y económica.
Todavía es posible realizar consultas entre particiones en una base de datos particionada. Al crear un índice secundario, debe elegir si su finalidad es para un ámbito por partición o global.
Aquí acaba esta parte. La siguiente parte se denomina IBM Cloudant Search.
Vídeo de IBM Cloudant Search
Aprenda a utilizar IBM Cloudant Search, así como el lenguaje de consulta Lucene y las creación de facetas.
Script de vídeo de IBM Cloudant Search
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 16: IBM Cloudant Search.
Tenemos otro método de consulta e indexación en IBM Cloudant que se conoce como IBM Cloudant Search y que abordaremos brevemente en esta parte.
IBM Cloudant Search se basa en otro proyecto de código abierto, Apache Lucene, que es la base de las funciones de búsqueda de muchos productos que incluyen Elasticsearch.
Se ha diseñado principalmente para la búsqueda de texto libre, donde los bloques de texto se procesan previamente antes de que se indexen: eliminación de casos, puntuación, palabras de ruido comunes y recorte de finales de palabras específicas del lenguaje común como, por ejemplo, granjero se convierte en granja y granjas se convierte en granjas.
Este procesamiento de textos se realiza mediante una selección de analizadores en el momento de la consulta, durante la búsqueda. Antes de este momento, también permite alguna funcionalidad de agregación que utiliza una técnica denominada creación de facetas.
Un índice de IBM Cloudant Search se crea proporcionando la función JavaScript. No es diferente a MapReduce, a excepción de que esta vez la función de emisión se sustituye por una función de índice, que espera el nombre del campo, los propios datos en y algunas opciones.
En este ejemplo, el nombre y el título del documento se indexan con las opciones predeterminadas. La categoría está designada para la creación de facetas (la funcionalidad de agregación) y el ISBN se almacena en el índice pero no se indexa
para la propia búsqueda. A veces resulta más eficaz almacenar algunos elementos en el índice que realizar include_docs=true
en el momento de la consulta.
Lucene tiene su propio lenguaje de consulta que crea consultas que coinciden con combinaciones de cláusulas con lógica, coincidencia difusa, rangos y potenciación de términos.
Consulte los ejemplos siguientes:
- Buscar documentos cuyo título coincida con
gastby
y cuyo autor empiece porfitz
. Observe el comodín de asterisco. - Buscar documentos cuyo autor (
author
) esté en el rangoausten to dickens
. En este ejemplo se muestra una consulta de rango en un campo de serie. - Buscar documentos cuyo precio sea
0 - 100
AND
cuyo año esté en el19th century
o cuyo autor coincida concharles dickens
. En este ejemplo se muestra cómo se puede crear una lógica en las consultas.
IBM Cloudant Search no solo resulta útil para la búsqueda de texto libre. También resulta útil cuando se sabe en qué atributos se basará la búsqueda, pero las consultas son variadas, con diferentes combinaciones de atributos cada vez. Esta flexibilidad es difícil de implementar con los índices de orden fijo de MapReduce.
El uso de facetas es una forma de agregación. Puede designar campos indexados individuales para crear facetas en el momento de la indexación y activar la agregación con parámetros en el momento de la consulta.
Tiene dos usos:
Contar los valores de repetición en el conjunto de resultados, como por ejemplo los recuentos de productos que pertenecen a cada categoría en un conjunto de resultados. O bien, contar números de elementos en rangos numéricos, como por ejemplo
los recuentos de productos en cada uno de los rangos de precios. Ambas formas de recuento se pueden presentar a un usuario de un front-end como un medio para filtrar adicionalmente una búsqueda existente para acotar el alcance de la búsqueda.
Por ejemplo, un cliente busca Fender
y luego pulsa Amplificadores (Amps) en un rango de precios inferior a 500$ (under $500
). Toda estas acciones de búsqueda y filtrado se pueden llevar a cabo mediante
IBM Cloudant Search.
En resumen, los índices de IBM Cloudant Search se definen con una función JavaScript proporcionada. Se basan en Apache Lucene y se utilizan principalmente para la coincidencia de búsqueda de texto libre, pero el lenguaje de consulta es útil para crear consultas flexibles en un conjunto fijo de campos indexados. Además, dispone de potentes agregaciones de recuento adecuadas para las interfaces de usuario detalladas.
IBM Cloudant Search también permite utilizar índices de IBM Cloudant Query type=text
, de manera que se obtiene un subconjunto de sus funciones utilizando la API _find
.
Aquí acaba esta parte. La siguiente parte se titula Las entrañas.
Vídeo Las entrañas
Descubra cómo se organiza el servicio IBM Cloudant.
Script de vídeo Las entrañas
Bienvenido al curso Introducción a IBM Cloudant, una serie de videos de 17 partes que le brinda una descripción general de la base de datos como servicio IBM Cloudant.
Este vídeo es la parte 17 - Bajo el capó.
Veamos cómo se organiza un servicio de IBM Cloudant: Esta visión general se aplica a los servicios de IBM Cloudant que se correlacionan con CouchDB 2 y 3. CouchDB 4 se basa en diferentes tecnologías.
IBM Cloudant es una base de datos distribuida con datos que se almacenan en torno a un clúster de nodos de almacenamiento. Imagínese el servicio de IBM Cloudant como un anillo de nodos, en este caso doce. Todos los nodos pueden gestionar llamadas de API entrantes y todos los nodos tienen la responsabilidad de almacenar algunos de los datos: fragmentos e índices secundarios asociados de bases de datos que existen en el clúster.
Cuando se graban datos en IBM Cloudant, uno de los nodos del anillo gestiona la solicitud: su tarea consiste en indicar que tres copias de los datos se deben almacenar en tres nodos de almacenamiento. Los datos se almacenan por triplicado en IBM Cloudant, por lo que cada fragmento de una base de datos se almacena varias veces, a menudo entre zonas de disponibilidad de una región.
Cuando se realiza una llamada a la API para escribir datos y obtener una respuesta, escribimos los datos en al menos dos de los tres nodos de almacenamiento. Los datos se desechan en el disco: no se almacenan en la memoria caché para ser datos desechados. Creemos que esta técnica es demasiado arriesgada y que puede ocasionar pérdida de datos.
Cuando se crea una base de datos, se crean varios fragmentos de base de datos (16 de forma predeterminada) que se distribuyen alrededor del clúster. Existen tres copias de cada fragmento, lo que equivale a 48 copias de fragmentos.
No se ve ninguna de estas. La actividad se maneja de forma transparente al crear una base de datos.
¿Qué ocurre si un nodo se desactiva o hay que rearrancarlo por motivos de mantenimiento? El resto del clúster sigue en funcionamiento normal. La mayoría de los fragmentos siguen teniendo tres copias de datos, pero algunos solo tienen dos. Las llamadas de API continúan funcionando con normalidad, solo se escriben dos copias de los datos.
Aunque dos nodos dejen de funcionar, la mayoría de los fragmentos siguen teniendo tres copias, algunos tienen dos y algunos tienen uno. Las grabaciones continúan funcionando, aunque el código de respuesta HTTP refleja que no se ha alcanzado el quórum de dos confirmaciones de nodo.
Ocurre lo mismo con las lecturas. El servicio continúa con un nodo anómalo. Podemos sobrevivir con un nodo anómalo...
O más nodos anómalos. Si existe una copia de cada nodo, la API sigue funcionando.
Cuando un nodo se recupera, captura los datos que faltan de los otros nodos sus compañeros y luego vuelve al servicio, gestionando las llamadas de la API y respondiendo a las consultas de datos.
La naturaleza de esta configuración es que IBM Cloudant presenta una coherencia eventual. Cualquier nodo puede gestionar una solicitud. Los datos se distribuyen por los nodos sin el tipo de bloqueo que puede verse en una base de datos relacional.
IBM Cloudant favorece la disponibilidad por encima de la coherencia: prefiere estar disponible y responder a llamadas de API que no estar disponible, porque en ese caso no puede ofrecer garantías de coherencia. (A menudo, una base de datos
relacional se configura de forma opuesta: funciona de forma coherente o no funciona en absoluto). El resultado de la eventual coherencia para un desarrollador es que la aplicación no debe read its writes
en un periodo de tiempo
breve. Puede existir una pequeña ventana de tiempo en la que es posible ver una versión más antigua de un documento que la que ha actualizado. Los datos acaban fluyendo en torno al clúster y, en la mayoría de los casos, el mecanismo de quórum
ofrecer la ilusión de coherencia, pero lo mejor es no depender de él.
En CouchDB 4, y en los servicios de IBM Cloudant basados en esa versión de código, se emplea un modelo de coherencia diferente.
Si su modelo de datos requiere actualizar un documento una y otra vez durante una breve ventana de tiempo, es posible que se acepten varias escrituras para el mismo número de revisión. Estas escrituras conducen a una ramificación en el árbol
de revisiones que se conoce como un conflicto. En este ejemplo, la revisión 2
se ha modificado de dos formas difusores, causando dos revisiones 3. Es posible resolver los conflictos mediante programación, pero deben evitarse
porque pueden causar problemas de rendimiento en circunstancias extremas.
Los conflictos también pueden ocurrir cuando se utiliza la réplica y se modifica un documento de diferentes maneras, y a continuación, las revisiones en conflicto se fusionan utilizando la réplica. IBM Cloudant no genera datos en este escenario.
Se elige una revisión winning
, pero se puede acceder a las revisiones no ganadoras y tu aplicación puede resolver el conflicto eligiendo un nuevo ganador, borrando las revisiones no deseadas o realizando cualquier acción que
necesites. Un conflicto no es una condición de error. Es un efecto secundario de tener copias desconectadas de datos que se pueden modificar sin bloqueo. IBM Cloudant elige manejar los conflictos sin descartar los cambios divergentes y,
en su lugar, los almacena como un conflicto.
Para comprobar los conflictos de un documento, añada ?conflicts=true
a la captación de un solo documento. Las revisiones en conflicto se listan en la matriz _conflicts
.
Las revisiones no deseadas se pueden eliminar utilizando la operación DELETE
normal, especificando la señal rev de la revisión que desea suprimir. La API masiva también es una buena opción para eliminar revisiones conflictivas,
incluso para eliminar varios conflictos del mismo documento.
Para resumir, IBM Cloudant es un servicio distribuido que almacena bases de datos, que se dividen en múltiples fragmentos, con tres copias de cada fragmento distribuidas alrededor de un anillo de nodos de almacenamiento. IBM Cloudant es coherente, pero favorece la alta disponibilidad por encima de una extrema coherencia.
Evite escribir en el mismo documento una y otra vez para no generar conflictos. Aunque a veces los conflictos son inevitables en situaciones de replicación.
Acepte la coherencia eventual: no intente hacer que IBM Cloudant sea coherente.
Los productos IBM Cloudant basados en CouchDB 4 pueden tener un modelo de coherencia diferente.
Aquí acaba este curso. Para obtener más información, consulte la documentación de IBM Cloudant y el blog.