{"id":1572,"date":"2016-01-26T23:04:16","date_gmt":"2016-01-26T23:04:15","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=1572"},"modified":"2023-06-23T05:54:47","modified_gmt":"2023-06-23T12:54:47","slug":"couchbase-server-20-most-common-questions-and-answers","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/couchbase-server-20-most-common-questions-and-answers\/","title":{"rendered":"Couchbase Server 2.0: Perguntas mais comuns (e respostas)"},"content":{"rendered":"

Acabei de concluir uma s\u00e9rie de nove semanas de webinars t\u00e9cnicos destacando os recursos da nossa pr\u00f3xima vers\u00e3o do Couchbase Server 2.0. Foi muito divertido interagir com as centenas de participantes e fiquei impressionado com o n\u00edvel de entusiasmo, envolvimento e expectativa em rela\u00e7\u00e3o a esse novo produto.<\/p>\n

(A prop\u00f3sito, se voc\u00ea perdeu a s\u00e9rie, todas as nove sess\u00f5es s\u00e3o dispon\u00edvel para reprodu\u00e7\u00e3o<\/a>.) Houve algumas perguntas excelentes geradas pelos usu\u00e1rios durante a s\u00e9rie 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\u00e9m pudesse ler todas elas, por isso adotei uma abordagem diferente. Este blog apresentar\u00e1 as perguntas mais comuns\/importantes\/interessantes e as responder\u00e1 aqui para o benef\u00edcio de todos. Antes de entrar no assunto, responderei \u00e0 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\u00e7\u00e1-lo antes do final do ano. Enquanto isso, sinta-se \u00e0 vontade para experimentar o Developer Preview que j\u00e1 est\u00e1 dispon\u00edvel. Quanto ao restante das perguntas, aqui vai!<\/p>\n

P: Quais s\u00e3o os principais benef\u00edcios de incorporar o Membase e o CouchDB em um \u00fanico produto?<\/p>\n

R: O Membase \u00e9 um armazenamento de valores-chave super r\u00e1pido e altamente escal\u00e1vel, conhecido por seu desempenho e escalabilidade. O CouchDB, por outro lado, \u00e9 um excelente banco de dados de documentos, com recursos avan\u00e7ados de indexa\u00e7\u00e3o e consulta. A combina\u00e7\u00e3o desses dois produtos re\u00fane o melhor dos dois mundos para criar um banco de dados NoSQL de alto desempenho e altamente el\u00e1stico que se expande linearmente e, ao mesmo tempo, oferece recursos de consulta, indexa\u00e7\u00e3o e orientados a documentos.<\/p>\n

P: O Couchbase acelera o acesso a um documento do banco de dados armazenando-o automaticamente em cache na mem\u00f3ria?<\/p>\n

R: Com certeza! Esse \u00e9 um dos grandes recursos do Couchbase Server 2.0 e vem da vasta experi\u00eancia 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\u00eancia extremamente baixa e, o que \u00e9 mais importante, previs\u00edvel, sob cargas extremamente pesadas. Por exemplo, vemos regularmente clientes com mais de 100 mil opera\u00e7\u00f5es\/segundo em um cluster e levamos n\u00f3s individuais a mais de 200 mil opera\u00e7\u00f5es\/segundo em nossos pr\u00f3prios ambientes de teste. Essa camada de cache de RAM tamb\u00e9m nos permite lidar com picos de carga de grava\u00e7\u00e3o (e leitura) sem afetar o desempenho do aplicativo.<\/p>\n

P: Vejo em seus f\u00f3runs que o Couchbase Server 2.0 usa o protocolo memcached para acessar dados, pois isso \u00e9 compat\u00edvel com os usu\u00e1rios existentes do Membase e tamb\u00e9m com o desempenho muito maior. Existe uma maneira de usar APIs REST semelhantes \u00e0s do CouchDB para acessar os documentos no Couchbase Server 2.0?<\/p>\n

R: A primeira vers\u00e3o do Couchbase Server 2.0 usa o protocolo memcached para acesso a documentos e o protocolo HTTP do CouchDB para acessar exibi\u00e7\u00f5es. Com o tempo, esses dois protocolos se unir\u00e3o ainda mais. Nesse meio tempo, fornecemos v\u00e1rias bibliotecas de clientes que abstraem esses dois m\u00e9todos de acesso do desenvolvedor.<\/p>\n

P: O Couchbase Server 2.0 ser\u00e1 de c\u00f3digo aberto?<\/p>\n

R: J\u00e1 est\u00e1 acontecendo! Como empresa, a Couchbase est\u00e1 totalmente comprometida com a promo\u00e7\u00e3o das comunidades de c\u00f3digo aberto que existem e est\u00e3o sendo constru\u00eddas em torno de nossos v\u00e1rios produtos. Embora nosso foco seja fornecer software de classe empresarial para nossos clientes pagantes, aceitamos o fluxo livre de ideias e a ampla ado\u00e7\u00e3o que um projeto de c\u00f3digo aberto permite e acreditamos firmemente que h\u00e1 lugar para ambos.<\/p>\n

Indexa\u00e7\u00e3o\/pesquisa<\/h4>\n

P: \"Tudo o que preciso \u00e9 de um \u00edndice secund\u00e1rio simples, sem mapeamento\/redu\u00e7\u00e3o... como fa\u00e7o isso?<\/p>\n

R: Atualmente, todos os nossos \u00edndices s\u00e3o criados usando uma fun\u00e7\u00e3o de mapa (a redu\u00e7\u00e3o \u00e9 totalmente opcional e pode ser ignorada aqui). Na verdade, essa \u00e9 apenas outra sintaxe para criar um \u00edndice e h\u00e1 v\u00e1rios exemplos dispon\u00edveis que discutem como criar \u00edndices muito simples. A forma mais simples envolveria apenas colocar \"emit(doc.)\" em sua fun\u00e7\u00e3o map onde est\u00e1 o que voc\u00ea deseja indexar. Isso criar\u00e1 uma lista de todos os documentos que cont\u00eam esse campo, classificados por esse campo. \u00c9 claro que h\u00e1 cen\u00e1rios mais complexos, mas isso pode ser bastante simples se for necess\u00e1rio.<\/p>\n

P: Como lidar com as visualiza\u00e7\u00f5es do Couchbase Server 2.0 difere do CouchDB e do Couchbase Single Server?<\/p>\n

R: De forma alguma... o formato, a sintaxe, tudo \u00e9 o mesmo. Al\u00e9m disso, todas as op\u00e7\u00f5es de consulta s\u00e3o compat\u00edveis. Voc\u00ea pode literalmente copiar e colar o c\u00f3digo de visualiza\u00e7\u00e3o de um para outro. Tamb\u00e9m h\u00e1 suporte para v\u00e1rios documentos de design.<\/p>\n

P: O Couchbase Server 2.0 oferece suporte a consultas ad-hoc?<\/p>\n

R: No momento, todas as consultas ao Couchbase Server (como o CouchDB) devem ser feitas em visualiza\u00e7\u00f5es pr\u00e9-materializadas. Em geral, essa \u00e9 a \u00fanica maneira de proporcionar um desempenho confi\u00e1vel ao fazer essas consultas. Tamb\u00e9m entendemos a necessidade de mais consultas sob demanda\/ad-hoc e estamos trabalhando diligentemente para oferecer isso tamb\u00e9m. O Couchbase j\u00e1 come\u00e7ou a adotar uma abordagem l\u00edder do setor para criar uma linguagem espec\u00edfica para dados n\u00e3o estruturados que possa ser usada em todo o cen\u00e1rio NoSQL. D\u00ea uma olhada em https:\/\/unqlspec.org para ver no que estamos trabalhando!<\/p>\n

SDKs\/bibliotecas de clientes<\/h4>\n

P: Quais SDKs e bibliotecas de clientes s\u00e3o compat\u00edveis?<\/p>\n

R: Em um n\u00edvel b\u00e1sico, o Couchbase Server 2.0 suporta qualquer biblioteca que implemente o protocolo memcached (e h\u00e1 MUITAS delas). Para a funcionalidade adicional que adicionamos (comandos de protocolo estendidos e acesso de visualiza\u00e7\u00e3o), o Couchbase fornece bibliotecas de cliente para v\u00e1rias linguagens (Java, .NET, PHP, Python, Ruby, C\/C++), bem como instru\u00e7\u00f5es sobre como estender bibliotecas para outras linguagens.<\/p>\n

P: H\u00e1 alguma chance de dogpiling com stale=update_after? Se voc\u00ea receber 30 solicita\u00e7\u00f5es simultaneamente para uma exibi\u00e7\u00e3o com stale=update_after, elas gerar\u00e3o v\u00e1rias solicita\u00e7\u00f5es simultaneamente para atualizar o \u00edndice?<\/p>\n

R: Para recapitular, \"stale\" informa ao servidor que essa solicita\u00e7\u00e3o de consulta deve ser retornada o mais r\u00e1pido poss\u00edvel, sabendo que alguns dados que j\u00e1 foram gravados podem n\u00e3o ser inclu\u00eddos na exibi\u00e7\u00e3o. Ao colocar \"update_after\" tamb\u00e9m na solicita\u00e7\u00e3o, o cliente est\u00e1 dizendo ao servidor para rematerializar o \u00edndice em segundo plano... depois de retornar a solicita\u00e7\u00e3o inicial o mais r\u00e1pido poss\u00edvel. Uma vez iniciada essa rematerializa\u00e7\u00e3o, as solicita\u00e7\u00f5es subsequentes n\u00e3o far\u00e3o com que nada diferente aconte\u00e7a, portanto, n\u00e3o h\u00e1 preocupa\u00e7\u00e3o com problemas de \"dogpiling\" ou \"stampeding herd\".<\/p>\n

P: Como o cliente sabe quando deve extrair os mapas atualizados do servidor\/vbucket?<\/p>\n

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

Desenvolvimento\/Produ\u00e7\u00e3o Visualizar uso<\/h4>\n

P: Por que o esfor\u00e7o extra de criar uma visualiza\u00e7\u00e3o no modo de \"desenvolvimento\" e depois coloc\u00e1-la em produ\u00e7\u00e3o?<\/p>\n

R: Quer\u00edamos oferecer a possibilidade de desenvolver visualiza\u00e7\u00f5es em um conjunto de dados em tempo real, mas n\u00e3o quer\u00edamos que esse desenvolvimento afetasse o aplicativo em execu\u00e7\u00e3o no momento. Assim, foi criado um modo de \"desenvolvimento\" para que os usu\u00e1rios pudessem criar e editar visualiza\u00e7\u00f5es em dados \"reais\". Para acelerar as itera\u00e7\u00f5es do desenvolvimento, o padr\u00e3o \u00e9 materializar uma visualiza\u00e7\u00e3o em um subconjunto dos dados. Quando o desenvolvimento estiver conclu\u00eddo, o usu\u00e1rio poder\u00e1 optar por materializar a visualiza\u00e7\u00e3o em todo o cluster antes de coloc\u00e1-la em produ\u00e7\u00e3o. Isso oferece o benef\u00edcio adicional de materializar a visualiza\u00e7\u00e3o para que ela esteja imediatamente pronta para ser usada pelo aplicativo. Por fim, esse modo de \"desenvolvimento\" pode ser usado para editar exibi\u00e7\u00f5es que est\u00e3o atualmente em produ\u00e7\u00e3o, sem afetar o acesso do aplicativo a elas (fazendo uma c\u00f3pia). Quando as edi\u00e7\u00f5es estiverem conclu\u00eddas, a visualiza\u00e7\u00e3o poder\u00e1 ser materializada e trocada com a original em produ\u00e7\u00e3o.<\/p>\n

P: Como voc\u00ea controla qual \u00e9 o conjunto de dados de desenvolvimento?<\/p>\n

R: Atualmente, o conjunto de dados de desenvolvimento \u00e9 decidido automaticamente pelo software, dependendo da quantidade de dados existentes. Para conjuntos de dados pequenos, o software realmente materializar\u00e1 a visualiza\u00e7\u00e3o em todo o conjunto. \u00c0 medida que o conjunto aumenta, o software o reduz automaticamente para proporcionar um tempo de resposta mais r\u00e1pido durante o desenvolvimento. Uma vez finalizada a visualiza\u00e7\u00e3o, o usu\u00e1rio tem a op\u00e7\u00e3o de execut\u00e1-la manualmente em todo o conjunto de dados (clicando na guia \"Full Cluster Dataset\"), tanto para fins de verifica\u00e7\u00e3o final quanto para prepar\u00e1-la para uso em produ\u00e7\u00e3o.<\/p>\n

Agrupamento<\/h4>\n

P: Em um bucket com r\u00e9plica e failover autom\u00e1tico, uma falha no servidor sem rebalanceamento causar\u00e1 erros de recupera\u00e7\u00e3o\/atualiza\u00e7\u00e3o nesse bucket?<\/p>\n

R: Quando um servidor falhar inicialmente (por qualquer motivo: hardware, rede, software), o aplicativo receber\u00e1 brevemente erros para todos os dados pelos quais esse servidor era respons\u00e1vel. As solicita\u00e7\u00f5es de dados em outros servidores n\u00e3o ser\u00e3o afetadas. Esses erros continuar\u00e3o at\u00e9 que ocorra a \"falha\" do n\u00f3, o que ativa os dados de r\u00e9plica (vbuckets) em outro local do cluster. O tempo varia de acordo com o uso de failover autom\u00e1tico ou manual... mas quando o failover \u00e9 acionado, n\u00e3o h\u00e1 mais atraso. Voc\u00ea pode se perguntar \"mas por que n\u00e3o posso ler os dados da r\u00e9plica que j\u00e1 existe?\". A resposta \u00e9 dupla. Em primeiro lugar, proibimos especificamente o acesso aos dados da r\u00e9plica (enquanto ela \u00e9 \"r\u00e9plica\") para preservar a consist\u00eancia muito forte que nosso sistema oferece. Em opera\u00e7\u00e3o normal, voc\u00ea tem a garantia de \"ler suas pr\u00f3prias grava\u00e7\u00f5es\" e isso \u00e9 feito fornecendo apenas um local para acessar qualquer dado. Ao permitir a leitura irrestrita de r\u00e9plicas, voc\u00ea pode ter uma situa\u00e7\u00e3o em que um cliente grava um dado na c\u00f3pia ativa e outro cliente tenta imediatamente ler esse dado da r\u00e9plica... levando a uma poss\u00edvel inconsist\u00eancia. Agora, a segunda parte dessa resposta \u00e9 que estamos trabalhando atualmente em um recurso para permitir a leitura dessas r\u00e9plicas. Ser\u00e1 uma nova opera\u00e7\u00e3o invocada explicitamente pelo aplicativo para que n\u00e3o haja confus\u00e3o sobre de qual c\u00f3pia est\u00e1 sendo lida. Voc\u00ea ainda desejar\u00e1 fazer o failover do n\u00f3 o mais r\u00e1pido poss\u00edvel, pois as grava\u00e7\u00f5es continuar\u00e3o a falhar. Esse \u00e9 um exemplo dos muitos recursos que adicionamos como resposta direta \u00e0s demandas de nossos clientes e usu\u00e1rios... voc\u00ea fala e n\u00f3s ouvimos (e depois fazemos algo a respeito tamb\u00e9m)!<\/p>\n

P: H\u00e1 algum efeito\/risco\/tempo ao rebalancear um sistema sob cargas pesadas de grava\u00e7\u00e3o? \u00c9 melhor adicionar n\u00f3s em \u00e9pocas de bastante movimento?<\/p>\n

R: Por padr\u00e3o, a opera\u00e7\u00e3o de rebalanceamento \u00e9 feita de forma ass\u00edncrona para causar o m\u00ednimo poss\u00edvel de impacto no desempenho do cluster. No entanto, a realidade \u00e9 que o rebalanceamento aumenta a carga no cluster e requer recursos para faz\u00ea-lo (rede, disco, RAM, CPU). Se o cluster j\u00e1 estiver perto da capacidade, qualquer aumento de carga poder\u00e1 afetar o desempenho do aplicativo. Embora seja seguro fazer isso a qualquer momento, \u00e9 altamente recomend\u00e1vel realizar seus pr\u00f3prios testes em seu pr\u00f3prio ambiente para caracterizar qual ser\u00e1 o impacto, se houver algum, de um rebalanceamento. Normalmente, nossos clientes realizam esses testes em momentos de baixa ou tranquilidade, mas a principal vantagem \u00e9 que voc\u00ea n\u00e3o precisa deixar o aplicativo completamente off-line enquanto continua a escalonar.<\/p>\n

P: O que \u00e9 um vbucket?<\/p>\n

R: Um vbucket \u00e9 a nossa maneira de particionar logicamente os dados para que possam ser distribu\u00eddos em todos os n\u00f3s de um cluster. Cada bucket do tipo Couchbase que \u00e9 criado no cluster \u00e9 automaticamente (e de forma transparente) dividido em um conjunto est\u00e1tico de fatias (os vbuckets). Esses s\u00e3o ent\u00e3o \"mapeados\" para servidores individuais. Quando um n\u00f3 \u00e9 adicionado ou removido, s\u00e3o essas fatias que s\u00e3o movidas e mapeadas novamente para proporcionar um dimensionamento linear e sem interrup\u00e7\u00f5es. Embora totalmente abstra\u00eddos do aplicativo e do usu\u00e1rio, \u00e9 importante perceber que os vbuckets existem \"por baixo do pano\" para fornecer muitos dos recursos maravilhosos do Couchbase Server. Voc\u00ea pode saber mais sobre o conceito de vbucket.<\/p>\n

Monitoramento<\/h4>\n

P: A interface do usu\u00e1rio da Web do Couchbase Server \u00e9 o \u00fanico m\u00e9todo de monitoramento de um cluster do Couchbase Server?<\/p>\n

R: N\u00e3o necessariamente, n\u00e3o. Tudo o que voc\u00ea v\u00ea e pode fazer na interface do usu\u00e1rio da Web \u00e9, na verdade, orientado pela nossa interface REST, que pode ser acessada externamente de forma program\u00e1tica. Al\u00e9m disso, cada servidor individual (e cada bucket individual nesse servidor) fornece suas pr\u00f3prias estat\u00edsticas \"brutas\" que s\u00e3o usadas pela API REST. Essas estat\u00edsticas brutas tamb\u00e9m est\u00e3o dispon\u00edveis externamente:<\/p>\n

Nosso objetivo \u00e9 fornecer o m\u00e1ximo poss\u00edvel de informa\u00e7\u00f5es sobre o sistema para que nossos usu\u00e1rios possam monitor\u00e1-lo de forma eficaz, tanto do ponto de vista do planejamento de capacidade quanto do ponto de vista de diagn\u00f3stico\/solu\u00e7\u00e3o de problemas quando as coisas come\u00e7arem a dar errado (ou para evitar que as coisas deem errado em primeiro lugar).<\/p>\n

P: Que tipo de alerta o Couchbase Server oferece?<\/p>\n

R: Tecnicamente, n\u00e3o somos uma empresa que fabrica software de alerta. Em nossa opini\u00e3o, nosso trabalho \u00e9 fornecer uma interface para que outros sistemas fa\u00e7am uso dela. A maioria das grandes organiza\u00e7\u00f5es n\u00e3o gostaria que cada parte da tecnologia em sua pilha enviasse um conjunto de alertas com formatos diferentes. \u00c9 por isso que tornamos t\u00e3o f\u00e1cil conectar nossas estat\u00edsticas e dados de monitoramento a qualquer outro sistema. No entanto, tamb\u00e9m percebemos que alguns ambientes menores podem, de fato, querer que nosso software forne\u00e7a isso imediatamente. Estamos trabalhando para ampliar nossos recursos aqui e j\u00e1 fornecemos alertas para quando os n\u00f3s caem.<\/p>\n

Autocompacta\u00e7\u00e3o<\/h4>\n

P: Se voc\u00ea abortar a compacta\u00e7\u00e3o no final do per\u00edodo de tempo, a compacta\u00e7\u00e3o feita at\u00e9 esse ponto ainda ser\u00e1 salva ou toda a compacta\u00e7\u00e3o feita at\u00e9 o momento ser\u00e1 perdida?<\/p>\n

R: Normalmente, uma compacta\u00e7\u00e3o \u00e9 do tipo tudo ou nada e, portanto, abort\u00e1-la perder\u00e1 o progresso que foi feito at\u00e9 o momento. No entanto, no Couchbase Server, estamos executando a compacta\u00e7\u00e3o 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.<\/p>\n

Autofailover<\/h4>\n

P: Por que h\u00e1 um atraso antes que o cluster fa\u00e7a o failover autom\u00e1tico de um n\u00f3 inoperante?<\/p>\n

R: Por padr\u00e3o, o software \u00e9 configurado com um m\u00ednimo de 30 segundos antes que o failover autom\u00e1tico seja ativado. Isso foi projetado para evitar que o software fa\u00e7a a \"coisa errada\". Por exemplo, se um n\u00f3 estiver simplesmente lento para responder ou se houver um breve solu\u00e7o na rede, voc\u00ea n\u00e3o desejar\u00e1 que ele sofra um failover e, portanto, o cluster aguardar\u00e1 para garantir que o n\u00f3 esteja realmente inoperante.<\/p>\n

Para obter ainda mais informa\u00e7\u00f5es, voc\u00ea pode assistir aos v\u00eddeos de 25 a 30 minutos do webinar de cada semana acessando aqui. E o local de refer\u00eancia para todas as informa\u00e7\u00f5es sobre o Couchbase Server 2.0 pode ser encontrado aqui. Embora essa s\u00e9rie possa ter chegado ao fim, j\u00e1 estamos planejando iniciar outra para destacar n\u00e3o apenas os recursos do Couchbase Server 2.0, mas tamb\u00e9m o Couchbase Mobile, nossos SDKs\/bibliotecas de clientes e muito mais! Alguns dos t\u00f3picos incluir\u00e3o:<\/p>\n