Mudança do MongoDB para o servidor Couchbase (revisitado)

É provável que seu aplicativo armazene documentos do tipo JSON no MongoDB, portanto, começaremos por ele.

O MongoDB armazena dados no formato BSON, que é um formato binário semelhante ao JSON. A principal diferença ao migrar é que o BSON registra informações adicionais de tipo.

Quando você exporta dados do MongoDB usando uma ferramenta como mongoexportaçãoa ferramenta produzirá JSON que preserva essas informações de tipo em um formato chamado Extended JSON.

Vamos dar uma olhada em um exemplo de JSON estendido:

Como você pode ver, o JSON estendido ainda é um JSON válido. Isso significa que você pode armazenar, indexar, consultar e recuperá-lo usando o Couchbase Server. No entanto, você precisará manter essas informações adicionais de tipo (no exemplo acima, o JSON estendido está armazenando um número inteiro longo como uma cadeia de caracteres, por exemplo) na camada do aplicativo.

Como alternativa, você pode converter o JSON estendido em JSON padrão antes (ou depois) de importá-lo para o Couchbase Server. Com as consultas N1QL, isso deve ser relativamente simples, embora potencialmente tedioso. Aqui está um exemplo que converte o campo "myInt" acima em um campo de número JSON padrão:

O que resultaria em:

Tanto o MongoDB quanto o Couchbase Server podem armazenar dados binários opacos.

Embora a representação interna dos dados binários seja muito diferente entre os dois, você pode continuar a armazenar no Couchbase Server os dados binários que vinha armazenando no MongoDB.

A principal diferença é que o Couchbase Server pode armazenar binários de até 20 MB, enquanto o MongoDB oferece uma camada de conveniência para dividir arquivos muito grandes em vários documentos.

Há fortes argumentos contra o armazenamento de binários grandes em seu banco de dados. Quando você tem muitos binários muito grandes, pode considerar o uso de um serviço de armazenamento de objetos dedicado para armazená-los e usar o Couchbase para manter os metadados desses binários.

O Couchbase Server fragmenta os dados e dimensiona horizontalmente, distribuindo automaticamente um espaço de hash entre os nós em um cluster.

Em seguida, ele usa a chave de seu documento para decidir em que parte do espaço de hash - e, portanto, em que nó do cluster - esse documento reside. Como desenvolvedor, isso é abstraído para você pelo SDK do cliente.

Com o MongoDB, você precisa escolher um método de fragmentação e uma chave de fragmentação. A chave de fragmento é um campo indexado dentro de seu documento que determina onde o documento reside no cluster.

A principal diferença aqui é que o Couchbase Server lida automaticamente com toda a fragmentação para você, enquanto o MongoDB lhe dá a opção de escolher o método de fragmentação e a chave de fragmentação. Se os seus aplicativos dependerem de uma distribuição específica de dados no cluster, será necessário ajustá-los para permitir a distribuição baseada em hash usada pelo Couchbase.

O sharding baseado em hash simplifica muito o dimensionamento em comparação com o MongoDB. Como desenvolvedor, você pode pensar que isso não lhe diz respeito e é um problema de operações. No entanto, isso significa que é mais fácil confiar no Couchbase Server caso o uso do seu software cresça.

O Couchbase Server mantém uma única cópia ativa de cada documento e, em seguida, até três réplicas; você pode configurar o número de réplicas em um bucket ou por operação.

Isso significa que, durante a operação normal, você lida com a mesma cópia ativa sempre que escreve ou lê um documento. Como resultado, você não precisa lidar com versões conflitantes de documentos. As réplicas entram em ação somente quando a cópia ativa não está disponível.

Como desenvolvedor, a distribuição e a replicação de documentos são abstraídas para você. Você escreve, lê e consulta usando sua conexão com o bucket, e o SDK cuida exatamente de onde esses dados estão armazenados. Não há necessidade de levar em conta conjuntos de réplicas ou esquemas de sharding.

Se você conhece o Teorema CAPEntão você também sabe que favorecer a consistência afeta a disponibilidade. No caso de falha de um nó, seus documentos ativos ficarão indisponíveis por um curto período de tempo para permitir que o cluster promova as réplicas apropriadas ao status ativo. Em seu código, tudo o que você precisa fazer é tentar novamente uma operação que falhou.

O Couchbase Server oferece dois tipos amplos de índice:

Quando você ultrapassa o limite de um servidor MongoDB, é necessário introduzir processos de roteador e servidores de configuração.

Com o Couchbase Server, essas duas funções são encontradas no SDK do cliente. Quando você se conecta ao cluster a partir do seu aplicativo, o SDK recebe um mapa de onde cada fragmento está localizado no cluster. O Couchbase Server atualiza automaticamente o mapa do cluster sempre que a forma do cluster muda. Cada solicitação acontece diretamente do servidor do aplicativo para o nó relevante do Couchbase.

Quando o cluster crescer, você poderá optar por executar nós especializados em dados, consultas e indexação. Leia mais sobre escalonamento multidimensional.

Tudo isso acontece de forma transparente para você, como desenvolvedor.

Tanto o Couchbase Server quanto o MongoDB permitem que você divida seu conjunto de dados em grupos de documentos: O Couchbase tem buckets e o MongoDB tem coleções.

Enquanto as coleções do MongoDB têm um escopo equivalente ao das tabelas relacionais, os buckets do Couchbase Server talvez sejam mais equivalentes a um banco de dados relacional.

Essa distinção é importante porque, normalmente, você não quer mais do que dez buckets em um único cluster do Couchbase. Isso faz com que eles não sejam adequados como namespaces. Em vez disso, eles servem como uma maneira de compartilhar decisões de configuração e modelagem entre tipos semelhantes de documentos.

Isso tem duas consequências principais:

O Couchbase Server oferece N1QL. O N1QL é uma linguagem semelhante ao SQL e é bem diferente da consulta no MongoDB.

Vejamos um exemplo em que retornamos o nome dos funcionários do escritório de Mountain View que trabalharam lá por dois anos ou mais, ordenados por data de início:

Se você já trabalhou com SQL, o N1QL deve ser muito familiar para você. Você poderá traduzir suas consultas do MongoDB para N1QL com relativamente pouco esforço.

Antes de começar a reescrever suas consultas, você deve considerar uma grande vantagem que o N1QL oferece: você pode executar JOINs em todos os documentos. Vamos usar nossa consulta acima e também retornar o nome do gerente de cada pessoa.

No Couchbase Server, o bloqueio sempre ocorre no nível do documento e há dois tipos:

Bloqueio otimista pode ser mais eficiente, mas o bloqueio pessimista pode ser necessário às vezes. Leia mais sobre como escolher o tipo certo de trava.

Existem SDKs com suporte oficial para todas as principais linguagens, incluindo Java, .NET, NodeJS, Python, Go, Ruby e C. Você também encontrará bibliotecas de clientes desenvolvidas pela comunidade para linguagens como Erlang.

Da mesma forma, há integrações oficiais com Dados do Spring, Spark, Hadoop, Kafka, Talend, Elasticsearch e ODBC/JDBC, Linq2Couchbase para .NET, e há um NodeJS ODM chamado Ottoman. Se você usa atualmente o Mongoose para MongoDB, assista a este vídeo Vídeo sobre migração do MongoDB com Ottoman.js.