{"id":2454,"date":"2016-12-12T14:52:52","date_gmt":"2016-12-12T14:52:51","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=2454"},"modified":"2025-06-13T19:29:36","modified_gmt":"2025-06-14T02:29:36","slug":"moving-from-mongodb-to-couchbase-server-revisited","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/moving-from-mongodb-to-couchbase-server-revisited\/","title":{"rendered":"Mudan\u00e7a do MongoDB para o servidor Couchbase (revisitado)"},"content":{"rendered":"
\n
\n
\n

Observa\u00e7\u00e3o: esta postagem do blog \u00e9 uma revis\u00e3o do artigo de Matthew Revell Mudan\u00e7a do MongoDB para o Couchbase Server<\/a><\/em><\/p>\n<\/div>\n

\n

Este \u00e9 um guia focado no desenvolvedor para mover o armazenamento de dados do seu aplicativo do MongoDB para o Servidor Couchbase<\/a>. Se voc\u00ea estiver interessado em migrar de um banco de dados relacional para o Couchbase, comece com o artigo de Laurent guia para fazer a mudan\u00e7a do PostgreSQL<\/a>e estarei trabalhando em uma postagem sobre migra\u00e7\u00e3o para o SQL Server no futuro.<\/p>\n<\/div>\n

\n

Embora este guia n\u00e3o cubra todos os casos, ele oferece dicas sobre o que deve ser considerado ao planejar a migra\u00e7\u00e3o. Se voc\u00ea estiver interessado em aprender sobre por que<\/em> voc\u00ea faria essa migra\u00e7\u00e3o, ou aprender sobre um cliente do Couchbase que tenha feito essa migra\u00e7\u00e3o, confira o Viber<\/a>.<\/p>\n<\/div>\n

\n

Se voc\u00ea usa atualmente o MongoDB e est\u00e1 usando o Mongoose ODM com o Node, aqui est\u00e1 um v\u00eddeo da confer\u00eancia Connect 2016 sobre migra\u00e7\u00e3o do MongoDB com Ottoman.js<\/a>.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n

Vers\u00f5es<\/h2>\n
\n
\n

Este guia foi escrito para o Couchbase Server 4.5 e o MongoDB 3.4.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n

Principais diferen\u00e7as<\/h2>\n
\n
\n

O Couchbase Server e o MongoDB s\u00e3o armazenamentos de documentos que podem operar em um ou v\u00e1rios servidores. No entanto, eles abordam as coisas de maneiras significativamente diferentes.<\/p>\n<\/div>\n

\n

Ao iniciar sua migra\u00e7\u00e3o do MongoDB para o Couchbase Server, voc\u00ea precisar\u00e1 considerar as seguintes diferen\u00e7as:<\/p>\n<\/div>\n

\n\n\n\n\n\n\n\n
<\/td>\n\n

Servidor Couchbase<\/p>\n<\/td>\n

\n

MongoDB<\/p>\n<\/td>\n<\/tr>\n

\n

Modelos de dados<\/strong><\/p>\n<\/td>\n

\n

Documento, valor-chave<\/p>\n<\/td>\n

\n

Documento<\/p>\n<\/td>\n<\/tr>\n

\n

Consulta<\/strong><\/p>\n<\/td>\n

\n

N1QL (SQL para JSON), visualiza\u00e7\u00f5es de mapa\/redu\u00e7\u00e3o, valor-chave<\/p>\n<\/td>\n

\n

Consulta ad-hoc, agrega\u00e7\u00e3o de mapa\/redu\u00e7\u00e3o<\/p>\n<\/td>\n<\/tr>\n

\n

Concorr\u00eancia<\/strong><\/p>\n<\/td>\n

\n

Bloqueio otimista e pessimista<\/p>\n<\/td>\n

\n

Bloqueio otimista e pessimista (com WiredTiger)<\/p>\n<\/td>\n<\/tr>\n

\n

Modelo de escala<\/strong><\/p>\n<\/td>\n

\n

Mestre-mestre distribu\u00eddo<\/p>\n<\/td>\n

\n

Mestre-escravo com conjuntos de r\u00e9plicas<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n<\/div>\n

\n

Modelo de dados<\/h2>\n
\n
\n

O Couchbase Server \u00e9 um armazenamento de documentos e um armazenamento de valores-chave.<\/p>\n<\/div>\n

\n

Tudo come\u00e7a com chave-valor, pois cada documento tem uma chave que voc\u00ea pode usar para obter e definir o conte\u00fado do documento. No entanto, voc\u00ea pode usar o Couchbase Server como um banco de dados de documentos, indexando e consultando o conte\u00fado dos documentos. Observa\u00e7\u00e3o: se voc\u00ea estiver interessado em usar o Couchbase como um simples armazenamento de valores-chave, leia minha postagem no blog sobre Uso do Couchbase para armazenar dados n\u00e3o JSON<\/a>.<\/em><\/p>\n<\/div>\n

\n

Diferen\u00e7as entre BSON e JSON<\/h3>\n
\n

\u00c9 prov\u00e1vel que seu aplicativo armazene documentos do tipo JSON no MongoDB, portanto, come\u00e7aremos por ele.<\/p>\n<\/div>\n

\n

O MongoDB armazena dados no formato BSON, que \u00e9 um formato bin\u00e1rio semelhante ao JSON. A principal diferen\u00e7a ao migrar \u00e9 que o BSON registra informa\u00e7\u00f5es adicionais de tipo.<\/p>\n<\/div>\n

\n

Quando voc\u00ea exporta dados do MongoDB usando uma ferramenta como mongoexporta\u00e7\u00e3o<\/em>a ferramenta produzir\u00e1 JSON que preserva essas informa\u00e7\u00f5es de tipo em um formato chamado Extended JSON.<\/p>\n<\/div>\n

\n

Vamos dar uma olhada em um exemplo de JSON estendido:<\/p>\n<\/div>\n

\n
\n
{\r\n \"myInt\": {\r\n  \"$numberLong\": \"123\"\r\n }\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
Como voc\u00ea pode ver, o JSON estendido ainda \u00e9 um JSON v\u00e1lido. Isso significa que voc\u00ea pode armazenar, indexar, consultar e recuper\u00e1-lo usando o Couchbase Server. No entanto, voc\u00ea precisar\u00e1 manter essas informa\u00e7\u00f5es adicionais de tipo (no exemplo acima, o JSON estendido est\u00e1 armazenando um n\u00famero inteiro longo como uma cadeia de caracteres, por exemplo) na camada do aplicativo.<\/p>\n<\/div>\n
\n
Como alternativa, voc\u00ea pode converter o JSON estendido em JSON padr\u00e3o antes (ou depois) de import\u00e1-lo para o Couchbase Server. Com as consultas N1QL, isso deve ser relativamente simples, embora potencialmente tedioso. Aqui est\u00e1 um exemplo que converte o campo \"myInt\" acima em um campo de n\u00famero JSON padr\u00e3o:<\/p>\n<\/div>\n
\n
\n
UPDATE `default`\r\nSET myInt = TONUMBER(myInt.`$numberLong`)\r\nWHERE myInt.`$numberLong` IS NOT MISSING<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
O que resultaria em:<\/p>\n<\/div>\n
\n
\n
{\r\n  \"myInt\": 123\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n
\n
Dados n\u00e3o JSON<\/h3>\n
\n
Tanto o MongoDB quanto o Couchbase Server podem armazenar dados bin\u00e1rios opacos.<\/p>\n<\/div>\n
\n
Embora a representa\u00e7\u00e3o interna dos dados bin\u00e1rios seja muito diferente entre os dois, voc\u00ea pode continuar a armazenar no Couchbase Server os dados bin\u00e1rios que vinha armazenando no MongoDB.<\/p>\n<\/div>\n
\n
A principal diferen\u00e7a \u00e9 que o Couchbase Server pode armazenar bin\u00e1rios de at\u00e9 20 MB, enquanto o MongoDB oferece uma camada de conveni\u00eancia para dividir arquivos muito grandes em v\u00e1rios documentos.<\/p>\n<\/div>\n
\n
H\u00e1 fortes argumentos contra o armazenamento de bin\u00e1rios grandes em seu banco de dados<\/a>. Quando voc\u00ea tem muitos bin\u00e1rios muito grandes, pode considerar o uso de um servi\u00e7o de armazenamento de objetos dedicado para armazen\u00e1-los e usar o Couchbase para manter os metadados desses bin\u00e1rios.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
Arquitetura<\/h2>\n
\n
\n
Fragmenta\u00e7\u00e3o<\/h3>\n
\n
O Couchbase Server fragmenta os dados e dimensiona horizontalmente, distribuindo automaticamente um espa\u00e7o de hash entre os n\u00f3s em um cluster.<\/p>\n<\/div>\n
\n
Em seguida, ele usa a chave de seu documento para decidir em que parte do espa\u00e7o de hash - e, portanto, em que n\u00f3 do cluster - esse documento reside. Como desenvolvedor, isso \u00e9 abstra\u00eddo para voc\u00ea pelo SDK do cliente.<\/p>\n<\/div>\n
\n
Com o MongoDB, voc\u00ea precisa escolher um m\u00e9todo de fragmenta\u00e7\u00e3o e uma chave de fragmenta\u00e7\u00e3o. A chave de fragmento \u00e9 um campo indexado dentro de seu documento que determina onde o documento reside no cluster.<\/p>\n<\/div>\n
\n
A principal diferen\u00e7a aqui \u00e9 que o Couchbase Server lida automaticamente com toda a fragmenta\u00e7\u00e3o para voc\u00ea, enquanto o MongoDB lhe d\u00e1 a op\u00e7\u00e3o de escolher o m\u00e9todo de fragmenta\u00e7\u00e3o e a chave de fragmenta\u00e7\u00e3o. Se os seus aplicativos dependerem de uma distribui\u00e7\u00e3o espec\u00edfica de dados no cluster, ser\u00e1 necess\u00e1rio ajust\u00e1-los para permitir a distribui\u00e7\u00e3o baseada em hash usada pelo Couchbase.<\/p>\n<\/div>\n
\n
O sharding baseado em hash simplifica muito o dimensionamento em compara\u00e7\u00e3o com o MongoDB. Como desenvolvedor, voc\u00ea pode pensar que isso n\u00e3o lhe diz respeito e \u00e9 um problema de opera\u00e7\u00f5es. No entanto, isso significa que \u00e9 mais f\u00e1cil confiar no Couchbase Server caso o uso do seu software cres\u00e7a.<\/p>\n<\/div>\n<\/div>\n
\n
Replica\u00e7\u00e3o e consist\u00eancia<\/h3>\n
\n
\"Three<\/div>\n<\/div>\n
\n
O Couchbase Server mant\u00e9m uma \u00fanica c\u00f3pia ativa de cada documento e, em seguida, at\u00e9 tr\u00eas r\u00e9plicas; voc\u00ea pode configurar o n\u00famero de r\u00e9plicas em um bucket ou por opera\u00e7\u00e3o.<\/p>\n<\/div>\n
\n
Isso significa que, durante a opera\u00e7\u00e3o normal, voc\u00ea lida com a mesma c\u00f3pia ativa sempre que escreve ou l\u00ea um documento. Como resultado, voc\u00ea n\u00e3o precisa lidar com vers\u00f5es conflitantes de documentos. As r\u00e9plicas entram em a\u00e7\u00e3o somente quando a c\u00f3pia ativa n\u00e3o est\u00e1 dispon\u00edvel.<\/p>\n<\/div>\n
\n
Como desenvolvedor, a distribui\u00e7\u00e3o e a replica\u00e7\u00e3o de documentos s\u00e3o abstra\u00eddas para voc\u00ea. Voc\u00ea escreve, l\u00ea e consulta usando sua conex\u00e3o com o bucket, e o SDK cuida exatamente de onde esses dados est\u00e3o armazenados. N\u00e3o h\u00e1 necessidade de levar em conta conjuntos de r\u00e9plicas ou esquemas de sharding.<\/p>\n<\/div>\n
\n
Se voc\u00ea conhece o Teorema CAP<\/a>Ent\u00e3o voc\u00ea tamb\u00e9m sabe que favorecer a consist\u00eancia afeta a disponibilidade. No caso de falha de um n\u00f3, seus documentos ativos ficar\u00e3o indispon\u00edveis por um curto per\u00edodo de tempo para permitir que o cluster promova as r\u00e9plicas apropriadas ao status ativo. Em seu c\u00f3digo, tudo o que voc\u00ea precisa fazer \u00e9 tentar novamente uma opera\u00e7\u00e3o que falhou.<\/p>\n<\/div>\n<\/div>\n
\n
Indexa\u00e7\u00e3o<\/h3>\n
\n
O Couchbase Server oferece dois tipos amplos de \u00edndice:<\/p>\n<\/div>\n
\n