Quando explicamos o que é NoSQL e como o Couchbase se encaixa nesse quadro, geralmente recebemos perguntas sobre bancos de dados relacionais, e não podemos deixar de comparar os dois. Embora suas arquiteturas sejam bastante diferentes, podemos encontrar algumas semelhanças nos conceitos. Esta é uma leitura de dois minutos para entender essas semelhanças.
Tabela/Coluna Documento V.S.
Vamos começar adotando a perspectiva do desenvolvedor. Em seu código, o desenvolvedor frequentemente manipula objetos de domínio. Alguns desses objetos são lidos de um banco de dados ou mantidos em um banco de dados. Em um banco de dados relacional, um objeto é representado por uma ou mais linhas de tabelas formadas por colunas. Uma coluna tem um nome e um tipo. Em um banco de dados de documentos, um documento é tradicionalmente um par de chave/valor em que o valor é um documento JSON (uma cadeia de caracteres JSON). Usamos o termo Document DB quando o banco de dados de chave/valor oferece ao desenvolvedor uma maneira de consultar o documento com base no valor.
Um documento JSON pode ter vários campos e cada campo tem um nome e um tipo. Portanto, se você levar a analogia adiante, o JSON permite que você tenha um conjunto flexível de colunas por documento. Isso significa que você não precisa definir todas as tabelas/colunas uma única vez. Você tem a flexibilidade de modificar isso como achar melhor em um banco de dados de documentos. Isso é realmente o que é ser sem esquema é sobre. Não se trata de não ter um esquema, mas de poder alterá-lo facilmente. Os campos digitados do documento JSON tornam o esquema, um esquema flexível e inferido.
Não posso trazer o tópico de granularidade à mesa e não falar sobre nosso novo API de subdocumento. Isso está sendo implementado no Couchbase 4.5. Em um banco de dados de relações, você pode modificar ou ler campos específicos do seu objeto porque pode modificar ou ler uma linha específica de uma coluna específica. O equivalente em um documento JSON seria modificar ou ler um campo específico do seu documento JSON. E é exatamente isso que a API de subdocumento permite que você faça.
Quando você executa uma consulta SQL, a cláusula FROM refere-se a tabelas. O Couchbase também tem uma linguagem de consulta declarativa chamada N1QL. É um superconjunto do SQL e, como tal, permite que você faça JOINs, entre outros legal material. E como não há tabelas no Couchbase, a cláusula FROM é aplicada a um Bucket. A consulta JOIN também é feita entre Buckets. E isso nos leva ao próximo tópico.
Esquema V.S. Bucket
A tabela e as colunas geralmente são armazenadas no que é chamado de esquema ou banco de dados (com outras coisas como procedimentos armazenados, visualizações materializadas, contadores e muito mais). Com o Couchbase, os documentos são armazenados em um Bucket. O conjunto de opções e recursos é bem diferente. Vejamos a segurança, por exemplo. Em um banco de dados relacional, você pode ir até a especificação de permissões em uma determinada coluna de uma tabela. Em um Bucket, você só pode armazenar pares k/v. Portanto, você só pode conceder permissões para isso. Isso significa que você só pode conceder permissão de leitura ou leitura/gravação em um Bucket para um determinado usuário. Portanto, se você quiser reforçar a segurança, isso deve ser feito no nível do aplicativo. Essa é uma das compensações que você precisa fazer no momento ao escolher um banco de dados NoSQL: parte da lógica do aplicativo que estava no banco de dados de relações será transferida para a camada do aplicativo. Podemos discutir se isso é bom ou não.
Como desenvolvedor, prefiro ter lógica no código, mas essa é apenas a minha opinião. Podemos iniciar uma discussão sobre isso nos comentários abaixo :) Diga-nos o que você acha! Também poderíamos levar esse tópico para além deste escopo e falar sobre clusters, replicação e sharding, mas não seria mais uma leitura de 2 minutos :)