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 solicitudGET
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:
- Latencia baja, almacén de datos en memoria. Para obtener más información, consulte IBM Cloud® Databases for Redis.
- Almacén de objetos sin límites para archivar datos. Para obtener más información, consulte IBM Cloud Object Storage.
- Base de datos relacional con consultas SQL, procedimientos almacenados y restricciones y desencadenantes. Para obtener más información, consulte IBM Cloud Databases for PostgreSQL.
- Depósito de datos para consultas ad hoc. Para obtener más información, consulte IBM® Db2® Warehouse as a Service.
- Una cola. Para obtener más información, consulte IBM MQ.
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
uoakland,ca
. - Si los objetos contienen una jerarquía, muéstrela como modelo en
_id
:usa:ca:oakland
obooks: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 deusa
o todas las ciudades deusa: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: