Couchbase Server 2.0: Perguntas mais comuns (e respostas)

Acabei de concluir uma série de nove semanas de webinars técnicos destacando os recursos da nossa próxima versão do Couchbase Server 2.0. Foi muito divertido interagir com as centenas de participantes e fiquei impressionado com o nível de entusiasmo, envolvimento e expectativa em relação a esse novo produto.

(A propósito, se você perdeu a série, todas as nove sessões são disponível para reprodução.) Houve algumas perguntas excelentes geradas pelos usuários durante a série de webinars, e meu plano original era usar este post do blog para destacar todas elas. Rapidamente percebi que havia muitas perguntas para que alguém pudesse ler todas elas, por isso adotei uma abordagem diferente. Este blog apresentará as perguntas mais comuns/importantes/interessantes e as responderá aqui para o benefício de todos. Antes de entrar no assunto, responderei à pergunta que foi, de longe, a mais frequente: "Quanto tempo falta para a GA do Couchbase Server 2.0?" No momento, estamos no caminho certo para lançá-lo antes do final do ano. Enquanto isso, sinta-se à vontade para experimentar o Developer Preview que já está disponível. Quanto ao restante das perguntas, aqui vai!

P: Quais são os principais benefícios de incorporar o Membase e o CouchDB em um único produto?

R: O Membase é um armazenamento de valores-chave super rápido e altamente escalável, conhecido por seu desempenho e escalabilidade. O CouchDB, por outro lado, é um excelente banco de dados de documentos, com recursos avançados de indexação e consulta. A combinação desses dois produtos reúne o melhor dos dois mundos para criar um banco de dados NoSQL de alto desempenho e altamente elástico que se expande linearmente e, ao mesmo tempo, oferece recursos de consulta, indexação e orientados a documentos.

P: O Couchbase acelera o acesso a um documento do banco de dados armazenando-o automaticamente em cache na memória?

R: Com certeza! Esse é um dos grandes recursos do Couchbase Server 2.0 e vem da vasta experiência que temos com o memcached. Todo o acesso aos documentos passa por nossa camada de cache de RAM integrada (criada a partir do memcached) para proporcionar uma latência extremamente baixa e, o que é mais importante, previsível, sob cargas extremamente pesadas. Por exemplo, vemos regularmente clientes com mais de 100 mil operações/segundo em um cluster e levamos nós individuais a mais de 200 mil operações/segundo em nossos próprios ambientes de teste. Essa camada de cache de RAM também nos permite lidar com picos de carga de gravação (e leitura) sem afetar o desempenho do aplicativo.

P: Vejo em seus fóruns que o Couchbase Server 2.0 usa o protocolo memcached para acessar dados, pois isso é compatível com os usuários existentes do Membase e também com o desempenho muito maior. Existe uma maneira de usar APIs REST semelhantes às do CouchDB para acessar os documentos no Couchbase Server 2.0?

R: A primeira versão do Couchbase Server 2.0 usa o protocolo memcached para acesso a documentos e o protocolo HTTP do CouchDB para acessar exibições. Com o tempo, esses dois protocolos se unirão ainda mais. Nesse meio tempo, fornecemos várias bibliotecas de clientes que abstraem esses dois métodos de acesso do desenvolvedor.

P: O Couchbase Server 2.0 será de código aberto?

R: Já está acontecendo! Como empresa, a Couchbase está totalmente comprometida com a promoção das comunidades de código aberto que existem e estão sendo construídas em torno de nossos vários produtos. Embora nosso foco seja fornecer software de classe empresarial para nossos clientes pagantes, aceitamos o fluxo livre de ideias e a ampla adoção que um projeto de código aberto permite e acreditamos firmemente que há lugar para ambos.

Indexação/pesquisa

P: "Tudo o que preciso é de um índice secundário simples, sem mapeamento/redução... como faço isso?

R: Atualmente, todos os nossos índices são criados usando uma função de mapa (a redução é totalmente opcional e pode ser ignorada aqui). Na verdade, essa é apenas outra sintaxe para criar um índice e há vários exemplos disponíveis que discutem como criar índices muito simples. A forma mais simples envolveria apenas colocar "emit(doc.)" em sua função map onde está o que você deseja indexar. Isso criará uma lista de todos os documentos que contêm esse campo, classificados por esse campo. É claro que há cenários mais complexos, mas isso pode ser bastante simples se for necessário.

P: Como lidar com as visualizações do Couchbase Server 2.0 difere do CouchDB e do Couchbase Single Server?

R: De forma alguma... o formato, a sintaxe, tudo é o mesmo. Além disso, todas as opções de consulta são compatíveis. Você pode literalmente copiar e colar o código de visualização de um para outro. Também há suporte para vários documentos de design.

P: O Couchbase Server 2.0 oferece suporte a consultas ad-hoc?

R: No momento, todas as consultas ao Couchbase Server (como o CouchDB) devem ser feitas em visualizações pré-materializadas. Em geral, essa é a única maneira de proporcionar um desempenho confiável ao fazer essas consultas. Também entendemos a necessidade de mais consultas sob demanda/ad-hoc e estamos trabalhando diligentemente para oferecer isso também. O Couchbase já começou a adotar uma abordagem líder do setor para criar uma linguagem específica para dados não estruturados que possa ser usada em todo o cenário NoSQL. Dê uma olhada em http://unqlspec.org para ver no que estamos trabalhando!

SDKs/bibliotecas de clientes

P: Quais SDKs e bibliotecas de clientes são compatíveis?

R: Em um nível básico, o Couchbase Server 2.0 suporta qualquer biblioteca que implemente o protocolo memcached (e há MUITAS delas). Para a funcionalidade adicional que adicionamos (comandos de protocolo estendidos e acesso de visualização), o Couchbase fornece bibliotecas de cliente para várias linguagens (Java, .NET, PHP, Python, Ruby, C/C++), bem como instruções sobre como estender bibliotecas para outras linguagens.

P: Há alguma chance de dogpiling com stale=update_after? Se você receber 30 solicitações simultaneamente para uma exibição com stale=update_after, elas gerarão várias solicitações simultaneamente para atualizar o índice?

R: Para recapitular, "stale" informa ao servidor que essa solicitação de consulta deve ser retornada o mais rápido possível, sabendo que alguns dados que já foram gravados podem não ser incluídos na exibição. Ao colocar "update_after" também na solicitação, o cliente está dizendo ao servidor para rematerializar o índice em segundo plano... depois de retornar a solicitação inicial o mais rápido possível. Uma vez iniciada essa rematerialização, as solicitações subsequentes não farão com que nada diferente aconteça, portanto, não há preocupação com problemas de "dogpiling" ou "stampeding herd".

P: Como o cliente sabe quando deve extrair os mapas atualizados do servidor/vbucket?

R: Todos os clientes (sejam eles nossos clientes "inteligentes" ou estejam passando pelo nosso processo Moxi) manterão uma conexão de fluxo contínuo com um servidor Couchbase. Quando a topologia do cluster mudar (adicionar/remover/failover nós), os clientes serão atualizados automaticamente com um novo mapa do vbucket por meio dessa conexão. Os clientes também podem solicitar esse mapa sob demanda e fazer isso sempre que forem inicializados. Além disso, cada nó do cluster sabe por quais vbuckets é responsável e só retornará dados para esses vbuckets. Dessa forma, mesmo que um cliente esteja temporariamente fora de sincronia com o cluster, ele nunca ficará vulnerável a dados inconsistentes.

Desenvolvimento/Produção Visualizar uso

P: Por que o esforço extra de criar uma visualização no modo de "desenvolvimento" e depois colocá-la em produção?

R: Queríamos oferecer a possibilidade de desenvolver visualizações em um conjunto de dados em tempo real, mas não queríamos que esse desenvolvimento afetasse o aplicativo em execução no momento. Assim, foi criado um modo de "desenvolvimento" para que os usuários pudessem criar e editar visualizações em dados "reais". Para acelerar as iterações do desenvolvimento, o padrão é materializar uma visualização em um subconjunto dos dados. Quando o desenvolvimento estiver concluído, o usuário poderá optar por materializar a visualização em todo o cluster antes de colocá-la em produção. Isso oferece o benefício adicional de materializar a visualização para que ela esteja imediatamente pronta para ser usada pelo aplicativo. Por fim, esse modo de "desenvolvimento" pode ser usado para editar exibições que estão atualmente em produção, sem afetar o acesso do aplicativo a elas (fazendo uma cópia). Quando as edições estiverem concluídas, a visualização poderá ser materializada e trocada com a original em produção.

P: Como você controla qual é o conjunto de dados de desenvolvimento?

R: Atualmente, o conjunto de dados de desenvolvimento é decidido automaticamente pelo software, dependendo da quantidade de dados existentes. Para conjuntos de dados pequenos, o software realmente materializará a visualização em todo o conjunto. À medida que o conjunto aumenta, o software o reduz automaticamente para proporcionar um tempo de resposta mais rápido durante o desenvolvimento. Uma vez finalizada a visualização, o usuário tem a opção de executá-la manualmente em todo o conjunto de dados (clicando na guia "Full Cluster Dataset"), tanto para fins de verificação final quanto para prepará-la para uso em produção.

Agrupamento

P: Em um bucket com réplica e failover automático, uma falha no servidor sem rebalanceamento causará erros de recuperação/atualização nesse bucket?

R: Quando um servidor falhar inicialmente (por qualquer motivo: hardware, rede, software), o aplicativo receberá brevemente erros para todos os dados pelos quais esse servidor era responsável. As solicitações de dados em outros servidores não serão afetadas. Esses erros continuarão até que ocorra a "falha" do nó, o que ativa os dados de réplica (vbuckets) em outro local do cluster. O tempo varia de acordo com o uso de failover automático ou manual... mas quando o failover é acionado, não há mais atraso. Você pode se perguntar "mas por que não posso ler os dados da réplica que já existe?". A resposta é dupla. Em primeiro lugar, proibimos especificamente o acesso aos dados da réplica (enquanto ela é "réplica") para preservar a consistência muito forte que nosso sistema oferece. Em operação normal, você tem a garantia de "ler suas próprias gravações" e isso é feito fornecendo apenas um local para acessar qualquer dado. Ao permitir a leitura irrestrita de réplicas, você pode ter uma situação em que um cliente grava um dado na cópia ativa e outro cliente tenta imediatamente ler esse dado da réplica... levando a uma possível inconsistência. Agora, a segunda parte dessa resposta é que estamos trabalhando atualmente em um recurso para permitir a leitura dessas réplicas. Será uma nova operação invocada explicitamente pelo aplicativo para que não haja confusão sobre de qual cópia está sendo lida. Você ainda desejará fazer o failover do nó o mais rápido possível, pois as gravações continuarão a falhar. Esse é um exemplo dos muitos recursos que adicionamos como resposta direta às demandas de nossos clientes e usuários... você fala e nós ouvimos (e depois fazemos algo a respeito também)!

P: Há algum efeito/risco/tempo ao rebalancear um sistema sob cargas pesadas de gravação? É melhor adicionar nós em épocas de bastante movimento?

R: Por padrão, a operação de rebalanceamento é feita de forma assíncrona para causar o mínimo possível de impacto no desempenho do cluster. No entanto, a realidade é que o rebalanceamento aumenta a carga no cluster e requer recursos para fazê-lo (rede, disco, RAM, CPU). Se o cluster já estiver perto da capacidade, qualquer aumento de carga poderá afetar o desempenho do aplicativo. Embora seja seguro fazer isso a qualquer momento, é altamente recomendável realizar seus próprios testes em seu próprio ambiente para caracterizar qual será o impacto, se houver algum, de um rebalanceamento. Normalmente, nossos clientes realizam esses testes em momentos de baixa ou tranquilidade, mas a principal vantagem é que você não precisa deixar o aplicativo completamente off-line enquanto continua a escalonar.

P: O que é um vbucket?

R: Um vbucket é a nossa maneira de particionar logicamente os dados para que possam ser distribuídos em todos os nós de um cluster. Cada bucket do tipo Couchbase que é criado no cluster é automaticamente (e de forma transparente) dividido em um conjunto estático de fatias (os vbuckets). Esses são então "mapeados" para servidores individuais. Quando um nó é adicionado ou removido, são essas fatias que são movidas e mapeadas novamente para proporcionar um dimensionamento linear e sem interrupções. Embora totalmente abstraídos do aplicativo e do usuário, é importante perceber que os vbuckets existem "por baixo do pano" para fornecer muitos dos recursos maravilhosos do Couchbase Server. Você pode saber mais sobre o conceito de vbucket.

Monitoramento

P: A interface do usuário da Web do Couchbase Server é o único método de monitoramento de um cluster do Couchbase Server?

R: Não necessariamente, não. Tudo o que você vê e pode fazer na interface do usuário da Web é, na verdade, orientado pela nossa interface REST, que pode ser acessada externamente de forma programática. Além disso, cada servidor individual (e cada bucket individual nesse servidor) fornece suas próprias estatísticas "brutas" que são usadas pela API REST. Essas estatísticas brutas também estão disponíveis externamente:

Nosso objetivo é fornecer o máximo possível de informações sobre o sistema para que nossos usuários possam monitorá-lo de forma eficaz, tanto do ponto de vista do planejamento de capacidade quanto do ponto de vista de diagnóstico/solução de problemas quando as coisas começarem a dar errado (ou para evitar que as coisas deem errado em primeiro lugar).

P: Que tipo de alerta o Couchbase Server oferece?

R: Tecnicamente, não somos uma empresa que fabrica software de alerta. Em nossa opinião, nosso trabalho é fornecer uma interface para que outros sistemas façam uso dela. A maioria das grandes organizações não gostaria que cada parte da tecnologia em sua pilha enviasse um conjunto de alertas com formatos diferentes. É por isso que tornamos tão fácil conectar nossas estatísticas e dados de monitoramento a qualquer outro sistema. No entanto, também percebemos que alguns ambientes menores podem, de fato, querer que nosso software forneça isso imediatamente. Estamos trabalhando para ampliar nossos recursos aqui e já fornecemos alertas para quando os nós caem.

Autocompactação

P: Se você abortar a compactação no final do período de tempo, a compactação feita até esse ponto ainda será salva ou toda a compactação feita até o momento será perdida?

R: Normalmente, uma compactação é do tipo tudo ou nada e, portanto, abortá-la perderá o progresso que foi feito até o momento. No entanto, no Couchbase Server, estamos executando a compactação em uma base por vbucket (veja acima) e, portanto, todo o conjunto de dados pode ser compactado de forma incremental sem perder todo o progresso feito quando abortado.

Autofailover

P: Por que há um atraso antes que o cluster faça o failover automático de um nó inoperante?

R: Por padrão, o software é configurado com um mínimo de 30 segundos antes que o failover automático seja ativado. Isso foi projetado para evitar que o software faça a "coisa errada". Por exemplo, se um nó estiver simplesmente lento para responder ou se houver um breve soluço na rede, você não desejará que ele sofra um failover e, portanto, o cluster aguardará para garantir que o nó esteja realmente inoperante.

Para obter ainda mais informações, você pode assistir aos vídeos de 25 a 30 minutos do webinar de cada semana acessando aqui. E o local de referência para todas as informações sobre o Couchbase Server 2.0 pode ser encontrado aqui. Embora essa série possa ter chegado ao fim, já estamos planejando iniciar outra para destacar não apenas os recursos do Couchbase Server 2.0, mas também o Couchbase Mobile, nossos SDKs/bibliotecas de clientes e muito mais! Alguns dos tópicos incluirão:

• Sincronização entre clusters (também conhecida como replicação entre data centers)
• Backup/Restauração com o Couchbase Server 2.0
• Atualização a partir do Membase 1.7
• E muito mais!

Para torná-lo ainda melhor, estou pedindo sua ajuda para participar! Por favor, comente aqui (ou me envie um e-mail diretamente para perry@couchbase.com) com os tópicos que acha que precisamos abordar mais e faremos o possível para incluí-los em um próximo webinar.