Couchbasics: como as necessidades funcionais e de desempenho determinam o acesso aos dados no Couchbase

Há várias maneiras de obter dados dentro e fora do Couchbase. Observe que eu não disse consultar, eu disse entrar e sair... de propósito. Nem todas as formas de obter dados dentro e fora do Couchbase são consultas, como em outros bancos de dados. O Couchbase oferece várias maneiras que proporcionam diferentes recursos/funcionalidades e características de desempenho que você pode misturar e combinar para atender às necessidades do seu aplicativo. Vamos listar os diferentes padrões de acesso a dados do Couchbase e, em seguida, vamos nos aprofundar na aplicação prática de cada um deles.

1. Leitura/gravação de dados por ID de objeto (chave)
2. Ler dados de uma visualização
3. Ler/gravar/atualizar dados usando N1QL
4. Pesquisa de texto completo via Solr ou Elastic

Quando e onde usar cada método

Com a introdução do N1QL (pronuncia-se "nickel") e dos serviços de consulta e índice no Couchbase na versão 4.0, o Couchbase ganha um novo nível de funcionalidade. O N1QL traz conformidade quase total com o SQL ANSI-92. (Digo quase, pois o N1QL deixa de fora recursos que são úteis em um banco de dados relacional, mas não em um banco de dados de documentos. Inversamente, ele tem recursos que são necessários para um banco de dados de documentos, mas não são apropriados para o relacional. Em outros termos, ele é um subconjunto e um superconjunto do SQL ANSI-92). Mas vamos deixar claro que o N1QL é NÃO deve e deve NÃO substitui os outros meios de ler e gravar dados que o Couchbase tinha antes da versão 4.0. Ele simplesmente oferece mais uma maneira de acessar os dados.

Com a introdução do N1QL, a necessidade do Solr e do Elastic diminuiu, pois o Couchbase oferece suporte à consulta completa para a qual a maioria das pessoas usava essas duas ferramentas. Elas ainda são necessárias se o seu aplicativo precisar de pesquisa de texto completo. Ambas as plataformas têm excelente integração com o Couchbase para fornecer essa funcionalidade.

Cada um dos quatro meios de acesso aos dados é uma ferramenta da sua caixa de ferramentas e cada um deles tem uma finalidade diferente. Cada ferramenta deve ser usada de acordo com as necessidades funcionais e de desempenho do caso de uso. Lembre-se de que essas ferramentas não são uma situação de um ou outro. Você pode misturar e combinar essas ferramentas a seu favor. Por exemplo, você pode consultar uma visualização que emite IDs de objetos e, em seguida, usar esses IDs com um BulkGet paralelizado usando o SDK do Couchbase para ler todos esses objetos ou simplesmente criar/ler/atualizar/excluir (CRUD) em todos esses objetos, o que será muito rápido. Portanto, juntas, essas ferramentas oferecem maneiras padrão e escalonáveis que qualquer pessoa pode usar para obter dados dentro e fora do Couchbase com facilidade e flexibilidade.

Mas vamos nos aprofundar nos detalhes...

Leitura/gravação de dados por ID de objeto (chave)

Em sua essência, o Couchbase é um banco de dados de chave/valor incrível e sempre foi. O acesso por meio de ID de objeto também é um dos conceitos mais difíceis do Couchbase para as pessoas entenderem rapidamente e usá-lo com sabedoria (por isso a extensão desta seção). Quando compreendem seu poder, elas percebem o que ele pode oferecer e como podem aplicar essa ferramenta. O acesso por meio do ID do objeto é a fera incompreendida e poderosa no canto. Portanto, vamos entender melhor essa fera e como podemos aproveitá-la em nosso benefício.

Antes de começarmos, deixe-me esclarecer que o acesso aos dados por meio do ID do objeto (chave) será sempre ser mais rápido do que a consulta. É a diferença entre saber a resposta para obter seus dados e ter que fazer uma pergunta (consulta) para encontrar esses dados. Digamos que você entre em uma biblioteca e precise de um livro específico. Se souber o ID do livro, você vai ao andar um, fila três, prateleira quatro, terceiro livro a partir da direita. Você vai até lá, pega o livro, faz o checkout e sai. Se não tiver o ID do livro, você pode perguntar ao bibliotecário ou ao computador, fornecer as informações que possui (autor, título etc.) e eles o levarão ao local para pegar o livro ou, pior ainda, você examinará todos os livros e acabará encontrando-o. Quando você sabe o ID do objeto, não há necessidade de uma pesquisa indexada dos seus dados; basta obter os dados de que precisa diretamente do cache gerenciado do Couchbase. Ele é extremamente rápido, com tempos de acesso muito consistentes e latência muito baixa. Portanto, certifique-se de não comparar seu desempenho com os outros métodos de acesso, pois cada um deles atende a necessidades funcionais diferentes.

Agora, você pode dizer sobre o acesso por chave/valor: "meh, eu preciso de consulta!" Talvez sim e talvez não. No Couchbase, o acesso aos dados com o ID do objeto pode ser muito poderoso, pois o ID do objeto pode ter no máximo 250 bytes e, dependendo de como você usa o ID do objeto, ele pode permitir que você evite a consulta. O verdadeiro poder do que você pode fazer com esse ID de objeto é quando você usa um padrão padronizado para cada ID de objeto que seu aplicativo pode construir para buscar os dados exatos de que precisa, quando necessário. Pense no ID do objeto como uma extensão de sua modelagem geral de objetos. Combine tudo isso com a arquitetura do Couchbase e você terá certeza de que seu aplicativo obterá os dados de que precisa o mais rápido possível a partir do cache gerenciado incorporado. No entanto, é preciso ter cuidado. Por padrão, o Couchbase armazenará todos os IDs de objeto para cada objeto no cache gerenciado por motivos de desempenho. Portanto, não exagere com chaves grandes. Por exemplo, se você tiver 250 milhões de objetos multiplicados por 250 bytes de dados, serão necessários cerca de 58 GB de RAM em todo o cluster, apenas para as chaves. Portanto, só porque você pode ter uma chave de 250 bytes, não significa que deva. Em escala séria, isso pode se tornar um problema, portanto, eu recomendaria mantê-las abaixo de 100.

A arquitetura do Couchbase com as camadas combinadas de cache e persistência é excelente em padrões de acesso a dados que podem ser prejudiciais para outros bancos de dados, especialmente os relacionais. A leitura de vários objetos diretamente do cache gerenciado é consideravelmente mais rápida do que nos bancos de dados tradicionais. E com outros bancos de dados, você precisa restringir as viagens de ida e volta para o banco de dados. Com o Couchbase, você pode ler um documento, obter dados dele e, em seguida, ler mais objetos com base nisso, tudo no mesmo tempo total ou até menos do que é necessário para que outros bancos de dados façam apenas essa consulta e retornem os resultados. A penalidade de várias viagens ao Couchbase é muito menor e, na verdade, incentivada.

Vou lhe dar alguns exemplos do que significa padrões padronizados de ID de objeto:

informações de login::hernandez94

Esse objeto armazena as informações de login para um nome de usuário exclusivo de hernandez94 em um armazenamento de perfil de usuário. Portanto, quando precisar autenticar esse usuário, você pegará apenas esse documento JSON que contém somente as informações de login.

security-questions::hernandez94

Nesse mesmo exemplo de armazenamento de perfil de usuário, esse objeto armazenaria um documento JSON com as três perguntas de segurança do usuário. Quando o usuário esquecer a senha, tudo o que seu aplicativo precisa fazer é obter esse objeto. Outra coisa boa é que, como as perguntas de segurança não são acessadas com frequência, elas podem ficar fora do cache gerenciado de objetos que são usados com frequência, e isso não é problema.

Você pode ver que, com padrões de ID de objeto padrão como esses, seu aplicativo poderia criá-los com as informações disponíveis e, em seguida, interagir com esses objetos diretamente no Couchbase. Não é necessária nenhuma consulta completa ao banco de dados. Poderíamos nos aprofundar mais nas estratégias de modelagem de objetos, mas isso está fora do escopo deste artigo. Para saber mais sobre isso, leia "Arquitetura orientada para o desempenho", de Chris Anderson.

Para obter alguns exemplos mais específicos de como você pode usar um padrão de ID de objeto padronizado em seu aplicativo, consulte este e este postagem de blog que escrevi. Mesmo que os casos de uso específicos nos blogs não se apliquem ao seu, eles podem ajudá-lo a entender melhor o uso dos padrões de ID de objeto e como eles podem se aplicar ao seu próprio caso de uso.

Prós:

• Acesso muito rápido e, se seu cluster for dimensionado corretamente, o objeto já estará no cache gerenciado do Couchbase.
• Flexibilidade para localizar dados por meio da ID do objeto
• Os dados são altamente consistentes, ou seja, você sempre lê suas próprias gravações.
• Escala linearmente com distribuição uniforme de dados entre os nós

Contras:

• O aplicativo requer mais inteligência para acessar os objetos de que precisa
• Modelagem de dados mais avançada
• Compreensão mais aprofundada dos padrões de acesso a dados do seu aplicativo antes de escrever o aplicativo

Leitura de dados de uma visualização

Até o Couchbase 4.0, os índices de visualização eram a única maneira de consultar o Couchbase se você não soubesse o ID do objeto. Agora que temos os serviços de consulta e de índice que conduzem o N1QL, vamos rever o que são as visualizações do Couchbase, em que elas são melhores e por que elas ainda são definitivamente relevantes.

As visualizações no Couchbase são uma função de redução de mapas em javascript que gera um índice. A visualização é atualizada automaticamente pelo banco de dados à medida que ocorrem as mutações. Seu aplicativo pode então consultar esse índice de visualização para retornar IDs de objetos.

Por exemplo, a gerência precisa saber regularmente quantos usuários de iOS temos, qual versão do aplicativo eles usam e de que país são, mas isso é feito em 30.000.000 de documentos de usuários no banco de dados. As visualizações resolvem isso muito bem, pois essas informações são computadas à medida que os dados são inseridos ou atualizados no banco de dados. Assim, quando você precisar consultar essa visualização pré-computada, a consulta será relativamente barata.

Um aspecto a ser observado, porém, é que as visualizações são consistentes por padrão. Ao consultá-las, você pode usar "stale=false" para forçar a atualização da visualização antes de retornando e com maior probabilidade de ser altamente consistente. No entanto, você pagará uma penalidade de desempenho por isso. A penalidade depende da frequência com que os dados são alterados no seu banco de dados e de como a visualização foi projetada. O fluxo de satisfação de uma consulta de visualização com stale=false ativado é: seu aplicativo chama os nós do cluster, eles atualizam o índice de visualização nos nós do cluster e, em seguida, retornam ao aplicativo com os resultados. Agora imagine isso com uma taxa de inserção/atualização muito alta e uma alta taxa de consulta e você verá onde poderá ter problemas. Fique atento.

Prós:

• Oferece fácil capacidade de consulta em grandes quantidades de dados
• Pode ser programado com Javascript executado no lado do servidor em tempo real para fornecer funcionalidade não disponível em outras áreas do Couchbase
• Uma vez criado, ele examina cada objeto à medida que ele é atualizado ou inserido para inclusão
• Cada nó do Data Service processa apenas sua parte do total de dados no cluster. Por exemplo, em um cluster de quatro nós, cada nó tem 25% dos dados ativos e, portanto, indexa apenas os 25% que possui.

Contras:

• Devem ser programados com Javascript. Isso os torna um pouco mais complicados de se acostumar, mas também poderosos.
• Os índices de exibição estão espalhados pelos nós do Data Service, não pelo Index Service. Quanto mais nós você tiver como parte do Data Service, mais nós o mecanismo de visualização terá de obter dados para devolver uma resposta ao aplicativo.
• Eventualmente consistente por padrão, mas você pode fazer consultas com stale=false, mas terá um impacto no desempenho.

Leitura e gravação de dados com N1QL

Com o N1QL, passamos a fazer a consulta tradicional de dados. SELECT this FROM that WHERE this = 'stuff we know' JOIN with that other thing. Se o acesso por meio da ID do objeto for a fera na sala, então esse é um assistente poderoso.

O N1QL, juntamente com os serviços de consulta e índice que o impulsionam, oferece a maior flexibilidade para acessar seus dados no Couchbase e, ao mesmo tempo, ter desempenho e escalabilidade por meio de serviços gerenciados de forma independente. Se você precisar fazer análises, consultas complexas, comparar dados etc., o N1QL é o que você está procurando. Na analogia de estar em uma biblioteca e precisar de um livro, a consulta com o N1QL é o bibliotecário pegando os livros que satisfazem os dados que você tem. "Por favor, obtenha na biblioteca todos os livros do autor Neil Gaiman que foram escritos entre 1998 e 2014 e que sejam livros ou graphic novels." Isso altera significativamente os tipos de funcionalidade de aplicativos para os quais o Couchbase pode ser usado.

A vantagem dos SDKs de cliente do Couchbase é que você só precisa usar um método diferente para consultar e o SDK cuida da comunicação com os serviços apropriados. Fora isso, você não precisa fazer nada a mais. Em seu aplicativo, a primeira chamada pode ser uma consulta N1QL complexa com junções e a próxima é usar os resultados da consulta para chamar uma visualização de redução de mapa para obter uma agregação pré-calculada. Esse é outro exemplo de que usar a ferramenta certa para o trabalho certo faz sentido e lhe dá opções.

Agora que já estabelecemos o poder e a flexibilidade, há outras ferramentas que você pode incorporar ao serviço Query. O Couchbase se uniu à Simba Technologies para criar drivers ODBC e JDBC para acesso aos dados. Isso permite que você utilize o Excel ou ferramentas de BI mais complexas, como Pentaho, Informatica, etc.

Prós:

• Muito flexível para consultar dados do banco de dados para obter as respostas de que você precisa.
• Os índices estão localizados apenas nos nós que atendem aos nós de índice e não estão espalhados pelo cluster.
• Pode usar o dimensionamento multidimensional (MDS) para dimensionar apenas os serviços necessários para obter o desempenho exigido para o seu aplicativo.
• Os desenvolvedores que conhecem SQL podem facilmente passar a escrever N1QL
• Drivers ODBC e JDBC para integração com ferramentas de BI

Contras:

• As consultas nunca terão o mesmo desempenho que o acesso aos dados por meio do ID do objeto, pelos motivos que já mencionei.
• Eventualmente consistente por padrão, mas você pode consultar com stale=false para atualizar imediatamente o índice, mas terá um impacto no desempenho. No entanto, para a maioria das cargas de trabalho, o índice está sendo atualizado o mais rápido possível em segundo plano e a consistência deve ser suficiente.

Pesquisa de texto completo com Solr ou Elastic

O Couchbase se integra ao Solr e ao Elastic (Search) por meio de plug-ins para fornecer recursos de pesquisa de texto completo que o Couchbase não tem, no momento. Se você tiver um requisito funcional para isso, cada um deles tem um plug-in que permite que cada operação de gravação/atualização seja transmitida para o Solr e/ou Elastic. Por padrão, esses servidores de pesquisa não salvam o documento JSON inteiro, mas apenas criam os componentes internos (índices etc.) necessários para permitir a pesquisa de texto completo. Quando os documentos forem pesquisáveis, seu aplicativo fará referência a essas ferramentas quando precisar dessa funcionalidade, obterá os resultados da pesquisa e, se necessário, lerá o(s) documento(s) completo(s) do Couchbase. Isso permite que você use cada ferramenta para aquilo em que ela é melhor e obtenha o melhor desempenho de cada uma.

Prós:

• Oferece recursos de pesquisa de texto completo
• O aplicativo não precisa fazer gravações duplas, ele grava no Couchbase e, a partir daí, a gravação é replicada automaticamente para o Elastic/Solr para indexação.
• Cada sistema pode ser dimensionado para lidar com o trabalho necessário

Contras:

• Deve manter uma infraestrutura separada para o Solr ou a Elastic.
• Eventualmente consistente
• Não totalmente integrado ao cluster do Couchbase
• Não está incorporado no SDK do Couchbase, portanto, seu aplicativo terá que se comunicar com um deles e com o Couchbase

Você pode se perguntar: "Por que não usar o Solr ou o Elastic e não usar o Couchbase?" O motivo é simples: embora ambos sejam ótimos para o que fazem, nem o Solr nem o Elastic são bancos de dados e nenhum deles tem o desempenho ou outros recursos avançados do Couchbase. Faça o teste você mesmo e verá que ambos podem ser pelo menos 2 a 3 vezes mais lentos do que obter os mesmos dados do Couchbase.

Resumo

Dependendo de como você precisa acessar os dados no Couchbase, bem como das necessidades funcionais e de desempenho que seu aplicativo precisa do Couchbase, você pode misturar e combinar as ferramentas que descrevi para obter os resultados de que precisa. Se você precisar de velocidade bruta e/ou consistência total, opte pelo acesso via ID de objeto e um padrão de chave padronizado. Se você precisar fazer perguntas sobre os dados, use visualizações, N1QL ou pesquisa de texto completo. Se precisar obter vários documentos e atualizá-los rapidamente, combine exibições com acesso via ID de objeto.

A outra grande vantagem é que os métodos de acesso #1-3 são todos incorporados aos SDKs do Couchbase, com a "forma como cada um faz sua mágica" ofuscada em seu aplicativo. Isso permite que você não apenas combine todos esses padrões de acesso para trabalhar em conjunto, mas também desenvolva com agilidade todos os recursos em um único nó do Couchbase em seu laptop e, em seguida, opere com o mesmo código em qualquer escala em um cluster. Portanto, quer você tenha 3 ou 80 nós do Couchbase em seu cluster, seu aplicativo está pronto para ser dimensionado com zero alterações de código para facilitar isso.