{"id":2165,"date":"2016-02-19T09:57:34","date_gmt":"2016-02-19T09:57:33","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=2165"},"modified":"2024-09-12T01:12:39","modified_gmt":"2024-09-12T08:12:39","slug":"moving-from-mongodb-to-couchbase-server","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/moving-from-mongodb-to-couchbase-server\/","title":{"rendered":"Mudan\u00e7a do MongoDB para o Couchbase Server"},"content":{"rendered":"

Mudan\u00e7a do MongoDB para o servidor Couchbase<\/h2>\n

Este \u00e9 um guia focado no desenvolvedor para mover o armazenamento de dados do seu aplicativo do MongoDB para o Couchbase Server, seguindo o guia de Laurent guia para fazer a mudan\u00e7a do PostgreSQL<\/a>.<\/p>\n

Embora n\u00e3o cubra todos os casos, ele oferece dicas sobre o que deve ser considerado ao planejar a migra\u00e7\u00e3o.<\/p>\n

Vers\u00f5es<\/h2>\n

Este guia foi escrito para o Couchbase Server 4.1 e o MongoDB 3.2.<\/p>\n

Principais diferen\u00e7as<\/h2>\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

Ao iniciar sua migra\u00e7\u00e3o do MongoDB para o Couchbase Server, voc\u00ea precisar\u00e1 considerar as seguintes diferen\u00e7as:<\/p>\n\n\n\n\n\n\n\n
<\/th>\nServidor Couchbase<\/th>\nMongoDB<\/th>\n<\/tr>\n<\/thead>\n
Modelos de dados<\/strong><\/td>\nDocumento, valor-chave<\/td>\nDocumento<\/td>\n<\/tr>\n
Consulta<\/strong><\/td>\nN1QL (SQL para JSON), visualiza\u00e7\u00f5es de mapa\/redu\u00e7\u00e3o, valor-chave<\/td>\nConsulta ad-hoc, agrega\u00e7\u00e3o de mapa\/redu\u00e7\u00e3o<\/td>\n<\/tr>\n
Concorr\u00eancia<\/strong><\/td>\nBloqueio otimista e pessimista<\/td>\n\n\n\n\n\n
Bloqueio otimista e pessimista, com o WiredTiger<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/td>\n<\/tr>\n
Modelo de escala<\/strong><\/td>\nMestre-mestre distribu\u00eddo<\/td>\nMestre-escravo com conjuntos de r\u00e9plicas<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Modelo de dados<\/h2>\n

O Couchbase Server \u00e9 um armazenamento de documentos e um armazenamento de valores-chave.<\/p>\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.<\/p>\n

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

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

O MongoDB armazena dados no formato BSON, que \u00e9 um formato bin\u00e1rio semelhante ao JSON. A principal diferen\u00e7a para n\u00f3s \u00e9 que o BSON registra informa\u00e7\u00f5es adicionais de tipo.<\/p>\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

Vamos dar uma olhada em um exemplo. Primeiro em JSON padr\u00e3o:<\/p>\n

{\r\n  \"created_at\": \"2016-01-27T16:00:58+00:00\"\r\n}<\/code><\/pre>\n
E agora no JSON estendido:<\/p>\n
{\r\n  \"created_at\": {\r\n    \"$date\": \"1453910458\"\r\n  }\r\n}<\/code><\/pre>\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 na camada do aplicativo.<\/p>\n
Como alternativa, voc\u00ea pode converter o JSON estendido em JSON padr\u00e3o antes de import\u00e1-lo para o Couchbase Server.<\/p>\n
Dados n\u00e3o JSON<\/h3>\n
Tanto o MongoDB quanto o Couchbase Server podem armazenar dados bin\u00e1rios opacos.<\/p>\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
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
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
Arquitetura<\/h2>\n
Fragmenta\u00e7\u00e3o<\/h3>\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
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
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
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
O sharding baseado em hash simplifica muito o dimensionamento em compara\u00e7\u00e3o com o MongoDB. Como desenvolvedor, isso pode parecer mais um problema para a sua equipe de opera\u00e7\u00f5es. No entanto, isso significa que \u00e9 mais f\u00e1cil contar com o Couchbase Server caso o uso do seu software cres\u00e7a.<\/p>\n
Replica\u00e7\u00e3o e consist\u00eancia<\/h3>\n
\"ThreeO Couchbase Server mant\u00e9m uma \u00fanica c\u00f3pia ativa de cada documento e, em seguida, at\u00e9 duas r\u00e9plicas; voc\u00ea pode configurar o n\u00famero de r\u00e9plicas em um bucket ou por opera\u00e7\u00e3o.<\/p>\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
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
Se voc\u00ea conhece o Teorema CAP<\/a> ent\u00e3o voc\u00ea tamb\u00e9m sabe que favorecer a consist\u00eancia tem um efeito sobre 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
Indexa\u00e7\u00e3o<\/h3>\n
O Couchbase Server oferece dois tipos amplos de \u00edndice:<\/p>\n