Em nossa série de treinamentos contínuos, várias perguntas surgem a cada vez, e eu as relaciono com suas respectivas respostas abaixo!
Couchbase 101 - Arquitetura, instalação e configuração
Meu gerador de carga baseado em Ruby pode ser baixado aqui: https://github.com/scalabl3/ruby-couchbase-loadgen
P: Estamos usando a versão 2.0 na produção, qual é a melhor prática para atualizar para a versão 2.2?
R: Você pode atualizar seu cluster de três maneiras diferentes. A primeira é a atualização on-line do rebalanceamento de swap e é uma ótima maneira de manter o tempo de atividade do cluster e, ao mesmo tempo, fazer a atualização. Para fazer um rebalanceamento de swap, você adiciona um número igual de novos nós que executam o Couchbase 2.2 ao tamanho atual do cluster, mas, antes do rebalanceamento, remove os nós do Couchbase 2.0. Ao fazer o rebalanceamento, como você está adicionando e removendo o mesmo número de nós, isso será o mais eficiente. Leia mais sobre isso aqui: http://docs.couchbase.com/couchbase-manual-2.0/#swap-rebalance Você também pode fazer uma atualização off-line usando o cbbackup/cbrestore do cluster antigo para o novo, ou pode usar o cbtransfer (mas é preciso interromper as operações que criam dados antes da transferência!)
P: O Couchbase Server é gratuito ou são necessárias licenças?
R: O Couchbase Community é gratuito para desenvolvimento e produção para qualquer número de nós. O Couchbase Enterprise é gratuito para desenvolvimento, qualquer número de nós e até 2 em produção. Mais de 2 nós em produção requerem licença, mas nosso licenciamento também inclui o Enterprise Support!
P: Os servidores de aplicativos são dispositivos físicos ou podem ser VMs?
R: Os servidores de aplicativos e os servidores do Couchbase podem ser máquinas físicas ou virtuais.
P: O Couchbase pode ser usado como uma alternativa ao Clearquest/Clearcase ou esse produto é usado estritamente para controle de documentos?
R: O Couchbase é um armazenamento de dados sobre o qual você cria aplicativos, e o Clearquest/Clearcase são aplicativos que são construídos em armazenamentos de dados, portanto, a comparação com o Couchbase não é realmente "igual para igual".
P: O Couchbase pode ser monitorado com SNMP? É possível integrar o monitoramento do Couchbase ao Solarwinds?
R: Você pode usar o SNMP para monitorar o próprio servidor como qualquer outra máquina, mas o Couchbase em si não tem integração com SNMP até o momento. Até onde sei, não tenho conhecimento de uma integração padrão pronta para uso com o Solarwinds, mas imagino que não seria difícil se você pudesse estender o Solarwinds para sondar http/JSON para obter informações e ter acionadores personalizados.
P: O couchbase suporta failover para um nó do couchbase em espera? Como os dados armazenados serão sincronizados com um cluster do couchbase em espera?
R: Não temos um failover automático para um nó de espera, principalmente porque o failover envolve a promoção de partições de réplica para partições ativas. Se você usasse um nó de espera, teria de ter uma cópia de todos os dados do cluster nele, pois não sabe qual nó (e quais partições) ficará inacessível/falhará. Em vez disso, temos partições de réplica e, no caso de uma falha, o failover promoverá as partições de réplica para que fiquem ativas. Se estiver mantendo um cluster separado inteiro em standby (e usando o XDCR (Cross Data Center Replication) para replicar os dados do cluster ativo para ele), será necessário criar um script de sua própria lógica para decidir quando trocar os clusters.
P: Os valores de metadados (ou seja, ids) podem ser automatizados pelo sistema CB (ou seja, contagem automática de ids) ou ele transfere essa responsabilidade para o aplicativo?
R: Todos os IDs (chaves) são de responsabilidade do aplicativo, não há mecanismos incorporados no Couchbase para gerar IDs. No entanto, você pode usar Atomic Counters para agir como colunas IDENTITY em RDBMSs. Confira o webinar Couchbase 103 para obter mais informações sobre alguns padrões.
P: Podemos armazenar mp3 ou qualquer arquivo de áudio ou vídeo no Couchbase?
R: É claro que você pode armazenar qualquer coisa no Couchbase, tipos de dados simples, JSON e dados binários de qualquer tipo (MP3, JPEG, PNG etc.). Você está limitado apenas por um limite de 20 MB por "documento". No entanto, os arquivos de vídeo tendem a ser muito grandes e, nesse caso, seria melhor usar um sistema CDN projetado para arquivos grandes e transmiti-los para grandes públicos e armazenar os metadados de ativos do arquivo (como título, URL para transmiti-lo etc.) no Couchbase.
P: Qual é a quantidade de RAM que devemos deixar para o sistema operacional?
R: Depende, se você estiver usando muito as visualizações, seria prudente alocar mais RAM para o cache do sistema de arquivos. Em geral, recomendamos deixar cerca de 40% de RAM disponível para o sistema operacional (portanto, configure o Couchbase para usar 60%) e isso proporciona um bom desempenho geral. Se você não estiver usando visualizações, poderá alocar mais RAM para o Couchbase. Talvez seja bom consultar as diretrizes de dimensionamento nesta postagem do blog: https://www.couchbase.com/blog/how-many-nodes-part-1-introduction-sizing-couchbase-server-20-cluster
P: O que é um número alto de OPS em um sistema de 16 GB e 4 núcleos?
R: Outro "depende", será fortemente influenciado pela velocidade da rede e pela capacidade de enviar operações binárias pelo fio para o Couchbase. Uma caixa de 16 GB com 4 núcleos no Amazon AWS não será a mesma coisa que uma caixa física conectada ao(s) gerador(es) de carga com 10 GIGE. Você não verá esse tipo de desempenho, https://www.couchbase.com/blog/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server no AWS! Mas isso mostra que não é realmente o Couchbase em si que está limitando as operações, mas sim a rede e a capacidade de fornecer operações ao Couchbase por meio de soquetes binários.
P: Quantas réplicas vocês recomendam?
R: Em geral, a maioria das pessoas se sente confortável com apenas uma réplica, mas há algumas que desejam a segurança de duas réplicas; não conheço nenhum cliente que use três réplicas. É claro que você precisa reforçar seus servidores para ter mais réplicas com mais RAM alocada e, possivelmente, CPU também, se for indexar as réplicas. Em última análise, essa decisão deve ser sua, pois você está mais ciente dos dados e da importância de protegê-los contra qualquer perda de dados, etc.
P: Para conexões de cliente sdk, precisamos adicionar todos os ips do servidor manualmente?
R: Há várias maneiras de lidar com isso, por meio do DNS, por exemplo, onde você faz com que os servidores de aplicativos sempre se conectem a um registro CNAME ou A e liste todas as máquinas do cluster (ou registre-as automaticamente) com o registro A. Ou você pode colocar os IPs em um arquivo de configuração que é atualizado em todos os servidores (ou localizado centralmente), ou digitar os IPs no código de inicialização do aplicativo, etc.
P: Com relação ao sistema operacional, ele está disponível para o Ubuntu. Há algum problema se você usar outra distribuição, como o Debian?
R: Acredito que isso seja possível, mas não experimentei. Os sistemas operacionais listados na página de download também são os mais testados. Sei que um de nossos engenheiros fez o Couchbase funcionar no Joyent SmartOS, mas não é um download oficial, etc.
P: Os metadados não são mantidos?
R: Os metadados também são mantidos no disco, é claro, mas também são sempre mantido na RAM também. Os documentos ficarão na RAM se houver RAM suficiente disponível no bucket (em todo o cluster) para conter os valores. Caso contrário, o Not Recently Used (NRU) é usado para ejetar o documento valores para o disco.
P: Qual é a utilidade dos trabalhadores de IO? Por que ele é dividido quando adicionamos novos nós?
R: Os operadores de E/S são usados para ler/gravar do disco. Você pode aumentar o número de threads (operadores) na configuração do seu bucket, dependendo da sua capacidade de fazer isso (se você só puder lidar com 4 operadores, configurá-lo para 8 não alterará o desempenho). Quando você adiciona mais nós ao cluster, aumenta seus workers de E/S linearmente, com cada novo nó adicionando a mesma quantidade de workers de E/S (para sua própria E/S). Eles não são "divididos", são alocados por nó.
P: Você disse: "A marca d'água alta mudou recentemente de 80% para 90%"? E quanto à marca d'água baixa, ela continua sendo 60% ou mudou?
R: Na verdade, esses são parâmetros configuráveis; as configurações padrão são aproximadamente 80% para marca d'água baixa e 90% para marca d'água alta. Na marca d'água baixa, a ejeção dos dados da partição de réplica da RAM começará e, na marca d'água alta, ocorrerá a ejeção dos dados da partição ativa da RAM. Esses também são parâmetros configuráveis no nível do bucket, consulte: http://docs.couchbase.com/couchbase-manual-2.2/#changing-thresholds-for-ejection
P: Como posso excluir um bucket de dados?
R: Na interface de administração, você pode excluir um compartimento clicando em Compartimentos de dados na navegação superior, clicando no triângulo ao lado do nome do compartimento para expandir, clicando no botão Editar no lado direito e, na parte inferior da caixa de diálogo modal que aparece, há um botão Excluir. Você também pode excluir os compartimentos de forma programática nos SDKs.
P: Qual é a relação entre o Couchbase e o Apache CouchDB?
R: Os fundadores do CouchDB (Damien Miller e JChris Anderson) deixaram o projeto Apache CouchDB e se juntaram/fizeram uma fusão com a NorthScale/Membase como fundadores do Couchbase, juntamente com Steve Yen e Dustin Sallings (da Northscale/Membase). Há muitas semelhanças no estilo Views Map-Reduce e na sintaxe de consulta que serão familiares aos usuários do CouchDB; no entanto, há também muitas diferenças importantes. O Couchbase é uma empresa de código aberto independente e com fins lucrativos, com sua própria base de código independente que não está vinculada ao CouchDB de forma alguma. As operações CRUD binárias, no entanto, se assemelham mais ao memcached/membase do que a qualquer coisa relacionada ao CouchDB. Eles certamente poderiam ter escolhido um nome menos confuso...
P: Como a arquitetura lida com partições fora de equilíbrio?
R: Na verdade, nossa estratégia de hashing e partição tem se mostrado muito bem distribuída ao longo de muitos anos, e é por isso que ainda a usamos.
Q: Como são tratadas as falhas de nós?
R: Há duas maneiras de lidar com falhas de nós: a primeira é ativando o failover automático. No failover automático, se um nó ficar inacessível por 30 segundos, esse nó sofrerá failover automaticamente e as réplicas serão promovidas a ativas. A alternativa é fazer o failover manual de um nó (ou programá-lo para ser automático, mas com base em sua própria solução de monitoramento), o que pode lhe dar a flexibilidade de decidir todos os parâmetros e o tempo para os failovers de nós.
P: Tentei instalar o servidor couchbase enterprise2.2.0 no fedora17, mas obtive falhas para libcrypto.so e libssl.so. Como faço para corrigir isso?
R: Sim, devido a uma dependência do erlang na biblioteca principal do erlang, você precisa instalar o openssl098e pelo yum
P: O que significa acid para o Couchbase?
R: O Couchbase oferece suporte a "transações" ACID em um nível por documento. Você pode usar CAS (Check and Set/Compare and Swap) para uma concorrência otimista ou usar GetAndLock para realmente bloquear um documento para cenários de concorrência pessimista. Em geral, as transações são muito mais necessárias em armazenamentos de dados RDBMS normalizados. O motivo é que, devido à normalização, as estruturas de dados costumam ser divididas em muitas tabelas diferentes e, sem as transações, a integridade dos dados entra em colapso rapidamente. Em cenários NoSQL como o Couchbase, como os dados são muito menos normalizados, as transações geralmente são menos necessárias do que no mundo RDBMS. Usando o modelo de simultaneidade, você pode criar transações. Também temos operações de durabilidade em que você pode garantir que os dados tenham chegado a uma réplica e/ou ao disco.
P: Se um dos nós do cluster ficar inativo, como o mapa no servidor de aplicativos do cliente será atualizado e os dados nesse nó serão atualizados?
R: Quando um failover é acionado (automática ou manualmente), isso promove as partições de réplica para ativas. Se um nó receber uma operação CRUD para um número de partição que ele não possui, ele retornará um erro "Not My VBucket" para o cliente sdk, que sabe como lidar com isso. Esse erro indica que o mapa do cluster está desatualizado ou fora de sincronia e solicita automaticamente um novo mapa a partir da conexão HTTP persistente. Há apenas dois cenários em que um mapa de cluster é alterado, em rebalanceamentos e failovers. Portanto, esses são os momentos em que a topologia muda e o mapa do cluster é alterado, e o cliente verá isso na primeira operação que retorna o erro "Not My VBucket".
P: Há um limite de 20 GB no disco rígido de cada servidor?
R: Não há limite de armazenamento, o que você pode ter entendido errado é que há um limite de 20 MB por valor de documento no Couchbase.
P: O append only disk writes é semelhante ao journaling e ao que o sistema de arquivos do sistema operacional usa?
R: Sim, é uma estratégia semelhante, mas em nosso próprio formato.
P: Existe uma maneira de monitorar o tamanho do disco livre? Ele enviará uma notificação por pager ou e-mail quando atingir os limites (por exemplo, 80% cheio)? O mesmo caso para o uso de CPU/MEM?
R: Não temos esse tipo de sistema de notificação incorporado, mas é certamente trivial integrar seu próprio sistema para fazer isso. Eles são mais parecidos com o monitoramento de VMs/computadores do que com os específicos do Couchbase, mas você poderia facilmente criar uma integração para seus próprios parâmetros personalizados. Todas as informações nos gráficos do console de administração estão disponíveis como JSON com solicitações http.
Q: O que é um balde?
R: Um bucket é um "banco de dados", uma coleção de dados. Ele também é um espaço de nomes para os dados, portanto, todas as chaves precisam ser exclusivas em um bucket. Ele também funciona como um espaço de nomes para visualizações; os documentos de design e as visualizações só podem acessar os dados dentro do bucket em que estão definidos.
P: No caso de haver vários servidores couchbase e vários servidores de aplicativos, todos os servidores de aplicativos podem se conectar ao mesmo servidor couchbase (mesmo endereço IP)? Nesse caso, o balanceamento de carga é feito automaticamente pelo couchbase ou é melhor distribuir as conexões entre os servidores de aplicativos?
R: Ótima pergunta, é importante NÃO colocar um balanceador de carga entre os servidores de aplicativos e o Couchbase. Devido ao particionamento de chave-hash, os dados já estão automaticamente distribuídos pelo cluster do Couchbase. Os servidores de aplicativos se conectarão e interagirão com os nós do cluster do Couchbase diretamente e, devido ao particionamento, já estarão "balanceados" no sentido de que farão operações CRUD em todo o cluster com base no hashing das chaves. Os servidores de aplicativos e os clientes sdk manterão conexões abertas com cada nó no cluster do Couchbase e, em geral, uma única conexão compartilhada é tudo o que é necessário para cada servidor de aplicativos.
P: O que acontece quando um documento está sendo acessado por aplicativos clientes enquanto o rebalanceamento desse documento que contém o bucket está em andamento?
R: Todas as operações continuam normalmente durante o rebalanceamento, e as operações normais são priorizadas em relação ao rebalanceamento. Isso significa que o rebalanceamento continuará enquanto você estiver realizando operações. É claro que, de modo geral, é melhor não iniciar um rebalanceamento durante o pico de uso! No entanto, depende do tipo de nível de uso e da configuração se isso pode causar lentidão ou não. Na maioria dos casos, isso não é perceptível.
P: Qual é o tipo de BLOB semelhante no Couchbase?
R: Você pode armazenar dados binários diretamente como um valor usando o SDK. Como não temos um esquema definido ou imposto, não é necessário especificar que se trata de um BLOB. O BLOB é simplesmente o valor do "documento".
P: Quando executo uma operação de configuração, o documento vai primeiro para a RAM e, em seguida, é enviado para a fila de gravação em disco e para a fila de replicação.
R: Sempre que há uma falha em qualquer sistema de qualquer tipo (qualquer tipo de banco de dados, servidor de aplicativos, telefone celular etc.), há sempre a possibilidade de perda de dados. Todas as estratégias são tentativas de minimizá-la da melhor forma possível, mas, nesse exato cenário, sim, é possível colocá-los na RAM, mas não na fila de gravação em disco e/ou na fila de replicação, se a máquina sofrer uma pane grave no exato momento entre o armazenamento e a RAM e a inserção nas filas.
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
