IBM Cloud Docs
Usando o IBM Cloudant

Usando o IBM Cloudant

Se geralmente você nunca usa bancos de dados IBM Cloudant ou NoSQL, examine esta introdução e algumas melhores práticas antes de ler mais adiante. Elas descrevem as coisas mais importantes que você precisa saber sobre o IBM Cloudant e como usá-lo melhor. O resto da documentação supõe que você saiba esses princípios básicos.

É possível localizar mais informações sobre o IBM Cloudant nas seções a seguir:

Conectando-se ao IBM Cloudant

Para acessar o IBM Cloudant, deve-se ter uma conta da IBM Cloud®.

API HTTP

Todas as solicitações para o IBM Cloudant passam pela web. Essa instrução significa que qualquer sistema que possa falar com a web pode falar com o IBM Cloudant. Todas as bibliotecas específicas de linguagem para o IBM Cloudant são apenas wrappers que fornecem alguma conveniência e maneirismos linguísticos para ajudá-lo a trabalhar com uma API simples. Muitos usuários escolhem usar bibliotecas HTTP brutas para trabalhar com o IBM Cloudant.

Para obter mais informações sobre como o IBM Cloudant usa HTTP, consulte HTTP na referência de API.

O IBM Cloudant suporta os métodos de solicitação de HTTP a seguir:

GET
Solicitar o item especificado. Como com solicitações normais de HTTP, o formato da URL define o que é retornado. Com o IBM Cloudant, essa definição pode incluir itens estáticos, documentos do banco de dados e informações de configuração e estatística. Na maioria dos casos, as informações são retornadas na forma de um documento JSON.
HEAD
O método HEAD recupera o cabeçalho de HTTP de uma solicitação GET sem o corpo da resposta.
POST
Fazer upload de dados. Na API do IBM Cloudant, o método POST configura valores, faz upload de documentos, configura valores de documentos e inicia alguns comandos de administração.
PUT
Usado para "armazenar" um recurso específico. Na API do IBM Cloudant, PUT cria novos objetos, incluindo bancos de dados, documentos, visualizações e documentos de design.
DELETE
Exclui o recurso especificado, incluindo documentos, visualizações e documentos de design.
COPY
Um método especial que copia documentos e objetos.

Se o cliente (como alguns navegadores da web) não suportar o uso de métodos HTTP, o POST poderá ser usado como alternativa com o cabeçalho de solicitação X-HTTP-Method-Override configurado para o método HTTP real.

Erro de método não permitido

Se você usar um tipo de solicitação de HTTP não suportado com uma URL que não suporta o tipo especificado, um erro 405 será retornado. O erro que lista os métodos HTTP suportados, conforme mostrado no exemplo a seguir.

Mensagem de erro de exemplo em resposta a uma solicitação não suportada

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

JSON

O IBM Cloudant armazena documentos que usam codificação JSON (JavaScript Object Notation), portanto, qualquer coisa codificada em JSON pode ser armazenada como um documento. Os arquivos que incluem mídia, como imagens, vídeos e áudio, são chamados de BLOBs (objetos binários grandes). Os BLOBs podem ser armazenados como anexos associados a documentos.

Mais informações sobre JSON podem ser localizadas no Guia do JSON.

Sistemas distribuídos

Ao usar a API do IBM Cloudant, é possível interagir com uma colaboração de inúmeras máquinas, chamadas de cluster. As máquinas em um cluster devem estar no mesmo data center, mas podem estar dentro de diferentes "pods" nesse data center. Usar diferentes pods ajuda a melhorar as características de Alta Disponibilidade do IBM Cloudant.

Uma vantagem do armazenamento em cluster é que quando você precisa de mais capacidade de computação, você inclui mais máquinas. Esse método é geralmente de custo mais reduzido e tolerante a falhas do que o aumento de escala ou o aprimoramento de uma única máquina existente.

Para obter mais informações sobre o IBM Cloudant e os conceitos de sistema distribuído, veja o guia Teorema CAP.

Replicação

Replicação é um procedimento seguido por IBM Cloudant, CouchDB, de PouchDB, e outros bancos de dados distribuídos. A replicação sincroniza o estado de dois bancos de dados para que seus conteúdos sejam idênticos.

É possível replicar continuamente. Replicação contínua significa que um banco de dados de destino é atualizado toda vez que o banco de dados de origem muda. A replicação contínua pode ser usada para backups de dados, agregando dados em muitos bancos de dados, ou para compartilhamento de dados.

No entanto, replicação contínua significa testar continuamente por quaisquer mudanças do banco de dados de origem. Esse teste requer chamadas internas contínuas, que podem afetar o desempenho ou o custo de uso do banco de dados.

A replicação contínua pode resultar em muitas chamadas internas. Essas chamadas podem afetar os custos para usuários de diversos locatários de sistemas IBM Cloudant. A replicação contínua é desativada por padrão.

Usando a ferramenta adequada para a tarefa

O IBM Cloudant é um armazenamento de documentos JSON escalável, durável, altamente disponível e operacional com uma API de HTTP. Isso é adequado para os propósitos a seguir:

  • Potencializando o seu aplicativo sempre ativo.
  • Sendo o armazenamento de dados do lado do servidor para aplicativos móveis.
  • Armazenando dados de séries temporais em bancos de dados de prazo fechado antes de arquivar o armazenamento de objetos e excluir o original.
  • Armazenando objetos de aplicativos como JSON enquanto consultas são entregues por meio de índices secundários.
  • Replicando conjuntos de dados em geografias para a recuperação de desastres, a obtenção de capacidade adicional ou a movimentação de dados para mais perto dos usuários.

O IBM Cloudant não inclui os recursos a seguir:

Para obter mais informações, consulte o blog Melhores e piores práticas.

Organizando documentos e bancos de dados

Os dados do IBM Cloudant são organizados em uma hierarquia de bancos de dados e documentos. Um documento é um objeto JSON com um identificador exclusivo: seu _id. Um banco de dados é uma coleção de documentos com um índice primário que permite que eles sejam recuperados por _id. Ele também tem índices secundários opcionais que permitem que os documentos sejam consultados por outros atributos no objeto.

Quando os desenvolvedores iniciam um projeto, às vezes, eles se deparam com as perguntas a seguir:

  • Quantos dados é possível colocar em um único objeto?
  • Devo armazenar diferentes tipos de documentos na mesma coleção ou em um banco de dados por tipo de documento?

É importante que um documento inclua todos os dados sobre um objeto modelado por seu aplicativo, por exemplo, um usuário, uma solicitação ou um produto. Esta prática garante buscar o objeto inteiro por meio do banco de dados em uma chamada de API. O IBM Cloudant não tem o conceito de junções como um banco de dados relacional, então os dados não são normalizados. No entanto, os dados podem se repetir nos objetos. Por exemplo, um documento de pedido pode incluir um subconjunto dos documentos do produto que foram comprados.

É comum armazenar vários tipos de objetos no mesmo banco de dados: uma convenção é que um atributo type é usado para denotar o tipo de objeto. Essa será uma boa opção se for necessário executar consultas que retornam vários tipos de objetos ou se um banco de dados precisar ser replicado em outro local por completo. Caso contrário, bancos de dados separados, por exemplo, users, orders, products, podem ser melhores para que os índices secundários sejam específicos para cada tipo de objeto.

Se você estiver armazenando matrizes de objetos em um documento, considere se os itens da matriz realmente devem ser o próprio documento delas. Por exemplo, um produto e cada revisão de produto devem ser armazenados em documentos separados, mas um usuário e cada um dos pedidos desse usuário devem ter seus próprios documentos.

Você provavelmente não desejará armazenar dados em um banco de dados único e em constante crescimento se tiver um conjunto de dados em constante crescimento. Os dados são mais bem armazenados em bancos de dados de prazo fechado que permitem que dados mais antigos sejam arquivados e excluídos de forma limpa. A exclusão de um documento do IBM Cloudant deixa um documento tombstone para trás, portanto, não dependa da exclusão de documentos para recuperar espaço em disco. Em vez disso, deve-se confiar na exclusão de bancos de dados inteiros.

O JSON não oferece uma maneira nativa de armazenar datas ou registros de data e hora. Escolha seu formato de data com cuidado se quiser consultá-lo posteriormente.

O tamanho máximo dos documentos é de 1 MB, mas eles devem ser muito menores do que isso, tendo geralmente alguns KB.

Para obter mais informações, consulte as postagens do blog a seguir:

Aproveitando ao máximo o índice primário

O IBM Cloudant tem um índice primário no atributo _id do documento. Este índice permite que os documentos sejam recuperados por _id (GET /db/id) ou uma faixa de _ids (GET /db/_all_docs?startkey="a"&endkey="z"). Ao armazenar dados na chave primária e garantir que cada _id seja único, o índice primário pode ser usado para buscar documentos e intervalos de documentos sem indexação secundária. Consulte a lista de ideias a seguir:

  • Se você tiver algo exclusivo em seu objeto que seja útil consultar, use-o como o campo _id, por exemplo, bob.smith@gmail.com, isbn9780241265543 ou oakland,ca.
  • Se seus objetos contiverem uma hierarquia, modele-a em seu _id: usa:ca:oakland ou books:fiction:9780241265543. A hierarquia vai da maior para a menor, então é possível usar o índice primário para localizar todas as cidades nos usa ou todas as cidades nos usa:ca, sem indexação secundária.
  • Se você estiver armazenando dados de séries temporais, o tempo de codificação no início de seu _id classificará o índice primário por tempo, por exemplo, 001j40Ox1b2c1B2ubbtm4CsuLB4L35wQ.
  • Documentos de grupo de bancos de dados particionados que compartilham uma chave de partição juntos. Uma chave da partição deve ter muitos valores e não deve incluir pontos de acesso para evitar direcionar uma grande parte do tráfego do seu aplicativo para algumas partições.

Para obter mais informações, consulte as postagens do blog a seguir:

Índices de consulta e secundários

O IBM Cloudant permite que as consultas sejam executadas com relação a um único banco de dados que retorna uma matriz de documentos correspondentes e um marcador, que permite o acesso ao próximo bloco de resultados da procura. Alcançar um melhor desempenho de consulta depende de ter suas consultas suportadas por índices secundários adequados. Um índice permite que o banco de dados responda a uma consulta sem ter de percorrer cada documento no banco de dados, o que oferece um desempenho muito mais rápido.

Consulte as dicas a seguir:

  • Às vezes, é difícil mensurar o desempenho de suas consultas até que seu conjunto de dados seja grande o suficiente para expor operações lentas. Gere dados realistas o bastante para que seja possível testar o desempenho da indexação e da consulta antes da chegada à produção.
  • O IBM Cloudant pode retornar dados sem um índice, mas você nunca deve contar com esses dados para cargas de trabalho de produção. Se o seu conjunto de resultados inclui o aviso, No matching index found. Create an index to optimize query time, você precisa revisitar sua estratégia de indexação. Use o recurso explicar para ver qual índice está sendo selecionado para cada consulta.
  • Com vários tipos de objetos no mesmo banco de dados, muitos casos de uso podem ser atendidos por alguns índices em atributos fixos. Para obter mais informações, consulte Indexação ideal do IBM Cloudant.
  • Dê aos seus índices nomes significativos e especifique o nome do índice no tempo de consulta, de modo que seja óbvio qual índice corresponde a qual consulta de seu aplicativo.

Para obter mais informações, consulte as postagens do blog a seguir: