Em nossa s\u00e9rie de treinamentos cont\u00ednuos, v\u00e1rias perguntas surgem a cada vez, e eu as relaciono com suas respectivas respostas abaixo!<\/p>\n
Couchbase 103 - Modelagem de documentos<\/span><\/p>\n P: Supondo que voc\u00ea possa armazenar um documento como XML em vez de JSON, o que voc\u00ea acha de um em rela\u00e7\u00e3o ao outro para o Couchbase?<\/strong><\/p>\n R: Voc\u00ea pode armazenar XML, assim como podemos armazenar cadeias de caracteres. No entanto, \u00e9 dif\u00edcil fazer exibi\u00e7\u00f5es Map-Reduce para index\u00e1-las e consult\u00e1-las, pois n\u00e3o analisamos o XML no lado do servidor para poder usar a nota\u00e7\u00e3o de ponto como no JSON. O XML n\u00e3o \u00e9 nativo do javascript. A extens\u00e3o E4X para analisar XML n\u00e3o faz parte do mecanismo V8 que usamos no Couchbase para processar as fun\u00e7\u00f5es de mapa javascript.<\/p>\n P: Podemos fazer inser\u00e7\u00f5es\/atualiza\u00e7\u00f5es em massa no Couchbase?<\/strong><\/p>\n R: Normalmente, voc\u00ea faz isso da mesma forma que faz qualquer opera\u00e7\u00e3o CRUD com o Couchbase, usando os SDKs. Temos uma ferramenta de linha de comando que pode ler arquivos JSON do disco, cbtransfer. Recomendo o uso de uma VM r\u00e1pida (por exemplo, Java\/C\/C++\/Go em vez de Ruby) e a paraleliza\u00e7\u00e3o do trabalho se houver uma grande quantidade de documentos.<\/p>\n P: Voc\u00ea n\u00e3o est\u00e1 voltando ao padr\u00e3o \"relacional\" quando usa o padr\u00e3o de v\u00e1rios documentos?<\/strong><\/p>\n R: N\u00e3o necessariamente, \u00e9 mais uma separa\u00e7\u00e3o de preocupa\u00e7\u00f5es, mas ainda n\u00e3o h\u00e1 jun\u00e7\u00f5es. Trata-se apenas de isolar os comportamentos do usu\u00e1rio em documentos separados, n\u00e3o de normaliza\u00e7\u00e3o. H\u00e1 uma grande diferen\u00e7a entre os dois. Em vez de ter um documento para muitos comportamentos de usu\u00e1rio, voc\u00ea est\u00e1 isolando os documentos por chave para comportamentos de usu\u00e1rio espec\u00edficos e ainda armazenando dados desnormalizados. O que estamos conseguindo com o uso de JSON em vez de tabelas e de dados desnormalizados em vez de normalizados \u00e9 a capacidade de distribuir dados. Quando voc\u00ea tem tabelas normalizadas, a distribui\u00e7\u00e3o de dados e a computa\u00e7\u00e3o de jun\u00e7\u00f5es s\u00e3o muito desafiadoras. Voc\u00ea n\u00e3o pode dividir facilmente tabelas grandes em v\u00e1rios servidores e, quando o faz, a computa\u00e7\u00e3o de jun\u00e7\u00f5es exige a agrega\u00e7\u00e3o de tabelas grandes em v\u00e1rios servidores, o que ser\u00e1 pesado em termos de computa\u00e7\u00e3o e transfer\u00eancia de dados e n\u00e3o poder\u00e1 sustentar muitas consultas. \u00c9 claro que a l\u00f3gica das opera\u00e7\u00f5es CRUD em uma situa\u00e7\u00e3o de RDBMS distribu\u00eddo \u00e9 igualmente complexa.<\/p>\n P: Com base em sua experi\u00eancia, qual \u00e9 a melhor maneira de garantir, tanto quanto poss\u00edvel, que um item seja referido com o mesmo nome em todo o banco de dados?<\/strong><\/p>\n R: Em primeiro lugar, escolha caracter\u00edsticas imut\u00e1veis para as chaves, de modo que os IDs referenciais dentro do documento JSON n\u00e3o precisem ser atualizados. Se voc\u00ea precisar alterar uma chave que tenha sido referenciada em outros documentos, provavelmente ter\u00e1 de criar uma visualiza\u00e7\u00e3o para localizar e atualizar esses documentos ap\u00f3s a altera\u00e7\u00e3o da chave.<\/p>\n P: Voc\u00ea observou que uma das vantagens do CB \u00e9 a linha reta entre o aplicativo e os dados, pois eles s\u00e3o armazenados no banco de dados, ou seja, n\u00e3o h\u00e1 incompatibilidade de imped\u00e2ncia. Wque se o aplicativo mudar e dados diferentes forem usados em p\u00e1ginas diferentes, ou (ainda pior) quando v\u00e1rios aplicativos estiverem analisando os mesmos dados. Ent\u00e3o, a abordagem RDBMS n\u00e3o \u00e9 melhor? ou voc\u00ea ainda a defenderia? Em caso afirmativo, por qu\u00ea?<\/span><\/strong><\/p>\n R: Se partes diferentes de um documento JSON forem usadas em p\u00e1ginas diferentes, isso n\u00e3o ser\u00e1 um problema. Se diferentes comportamentos de usu\u00e1rio modificarem o mesmo documento e houver uma oportunidade para condi\u00e7\u00f5es de corrida, voc\u00ea poder\u00e1 usar opera\u00e7\u00f5es CAS ou separar os documentos em v\u00e1rios. Se v\u00e1rios aplicativos estiverem analisando os mesmos dados, isso tamb\u00e9m n\u00e3o ser\u00e1 um problema. Se esses aplicativos forem de terceiros e puderem fazer grava\u00e7\u00f5es nos dados, \u00e9 melhor que eles passem por uma API para que a formata\u00e7\u00e3o das chaves JSON e outras valida\u00e7\u00f5es possam ser feitas para manter a formata\u00e7\u00e3o e a integridade dos dados. Nos sistemas RDBMS, voc\u00ea depende do banco de dados para fazer a valida\u00e7\u00e3o de tipo; essa responsabilidade passa do banco de dados para a camada de aplicativos com o Couchbase. Isso \u00e9 resolvido com bastante facilidade e, de qualquer forma, \u00e9 uma pr\u00e1tica melhor fazer com que os aplicativos de terceiros passem por uma API em vez de irem diretamente para o banco de dados. Mesmo no caso de v\u00e1rios aplicativos interagindo com o mesmo banco de dados, o uso de SOA tamb\u00e9m pode ser uma arquitetura melhor.<\/span><\/p>\n P: Como voc\u00ea \"encontra\" o tamanho (em termos de bytes no disco, por exemplo) de um determinado documento?<\/strong><\/p>\n R: N\u00e3o temos uma maneira de fazer isso para documentos individuais. Os documentos s\u00e3o compactados em disco, usando o Snappy, portanto, voc\u00ea pode obter uma taxa de compacta\u00e7\u00e3o m\u00e9dia do tamanho do documento do lado do cliente (json bruto n\u00e3o compactado) e, em seguida, obter uma compacta\u00e7\u00e3o arbitr\u00e1ria de 40% para ver o espa\u00e7o ocupado em disco. Ou voc\u00ea pode fazer uma m\u00e9dia observando o n\u00famero de itens (documentos), pegando o uso do disco e dividindo-o para ver o tamanho m\u00e9dio do documento no disco.<\/p>\n P: Como \"atualizar\" o(s) item(ns) json, por exemplo, o carimbo de data\/hora da atualiza\u00e7\u00e3o do documento, usando qualquer forma, mas n\u00e3o manualmente?<\/strong><\/p>\n R: N\u00e3o h\u00e1 mecanismo autom\u00e1tico para atualizar chaves json individuais em um documento json. Documentos inteiros s\u00e3o transmitidos para frente e para tr\u00e1s com opera\u00e7\u00f5es CRUD. Se voc\u00ea estiver atualizando qualquer chave json com um novo valor, isso ser\u00e1 feito no lado do cliente, incluindo, entre outros, a atualiza\u00e7\u00e3o de um carimbo de data\/hora.<\/p>\n P: Como voc\u00ea lida com as atualiza\u00e7\u00f5es de dados, isso n\u00e3o consumir\u00e1 muito tempo?<\/strong><\/p>\n R: Se voc\u00ea estiver se referindo apenas \u00e0 atualiza\u00e7\u00e3o do documento JSON, \u00e9 claro que a opera\u00e7\u00e3o de substitui\u00e7\u00e3o em sub-milissegundos n\u00e3o \u00e9 o que voc\u00ea est\u00e1 falando. Portanto, tive de presumir, para responder a essa pergunta, que voc\u00ea est\u00e1 se referindo \u00e0 migra\u00e7\u00e3o de uma estrutura de documento JSON para outra, como um documento de usu\u00e1rio que tem algumas chaves JSON e que voc\u00ea deseja adicionar\/remover\/transformar. Como mencionei no webinar, voc\u00ea pode fazer isso de v\u00e1rias maneiras. \u00c9 claro que ele assume duas formas diferentes: uma delas \u00e9 o estilo de trabalho em lote\/cron, em que voc\u00ea itera pelos documentos e faz a transforma\u00e7\u00e3o\/muta\u00e7\u00e3o. O tempo que isso leva depende do tamanho do seu conjunto de dados, de quantas m\u00e1quinas est\u00e3o no cluster do Couchbase e de quantas m\u00e1quinas est\u00e3o fazendo as transforma\u00e7\u00f5es. Portanto, \"demorado\" \u00e9 uma avalia\u00e7\u00e3o relativa. A outra maneira de lidar com isso seria transformar os documentos \"sob demanda\", ou seja, quando eles s\u00e3o recuperados pelo uso normal do seu aplicativo. Por exemplo, quando um usu\u00e1rio faz um login, voc\u00ea pode recuperar o documento do usu\u00e1rio, transform\u00e1-lo e substitu\u00ed-lo no Couchbase.<\/p>\n P: O que Jasdeep n\u00e3o mencionou \u00e9 que os dados precisam residir na mem\u00f3ria (pelo menos para justificar a velocidade). Ent\u00e3o, qual \u00e9 a vantagem sobre um banco de dados relacional na mem\u00f3ria que suporta SQL avan\u00e7ado? Eles tamb\u00e9m fazem um bom clustering ...<\/strong><\/p>\n R: Se voc\u00ea estiver fazendo um \u00fanico n\u00f3 em escala vertical de um banco de dados relacional na mem\u00f3ria, o limite ser\u00e1 a escala vertical dessa \u00fanica m\u00e1quina. Quando voc\u00ea tiver mais de um servidor e jun\u00e7\u00f5es (e particularmente jun\u00e7\u00f5es distribu\u00eddas), encontrar\u00e1 gargalos de desempenho semelhantes aos ancestrais vinculados a disco, puramente por causa da f\u00edsica. Se voc\u00ea fizer uma uni\u00e3o por meio de uma conex\u00e3o de rede em muitas tabelas grandes, n\u00e3o importa como voc\u00ea a fa\u00e7a, ela ser\u00e1 lenta e, se voc\u00ea a fizer com frequ\u00eancia, todo o desempenho ser\u00e1 degradado em escala.<\/p>\n P: Em um padr\u00e3o Counter-ID para usu\u00e1rios, onde residir\u00e1 o valor da contagem de usu\u00e1rios?<\/strong><\/p>\n R: \u00c9 um valor inteiro positivo simples com uma chave, como \"user::count\". Certifique-se de incrementar apenas o contador! E siga-o com uma opera\u00e7\u00e3o de adi\u00e7\u00e3o em vez de um conjunto, dessa forma, se houver um erro de l\u00f3gica, voc\u00ea o detectar\u00e1.<\/p>\n P: Como voc\u00ea faria um MapReduce de \u00edndice reverso (invertido)?<\/strong><\/p>\n R: Esse assunto est\u00e1 mais no t\u00f3pico do webinar Couchbase 104: Views. Mas os \u00edndices reversos s\u00e3o complicados com o Map-Reduce, voc\u00ea pode cri\u00e1-los emitindo a tag para quando ela ocorrer e, em seguida, fazer uma consulta de intervalo para essa tag.<\/p>\n P: Quando voc\u00ea divide documentos em v\u00e1rios documentos?<\/strong><\/p>\n R: Em geral, h\u00e1 tr\u00eas motivos para pensar em dividir um documento em v\u00e1rios documentos. O primeiro \u00e9 que uma determinada a\u00e7\u00e3o do usu\u00e1rio pode modificar um documento que tamb\u00e9m pode ser modificado por outra a\u00e7\u00e3o do usu\u00e1rio (e ambas s\u00e3o frequentes). Se v\u00e1rios usu\u00e1rios puderem modificar o mesmo documento em um determinado momento (ou quase provavelmente simultaneamente), isso \u00e9 uma \"condi\u00e7\u00e3o de corrida\" e voc\u00ea deve isolar esse documento e usar opera\u00e7\u00f5es CAS. O segundo caso \u00e9 quando um \u00fanico documento pode ser \"inchado\" ou muito grande e, nesse caso, pode ser mais eficiente dividi-lo em termos de c\u00f3digo e manuten\u00e7\u00e3o de c\u00f3digo. Em terceiro lugar, se voc\u00ea estiver usando um contador at\u00f4mico para representar um componente espec\u00edfico de um objeto\/classe. Isso ter\u00e1 que ser seu pr\u00f3prio par chave-valor, independente do documento JSON prim\u00e1rio, \u00e9 claro.<\/p>\n P: Como voc\u00ea faria uma pesquisa se tivesse um ID de navio e Lat\/Long e quisesse pesquisar por qualquer um dos par\u00e2metros?<\/strong><\/p>\n R: Nesse caso, como as coordenadas geogr\u00e1ficas t\u00eam precis\u00e3o de tr\u00eas casas decimais, nenhum padr\u00e3o de chave o ajudar\u00e1 com isso. No entanto, temos duas op\u00e7\u00f5es para fazer buscas do tipo de informa\u00e7\u00e3o que voc\u00ea deseja. Nossas visualiza\u00e7\u00f5es gerais Map\/Reduce s\u00e3o mais do que satisfat\u00f3rias, mas tamb\u00e9m temos visualiza\u00e7\u00f5es especializadas com Geo. Elas permitem a pesquisa em caixas delimitadas e outras t\u00e9cnicas geogr\u00e1ficas mais avan\u00e7adas. N\u00e3o falo especificamente sobre isso no webinar Couchbase 104: Views, mas entre em contato comigo se estiver interessado em saber mais ou se precisar de ajuda com rela\u00e7\u00e3o ao Geo e ao Couchbase.<\/p>\n P: Contar os usu\u00e1rios \u00e9 uma maneira melhor (com a fun\u00e7\u00e3o .incr()) de criar o ID do usu\u00e1rio do que, por exemplo, um grande n\u00famero aleat\u00f3rio ou um GUID? Estou falando do caso em que pode haver muitos novos usu\u00e1rios por segundo. A contagem n\u00e3o causar\u00e1 mais conflitos do que uma grande chave aleat\u00f3ria que tem uma probabilidade muito baixa de conflito?<\/strong><\/p>\n R: Como os contadores at\u00f4micos s\u00e3o, bem, at\u00f4micos, ent\u00e3o voc\u00ea pode contar com eles (em um \u00fanico cluster) para serem executados em ordem. Se todos os seus servidores de aplicativos estiverem apontando para esse cluster, todos eles estar\u00e3o executando opera\u00e7\u00f5es incr simultaneamente. Mas como elas s\u00e3o at\u00f4micas, cada opera\u00e7\u00e3o de cada servidor de aplicativos executando opera\u00e7\u00f5es gerar\u00e1 um novo n\u00famero inteiro, portanto, todas ser\u00e3o exclusivas. Se voc\u00ea nunca usar uma opera\u00e7\u00e3o decr (diminuir), n\u00e3o ter\u00e1 problemas. A situa\u00e7\u00e3o fica um pouco mais complexa se voc\u00ea tiver v\u00e1rios data centers e estiver usando XDCR (Cross Data Center Replication). Nesses casos, \u00e9 melhor prefixar seus contadores pelo ID do data center (que voc\u00ea criou).<\/p>\n P: Estou usando a gem couchbase-model no Rails e estou tendo dificuldades para entender o Counter-ID e o namespacing das chaves no paradigma do Rails, por exemplo, usando o m\u00e9todo Object.find() ou acessando\/incrementando refdocs n\u00e3o-JSON. Voc\u00ea poderia postar um exemplo que misture e combine o Counter-ID com o Rails, incluindo o incremento a partir do bucket do Model?<\/strong><\/p>\n R: Isso precisar\u00e1 de algo melhor do que um blog para ser mostrado. Vou pensar em uma maneira de montar um resumo e postar um link aqui. Mas me d\u00ea um pouco de tempo para fazer isso. :)<\/p>\n P: Existe uma maneira de obter v\u00e1rios documentos para diferentes ids. O exemplo em que estou pensando \u00e9 uma lista de IDs de usu\u00e1rios do Facebook que queremos mapear para seus documentos de usu\u00e1rio. Existe uma maneira de passar v\u00e1rios IDs do Facebook e receber de volta uma matriz de documentos?<\/strong><\/p>\n R: Temos uma opera\u00e7\u00e3o multi-get em cada sdk apenas para essa finalidade. Na matriz resultante, se o documento n\u00e3o existir, ele ter\u00e1 um elemento null\/nill para indicar isso (talvez o Java tenha um retorno diferente, terei de verificar, mas sei que ele tamb\u00e9m tem).<\/p>\n P: As visualiza\u00e7\u00f5es s\u00e3o a \u00fanica maneira de usar chaves compostas? Existe uma maneira de us\u00e1-las com chaves get ou setup para usar esse tipo de funcionalidade sem uma visualiza\u00e7\u00e3o? https:\/\/www.couchbase.com\/blog\/understanding-grouplevel-view-queries-compound-keys<\/a>\u00a0<\/strong><\/p>\n R: Esse \u00e9 mais um t\u00f3pico para o Couchbase 104: Visualiza\u00e7\u00f5es e indexa\u00e7\u00e3o, mas basicamente uma chave pode ser o que voc\u00ea quiser, portanto, tecnicamente, sim, voc\u00ea pode ter uma chave composta (depende apenas de como voc\u00ea define composta). No entanto, o link ao qual voc\u00ea est\u00e1 se referindo est\u00e1 focado na consulta de um \u00edndice de visualiza\u00e7\u00e3o, e esses tamb\u00e9m t\u00eam chaves, chaves de \u00edndice, com as quais constru\u00edmos nossas \u00e1rvores B+. Nesse caso, voc\u00ea est\u00e1 pegando partes da chave e dividindo-as com base no delimitador \",\" (v\u00edrgula). Estamos falando de um assunto diferente.<\/p>\n P: No momento, estamos usando uma exibi\u00e7\u00e3o para pesquisar o ID de usu\u00e1rio do Facebook para obter nosso pr\u00f3prio ID de usu\u00e1rio do aplicativo. Parece que, se realmente usarmos o padr\u00e3o de pesquisa que voc\u00ea sugeriu, isso pode ser mais r\u00e1pido do que usar uma visualiza\u00e7\u00e3o?<\/strong><\/p>\n R: Sim, e \u00e9 claro que isso depende. A escala tamb\u00e9m \u00e9 um fator aqui. Quanto mais n\u00f3s houver no cluster, mais amplo ser\u00e1 o processo de coleta e dispers\u00e3o da consulta do View, ou seja, mais n\u00f3s ter\u00e3o de ser dispersos e coletados em termos de resultados da consulta do View. Portanto, apenas pela f\u00edsica, a pesquisa ser\u00e1 mais r\u00e1pida. A desvantagem \u00e9 que voc\u00ea est\u00e1 adicionando mais documentos e, portanto, mais requisitos de RAM\/metadados, mas, como resultado, est\u00e1 ganhando uma tremenda escalabilidade, porque as opera\u00e7\u00f5es bin\u00e1rias passam por uma conex\u00e3o persistente com um servidor para o facebook_id->app_user_id e, novamente, uma segunda opera\u00e7\u00e3o bin\u00e1ria para o mesmo ou outro n\u00f3 por meio de uma conex\u00e3o persistente sempre ser\u00e1 mais r\u00e1pida do que espalhar uma consulta View por todos os n\u00f3s e coletar os resultados. As visualiza\u00e7\u00f5es s\u00e3o muito poderosas porque s\u00e3o mais flex\u00edveis do que os padr\u00f5es de chave; entretanto, nesse cen\u00e1rio, opte pela velocidade.<\/p>\n P: As exibi\u00e7\u00f5es t\u00eam uma op\u00e7\u00e3o obsoleta que parece poder atenuar o problema de const\u00e2ncia em compara\u00e7\u00e3o com duas chamadas get separadas. \u00c9 realmente mais r\u00e1pido ter duas chamadas para o banco de dados do que uma visualiza\u00e7\u00e3o bem gerenciada? Eu poderia me preocupar com a escala, duas chamadas em vez de uma em uma visualiza\u00e7\u00e3o.<\/strong><\/p>\n R: Isso n\u00e3o atenua o problema de consist\u00eancia. Os \u00edndices s\u00e3o sempre consistentes no Couchbase (at\u00e9 que n\u00f3s mesmos os desenvolvamos, o que est\u00e1 no radar), mas veja a pergunta\/resposta acima e assista a Couchbase 104: Views and Indexes! Isso pode mudar sua opini\u00e3o.<\/p>\n P: No exemplo que voc\u00ea est\u00e1 demonstrando, estamos discutindo sobre um \u00fanico documento e seus atributos\/propriedades via JSON.\u00a0Como lidamos com o fato de voc\u00ea querer obter estat\u00edsticas\/contagem em v\u00e1rios objetos\/documentos?\u00a0<\/span>Por exemplo: a)\u00a0<\/span>me traga todos os usu\u00e1rios com a cor favorita azul? b)\u00a0<\/span>me informar todos os usu\u00e1rios que usam cart\u00e3o de cr\u00e9dito Visa?<\/span><\/strong><\/p>\n R: Isso requer visualiza\u00e7\u00f5es e a t\u00e9cnica Map\/Reduce para reunir todos esses elementos de dados de documentos e coloc\u00e1-los em uma estrutura de \u00edndice para que voc\u00ea possa fazer consultas como essas. Esse \u00e9 um bom exemplo de coisas que voc\u00ea n\u00e3o pode realmente fazer com padr\u00f5es-chave e requer integra\u00e7\u00e3o com VIews e\/ou Elastic Search. Nesses cen\u00e1rios de que voc\u00ea est\u00e1 falando, voc\u00ea poderia usar qualquer uma das solu\u00e7\u00f5es.<\/p>\n P: *Require* views\/map-reduce? Que tal armazenar o segundo documento u::uuid { email:user@domain.com } para depois acessar u:user@domain.com? Quando isso deve ser feito por meio de view\/map-reduce?<\/strong><\/p>\n R: Essa pergunta estava se referindo ao que acontece sem um padr\u00e3o Lookup. Se voc\u00ea tiver chaves de documento geradas aleatoriamente, normalmente precisar\u00e1 criar um \u00edndice para poder pesquisar documentos por meio de diferentes propriedades JSON. No entanto, se voc\u00ea criar um padr\u00e3o Lookup, poder\u00e1 fazer uma busca dupla para obter o documento principal; a primeira busca ser\u00e1 baseada em informa\u00e7\u00f5es conhecidas (endere\u00e7o de e-mail), o valor ser\u00e1 o ID gerado aleatoriamente que est\u00e1 associado ao documento principal; a segunda busca usar\u00e1 esse valor e obter\u00e1 o documento principal.<\/p>\n P: Qual \u00e9 a melhor maneira de consultar esses documentos de notifica\u00e7\u00e3o?<\/strong><\/p>\n