IBM Cloud Docs
Utilización de IBM Cloudant

Utilización de IBM Cloudant

Si nunca utiliza bases de datos IBM Cloudant o NoSQL en general, examine esta introducción y algunas prácticas recomendadas antes seguir leyendo. Se describe lo más importante que necesita saber acerca de IBM Cloudant y cómo utilizarlo de la mejor manera posible. En el resto de la documentación se da por supuesto que conoce estos conceptos.

Encontrará más información sobre IBM Cloudant en las secciones siguientes:

Conexión a IBM Cloudant

Para acceder a IBM Cloudant, debe tener una cuenta de IBM Cloud®.

API HTTP

Todas las solicitudes destinadas a IBM Cloudant pasan por la web. Esta declaración significa que cualquier sistema que se puede comunicar con la web, se puede comunicar con IBM Cloudant. Todas las bibliotecas específicas de lenguaje para IBM Cloudant son derivadores que proporcionan comodidad y sutilezas lingüísticas que le ayudarán a trabajar con una simple API. Muchos usuarios optan por utilizar directamente bibliotecas HTTP para trabajar con IBM Cloudant.

Para obtener más información sobre el modo en que IBM Cloudant utiliza HTTP, consulte HTTP en la referencia de API.

IBM Cloudant admite los siguientes métodos de solicitud HTTP:

GET
Solicitar el elemento especificado. Al igual que sucede con las solicitudes HTTP normales, el formato del URL define lo que se devuelve. Con IBM Cloudant, esta definición puede incluir elementos estáticos, documentos de base de datos e información sobre configuración y estadísticas. En la mayoría de los casos, la información se devuelve en forma de documento JSON.
HEAD
El método HEAD recupera la cabecera HTTP de una solicitud GET sin el cuerpo de la respuesta.
POST
Cargar datos. En la API de IBM Cloudant, el método POST establece valores, descarga documentos, establece valores de documento e inicia algunos mandatos de administración.
PUT
Se utiliza para "almacenar" un recurso específico. En la API de IBM Cloudant, PUT crea objetos nuevos, incluidos documentos, bases de datos, vistas y documentos de diseño.
DELETE
Suprime el recurso especificado, incluidos documentos, vistas y documentos de diseño.
COPY
Un método especial que copia documentos y objetos.

Si el cliente (como algunos navegadores web) no admite el uso de métodos HTTP, se puede utilizar POST en su lugar con la cabecera de solicitud X-HTTP-Method-Override establecida en el método HTTP real.

Error Método no permitido

Si utiliza un tipo de solicitud HTTP no soportado con un URL que no da soporte al tipo especificado, se devuelve un error 405 . El error que lista los métodos HTTP soportados, tal como se muestra en el ejemplo siguiente.

Ejemplo de mensaje de error en respuesta a una solicitud no admitida

{
    "error":"method_not_allowed",
    "reason":"Only GET,HEAD allowed"
}

JSON

IBM Cloudant almacena los documentos que utilizan la codificación JSON (JavaScript Object Notation), de forma que cualquier cosa codificada en JSON se puede almacenar como un documento. Los archivos que incluyen medios, como imágenes, vídeos y audio, se denominan BLOB (objeto binario grande). Los BLOB se pueden almacenar como archivos adjuntos asociados con documentos.

Encontrará más información sobre JSON en la Guía de JSON.

Sistemas distribuidos

Mediante la API de IBM Cloudant puede interactuar con una colaboración de varias máquinas, lo que se denomina clúster. Las máquinas de un clúster deben estar en el mismo centro de datos, pero pueden estar en distintos "pods" en dicho centro de datos. El uso de distintos pods ayuda a mejorar las características de alta disponibilidad de IBM Cloudant.

Una ventaja del uso de clústeres es que cuando se necesita más capacidad de cálculo se puede añadir más máquinas. Este suele ser un método más rentable y con mayor tolerancia de errores que aumentar la capacidad o mejorar una sola máquina existente.

Para obtener información sobre IBM Cloudant y los conceptos del sistema distribuido, consulte la guía CAP Theorem.

Réplica

Réplica es un procedimiento seguido por IBM Cloudant, CouchDB, PouchDBy otras bases de datos distribuidas. La réplica sincroniza el estado de dos bases de datos para que su contenido sea idéntico.

Puede replicar continuamente. La réplica continua significa que una base de datos de destino se actualiza cada vez que cambia la base de datos de origen. La réplica continua se puede utilizar para copias de seguridad de datos, para agregar datos entre varias bases de datos o para compartir datos.

Sin embargo, la réplica continua implica comprobar continuamente si la base de datos de origen se ha modificado. Esta comprobación requiere constantes llamadas internas, lo que puede afectar el rendimiento o al coste de utilizar la base de datos.

La réplica continua puede provocar que se realicen muchas llamadas internas. Estas llamadas podrían afectar a los costes para los usuarios multiarrendatarios de sistemas IBM Cloudant. La réplica continua está inhabilitada de forma predeterminada.

Uso de la herramienta adecuada para el trabajo

IBM Cloudant es un almacén de documentos JSON operativo, de alta disponibilidad, escalable y duradero con una API HTTP. Es adecuado para los siguientes fines:

  • Servir de base a la aplicación web siempre activa.
  • Ser el almacén de datos del lado del servidor para aplicaciones móviles.
  • Almacenar datos de series temporales en bases de datos de tiempo fijo antes de archivar en el almacenamiento de objetos y suprimir el original.
  • Almacenar objetos de aplicación como JSON al entregar consultas de índices secundarios.
  • Replicar conjuntos de datos en geografías para la recuperación tras desastre, capacidad adicional o traslado de datos más cerca de los usuarios.

IBM Cloudant no incluye las características siguientes:

Para obtener más información, consulte el blog Prácticas recomendadas y no recomendadas.

Organización de documentos y bases de datos

Los datos de IBM Cloudant están organizados en una jerarquía de bases de datos y documentos. Un documento es un objeto JSON con un identificador exclusivo: su _id. Una base de datos es una recopilación de documentos, con un índice primario que permite recuperar documentos mediante _id. También tiene índices secundarios opcionales que permiten consultar documentos mediante otros atributos del objeto.

Cuando los desarrolladores inician un proyecto, a veces se enfrentan a las siguientes preguntas:

  • ¿Cuántos datos puedo colocar en un solo objeto?
  • ¿Debo almacenar distintos tipos de documento en la misma recopilación o una base de datos por tipo de documento?

Es importante que un documento incluya todos los datos sobre un objeto modelado por la aplicación, por ejemplo, un usuario, un pedido o un producto. Esta práctica asegura que obtiene el objeto completo de la base de datos en una llamada de API. IBM Cloudant no tiene el concepto de uniones como en una base de datos relacional, por lo que los datos no se normalizan. Sin embargo, los datos pueden repetirse entre los objetos. Por ejemplo, un documento de pedido puede incluir un subconjunto de los documentos de producto que se han adquirido.

Es habitual almacenar varios tipos de objeto en la misma base de datos: una convención es que se utiliza un atributo type para indicar el tipo de objeto. Se trata de una buena opción si necesita realizar consultas que devuelven varios tipos de objeto o si una base de datos debe replicarse en otra ubicación. De lo contrario, las bases de datos independientes, por ejemplo, users, orders, products, pueden ser una mejor opción, de modo que los índices secundarios sean específicos para cada tipo de objeto.

Si almacena matrices de objetos dentro de un documento, tenga en cuenta si los elementos de la matriz deben ser su propio documento. Por ejemplo, un producto y cada revisión de producto se debe almacenar en documentos independientes, pero un usuario y cada uno de esos pedidos de usuario deben tener su propio documento.

Si tiene un conjunto de datos cada vez mayor, probablemente no desee almacenar datos en una única base de datos cada vez mayor. Los datos se almacenan mejor en bases de datos de tiempo fijo que permiten archivar y suprimir los datos antiguos sin problemas. La supresión de un documento de IBM Cloudant deja un documento de marcador de exclusión (tombstone), así que no cuente con la supresión de documentos para recuperar espacio de disco. En su lugar, debe suprimir bases de datos completas.

JSON no ofrece una forma nativa de almacenar fechas o indicaciones de fecha y hora. Elija detenidamente el formato de fecha si tiene la intención de consultarlas más tarde.

El tamaño máximo de documento es 1 MB, pero los documentos deben ser mucho más pequeños, normalmente unos cuantos KB.

Para obtener más información, consulte las siguientes publicaciones de blog:

Cómo aprovechar al máximo el índice primario

IBM Cloudant tiene un índice primario en el atributo _id del documento. Este índice permite que _id recupere documentos (GET /db/id) o un rango de _ids (GET /db/_all_docs?startkey="a"&endkey="z"). Al almacenar datos en la clave primaria y asegurarse de que cada _id es exclusivo, el índice primario se puede utilizar para captar documentos y rangos de documentos sin indexación secundaria. Consulte la siguiente lista de ideas:

  • Si tiene algún elemento exclusivo en el objeto que sería útil para realizar una consulta, utilícelo como campo _id; por ejemplo, bob.smith@gmail.com, isbn9780241265543 u oakland,ca.
  • Si los objetos contienen una jerarquía, muéstrela como modelo en _id: usa:ca:oakland o books:fiction:9780241265543. La jerarquía va de más grande a más pequeño, de modo que puede utilizar el índice primario para buscar todas las ciudades de usa o todas las ciudades de usa:ca, sin indexación secundaria.
  • Si va a almacenar datos de series temporales, codificar la hora al principio del _id ordena el índice primario por tiempo, por ejemplo, 001j40Ox1b2c1B2ubbtm4CsuLB4L35wQ.
  • Las bases de datos particionadas agrupan los documentos que comparten una clave de partición. Una clave de partición debe tener muchos valores y no debe incluir zonas activas para evitar dirigir una gran parte del tráfico de la aplicación a pocas particiones.

Para obtener más información, consulte las siguientes publicaciones de blog:

Consultas e índices secundarios

IBM Cloudant permite ejecutar consultas en una única base de datos que devuelve una matriz de documentos coincidentes y un marcador, que permite el acceso al siguiente bloque de resultados de búsqueda. Lograr un mejor rendimiento de consulta depende de que las consultas reciban soporte de los índices secundarios adecuados. Un índice permite que la base de datos responda a una consulta sin tener que buscar en cada documento en la base de datos, lo que produce un rendimiento mucho más rápido.

Consulte los consejos siguientes:

  • A veces es difícil medir el rendimiento de las consultas hasta que el conjunto de datos es lo suficientemente grande como para mostrar las operaciones lentas. Genere suficientes datos realistas para poder probar la indexación y el rendimiento de la consulta antes de pasar a producción.
  • IBM Cloudant podría devolver datos sin un índice, pero no debe utilizarlos para cargas de trabajo de producción. Si el conjunto de resultados incluye el aviso, No matching index found. Create an index to optimize query time, deberá revisar la estrategia de indexación. Utilice la característica explain para ver qué índice se selecciona para cada consulta.
  • Con varios tipos de objeto en la misma base de datos, se pueden atender muchos casos de uso con pocos índices con atributos fijos. Para obtener más información, consulte Indexación óptima de IBM Cloudant.
  • Dé a sus índices nombres significativos y especifique el nombre del índice en el momento de la consulta, de modo que sea obvio qué índice corresponde a cada consulta de la aplicación.

Para obtener más información, consulte las siguientes publicaciones de blog: