Couchbase 101-102-103 (Série 1)

Recentemente, iniciamos uma série de webinars on-line para abordar os principais componentes do Couchbase Server, desde a instalação até a configuração para desenvolvimento e compreensão da indexação. Várias perguntas surgiram durante os webinars e estou publicando aqui as perguntas e respostas por escrito.

Meu gerador de carga baseado em Ruby pode ser baixado aqui: https://github.com/scalabl3/ruby-couchbase-loadgen

Couchbase 101 - Instalação e configuração

P: Quando você adiciona um servidor, ele é fragmentado?

R: Sim, usamos "Hash Sharding" para todos os dados, o que significa que, para cada par chave-valor, fazemos o hash da chave da cadeia de caracteres para obter o número da partição (um contêiner lógico) em que ela deve estar. Procuramos o número da partição no mapa do cluster para ver onde essa partição está localizada no cluster do Couchbase e, em seguida, fazemos CRUD diretamente com o nó do Couchbase responsável por essa partição. Quando você adiciona um novo servidor (ou mais de um), estamos simplesmente redistribuindo as partições uniformemente entre o novo número de nós.

P: É necessário adicionar servidores apenas para a réplica?

R: As réplicas, para serem eficazes em uma situação de failover, precisam estar localizadas em nós diferentes para que os nós possam sofrer "failover". Para uma réplica, é necessário que haja pelo menos dois nós do Couchbase. Para duas réplicas, é necessário que haja pelo menos três nós do Couchbase e, para três réplicas, é necessário que haja pelo menos quatro nós do Couchbase. É claro que o aumento do número de réplicas também aumenta a necessidade de recursos maiores para um desempenho ideal.

P: Todos os documentos com o mesmo valor de hash são armazenados na mesma partição?

R: Sim, nossa função de hash está simplesmente transformando uma chave de cadeia de caracteres em um número de [0...1023], todas as chaves que fazem hash para o número 2 residirão no contêiner de partição #2. Essa partição residirá em um nó específico do Couchbase no cluster. Se você adicionar mais servidores e fizer o rebalanceamento, essa partição poderá ser movida para outro servidor, mas sempre haverá apenas um nó que será o "mestre" dessa partição. A "réplica" dessa partição viverá, obviamente, em um nó separado.

P: Em seu exemplo de escala horizontal, o total de partições é sempre 1024. 1024 é o máximo de partições em um cluster?

R: Ao conhecer nosso esquema de fragmentação e distribuição, muitos desenvolvedores consideram esse número como um botão a ser ajustado, naturalmente, já que todos nós somos consertadores. Entretanto, o número de partições não altera as características de desempenho. Acreditamos que 1024 é um bom número de partições para a distribuição uniforme dos dados, não é algo que precise ser alterado e não é um parâmetro de configuração. O número poderia facilmente ser 10.000 ou 990, e isso não alteraria a arquitetura de como distribuímos os dados (apenas aumentaria ou reduziria o número de arquivos de dados).

P: Quantos Buckets podem ser instalados em uma única máquina virtual?

R: É difícil dar uma regra geral para essa pergunta, pois os recursos alocados para essa máquina virtual podem variar muito, mas, em geral, para uma máquina de tamanho considerável com mais de 8 núcleos, é possível ter cerca de 10 a 12 Buckets. Para cada bucket, alocamos recursos para gerenciar e monitorar, portanto, ter um grande número de buckets aumenta a sobrecarga da CPU e, em geral, não é recomendado.

P: O rebalanceamento dos nós tem algum efeito sobre a eficiência do Couchbase?

R: Priorizamos as operações primárias em relação às operações de rebalanceamento no Couchbase, mas, dito isso, há um aumento do tráfego de CPU e de rede entre os nós do Couchbase durante um rebalanceamento. É recomendável fazer o rebalanceamento em horários fora do pico de uso, é claro, o mesmo vale para fazer backups, como em qualquer outro sistema. Fazer um rebalanceamento em horários de pico de uso certamente tornará o tempo de rebalanceamento mais lento se o uso de pico for muito intenso.

P: Quando você faz o rebalanceamento, as partições são realmente movidas para outro nó ou são duplicadas?

R: Eles são copiados até que o rebalanceamento seja concluído, caso ocorra uma falha durante o rebalanceamento. O nó mestre original continua sendo o nó mestre até que o rebalanceamento seja totalmente concluído. Após a conclusão do rebalanceamento, o novo nó mestre dessa partição se torna o mestre e o antigo remove seus dados, e os mapas do cluster são atualizados de acordo com o cluster e, em seguida, com o sdk do cliente.

P: Quais ferramentas estão disponíveis para backup/restauração e para ajudar na recuperação de desastres?

R: Temos as ferramentas de linha de comando cbbackup e cbrestore apenas para essa finalidade; você pode ler sobre elas aqui: http://www.couchbase.com/docs//couchbase-manual-2.0/couchbase-backup-restore-backup-cbbackup.html

Couchbase 102 - Desenvolvimento

P: O que acontece quando estamos armazenando imagens no Couchbase? 

R: Você pode armazenar imagens de duas maneiras diferentes com o Couchbase: uma é armazenar dados binários diretos como um valor de documento. A segunda opção é armazená-las como bases64 pré-codificadas em um documento JSON, ou seja, é um documento JSON padrão com uma ou mais imagens codificadas como valores JSON (com chaves JSON). A vantagem de armazenamento de imagens no Couchbase é que ele será servido a partir da RAM em vez do disco, portanto, terá um ótimo desempenho. Junte isso ao XDCR (Cross Data Center Replication) e você poderá criar sua própria CDN para imagens!

P: Como modificar/atualizar vários documentos e reverter se ocorrer um erro em um deles?

R: No Couchbase, você pode usar facilmente a simultaneidade otimista (CAS) ou pessimista (Lock) para transações em único documentos, mas para vários documentos em uma única "transação", será necessário usar o que é chamado de Two-Phase Commit. Você pode ler mais sobre isso aqui: http://www.couchbase.com/docs/couchbase-devguide-2.0/two-phase-commits.html

P: Existe a possibilidade de transações no Couchbase?

R: Como na pergunta anterior, você pode facilmente fazer transações de documento único usando a concorrência otimista com (CAS - Compare and Swap) ou Get and Lock.

P: Existe uma operação de inserção/atualização em lote que poderia chamar de volta uma lista de inserções/atualizações com falha após a gravação no disco primário?

R: Em alguns SDKs (Python, por exemplo), eles têm operações de tipo com vários conjuntos (todos eles têm operações com vários get), mas não acredito que suportemos operações de tipo com vários conjuntos E observação.

P: Como posso fazer uma consulta com vários parâmetros para passar, como nome, data e status? algo como um "where" no SQL?

R: Isso é feito com nossas visualizações (índices). A consulta de vários parâmetros pode exigir: a) a consulta de visualizações separadas e a realização de uma interseção dentro do aplicativo ou a criatividade com a chave do índice para que você possa fazer a consulta por intervalo. Há várias estratégias diferentes para isso, e a resposta será dada de forma sucinta, dependendo do caso de uso e do design do documento.

P: Vocês oferecem suporte a outras linguagens, como Go ou Clojure?

R: Sim! Temos edições comunitárias para Go (https://github.com/dustin/go-couchbase), você pode ver todos os clientes da comunidade em nossa página Todos os clientes em couchbsae.com: http://www.couchbase.com/communities/all-client-libraries As bibliotecas de clientes da comunidade não são oficialmente suportadas por nossos contratos de suporte, mas você pode encontrar facilmente ajuda de nossos engenheiros via IRC ou Twitter.

P: Os padrões-chave são mais rápidos do que as visualizações?

R: Na maioria dos casos em que você pode usar Key Patterns, sim, porque são operações binárias que saem do cache da RAM, mas nem tudo pode ser modelado usando Key Patterns. Nesses casos, é aí que nossas visualizações (índices) são úteis e também nossa integração com o Elastic Search.

Couchbase 103 - Visualizações, indexação e consulta

P: Os índices são mantidos na memória?

R: Não, todos os índices (assim como outros sistemas de indexação em outros bancos de dados) são criados e consultados no disco. O sistema operacional utilizará a RAM para o cache do sistema de arquivos, o que melhorará consideravelmente o desempenho da consulta ao índice. É por isso que deixamos uma boa parte da RAM para o sistema operacional fazer isso (40% de RAM disponível).

P: Os índices são distribuídos automaticamente em vários nós? Você pode colocar índices somente em determinados nós por motivos de desempenho? Por exemplo, se você tivesse uma operação pesada de consulta/índice que não quisesse afetar vários nós.  

R: Cada nó do Couchbase mantém índices para as partições mestre/ativas que residem nele (para as quais ele é o "mestre"). Como os dados são distribuídos uniformemente devido ao nosso Hash sharding de chaves para partições, você não poderá ter índices somente em determinados nós sem um índice incompleto. No entanto, dito isso, você pode empregar uma estratégia diferente de ter um cluster inteiro separado que esteja na extremidade receptora de um XDCR (Cross Data Center Replication) unidirecional que esteja recebendo documentos do seu armazenamento de dados primário (apenas recebendo, não usados para criação ou atualização de dados) que podem ser usados para indexação e consulta pesadas e completamente otimizados para essa finalidade.

P: É possível ocultar o meta.id de uma determinada visualização no nível da interface? Você simplesmente o elimina dos parâmetros da função map? Quando você estiver usando um site, por exemplo, e um cliente estiver consultando o banco de dados, e você não quiser mostrar o meta.id?

R: Não, todas as chaves de documento (ids) são incluídas no conjunto de resultados em JSON para o documento que gerou essa "linha" de resultado (na verdade, um item de matriz na matriz de resultados). Deixar isso de fora da função map não muda isso. O que você pode fazer para resolver o segundo caso é não fazer com que o javascript da sua página da Web consulte o Couchbase diretamente (o que eu não recomendaria, pois isso significa que o servidor do Couchbase está exposto, assim como qualquer banco de dados que normalmente não é exposto ao público). Em vez disso, você pode executar a consulta por meio de sua própria API e filtrar o conjunto de resultados para não ter ids de documentos (meta.id).

P: Ao consultar uma exibição com salto, o tempo de resposta parece proporcional ao tamanho do salto. Isso é esperado?

R: Na verdade, é melhor usar um par de parâmetros em vez de usar skip, startkey e startkey_docid para percorrer a página. Os resultados são classificados primeiro por startkey (sua chave de índice) e, em seguida, se houver várias chaves de índice idênticas no conjunto de resultados, serão classificados por startkey_docid. O motivo para usar esse método é duplo: o primeiro é que ele evita o problema do tempo de resposta, que também piora à medida que o cluster cresce, pois a coleta dispersa será afetada pelo pulo - quanto mais nós, mais tempo leva para pular em cada nó, pois as consultas estão espalhadas pelo cluster. Em segundo lugar, seu conjunto de resultados mudará quando o índice for atualizado, portanto, o "pular" não pulará exatamente o mesmo após a primeira consulta.

Obrigado pela leitura!

Jasdeep Jaitla
jasdeep@couchbase.com
@scalabl3