{"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\/es\/moving-from-mongodb-to-couchbase-server-revisited\/","title":{"rendered":"Pasar de MongoDB al servidor Couchbase (revisitado)"},"content":{"rendered":"
\n
\n
\n

Nota: esta entrada de blog es una revisi\u00f3n de Matthew Revell's Pasar de MongoDB a Couchbase Server<\/a><\/em><\/p>\n<\/div>\n

\n

Esta es una gu\u00eda centrada en el desarrollador para mover el almac\u00e9n de datos de su aplicaci\u00f3n de MongoDB a Servidor Couchbase<\/a>. Si est\u00e1 interesado en migrar de una base de datos relacional a Couchbase, comience con el libro de Laurent Gu\u00eda para pasar de PostgreSQL<\/a>y en el futuro publicar\u00e9 un post sobre la migraci\u00f3n a SQL Server.<\/p>\n<\/div>\n

\n

Aunque esta gu\u00eda no cubre todos los casos, s\u00ed ofrece indicaciones sobre lo que debe tener en cuenta al planificar su migraci\u00f3n. Si le interesa saber m\u00e1s sobre por qu\u00e9<\/em> usted har\u00eda esta migraci\u00f3n, o aprender sobre un cliente de Couchbase que haya hecho esta migraci\u00f3n, echa un vistazo a Viber<\/a>.<\/p>\n<\/div>\n

\n

Si actualmente utilizas MongoDB, y est\u00e1s utilizando Mongoose ODM con Node, aqu\u00ed tienes un v\u00eddeo de la conferencia Connect 2016 sobre Migraci\u00f3n desde MongoDB con Ottoman.js<\/a>.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n

Versiones<\/h2>\n
\n
\n

Esta gu\u00eda est\u00e1 escrita para Couchbase Server 4.5 y MongoDB 3.4.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n

Principales diferencias<\/h2>\n
\n
\n

Couchbase Server y MongoDB son almacenes de documentos que pueden operar en uno o varios servidores. Sin embargo, abordan las cosas de maneras significativamente diferentes.<\/p>\n<\/div>\n

\n

Cuando empieces tu migraci\u00f3n de MongoDB a Couchbase Server, tendr\u00e1s que tener en cuenta las siguientes diferencias:<\/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 datos<\/strong><\/p>\n<\/td>\n

\n

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

\n

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

\n

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

\n

N1QL (SQL para JSON), vistas map\/reduce, clave-valor<\/p>\n<\/td>\n

\n

Consulta ad hoc, agregaci\u00f3n map\/reduce<\/p>\n<\/td>\n<\/tr>\n

\n

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

\n

Bloqueo optimista y pesimista<\/p>\n<\/td>\n

\n

Bloqueo optimista y pesimista (con WiredTiger)<\/p>\n<\/td>\n<\/tr>\n

\n

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

\n

Distribuido maestro-maestro<\/p>\n<\/td>\n

\n

Maestro-esclavo con conjuntos de r\u00e9plicas<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n<\/div>\n

\n

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

Couchbase Server es tanto un almac\u00e9n de documentos como un almac\u00e9n clave-valor.<\/p>\n<\/div>\n

\n

Todo empieza con clave-valor, ya que cada documento tiene una clave que puedes usar para obtener y establecer el contenido del documento. Sin embargo, puedes usar Couchbase Server como una base de datos de documentos indexando y consultando el contenido de los documentos. Nota: si est\u00e1s interesado en utilizar Couchbase como almac\u00e9n de valores clave, lee mi entrada en el blog sobre Uso de Couchbase para almacenar datos no JSON<\/a>.<\/em><\/p>\n<\/div>\n

\n

Diferencias entre BSON y JSON<\/h3>\n
\n

Es probable que tu aplicaci\u00f3n almacene documentos de tipo JSON en MongoDB, as\u00ed que empezaremos por ah\u00ed.<\/p>\n<\/div>\n

\n

MongoDB almacena datos en formato BSON, que es un formato binario similar a JSON. La diferencia clave a la hora de migrar es que BSON registra informaci\u00f3n de tipo adicional.<\/p>\n<\/div>\n

\n

Al exportar datos de MongoDB mediante una herramienta como mongoexport<\/em>la herramienta producir\u00e1 JSON que conserva esa informaci\u00f3n de tipo en un formato denominado JSON extendido.<\/p>\n<\/div>\n

\n

Veamos un ejemplo en JSON extendido:<\/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 puedes ver, el JSON extendido sigue siendo JSON v\u00e1lido. Eso significa que puedes almacenarlo, indexarlo, consultarlo y recuperarlo usando Couchbase Server. Sin embargo, tendr\u00e1s que mantener esa informaci\u00f3n de tipo adicional (en el ejemplo anterior, Extended JSON est\u00e1 almacenando un entero largo como una cadena, por ejemplo) en la capa de aplicaci\u00f3n.<\/p>\n<\/div>\n
\n
Alternativamente, puedes convertir el JSON extendido a JSON est\u00e1ndar antes (o despu\u00e9s) de importarlo a Couchbase Server. Con consultas N1QL, esto deber\u00eda ser relativamente sencillo, aunque potencialmente tedioso. Aqu\u00ed tienes un ejemplo que convierte el campo \"myInt\" anterior en un campo num\u00e9rico JSON est\u00e1ndar:<\/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
Lo que resultar\u00eda en:<\/p>\n<\/div>\n
\n
\n
{\r\n  \"myInt\": 123\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n
\n
Datos no JSON<\/h3>\n
\n
Tanto MongoDB como Couchbase Server pueden almacenar datos binarios opacos.<\/p>\n<\/div>\n
\n
Aunque la representaci\u00f3n interna de los datos binarios difiere mucho entre ambos, puedes seguir almacenando en Couchbase Server los datos binarios que has estado almacenando en MongoDB.<\/p>\n<\/div>\n
\n
La principal diferencia es que Couchbase Server puede almacenar binarios de hasta 20 MB de tama\u00f1o, mientras que MongoDB ofrece una capa de conveniencia para fragmentar archivos muy grandes en m\u00faltiples documentos.<\/p>\n<\/div>\n
\n
Hay argumentos de peso en contra de almacenar binarios de gran tama\u00f1o en la base de datos<\/a>. Cuando tengas muchos binarios muy grandes, puedes considerar usar un servicio dedicado de almacenamiento de objetos para almacenarlos mientras usas Couchbase para mantener los metadatos de esos binarios.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
Arquitectura<\/h2>\n
\n
\n
Fragmentaci\u00f3n<\/h3>\n
\n
Couchbase Server fragmenta los datos y escala horizontalmente distribuyendo autom\u00e1ticamente un espacio hash entre los nodos de un cl\u00faster.<\/p>\n<\/div>\n
\n
A continuaci\u00f3n, utiliza la clave de tu documento para decidir en qu\u00e9 parte del espacio hash -y, por tanto, en qu\u00e9 nodo del cl\u00faster- reside ese documento. Como desarrollador, esto se abstrae para ti en el SDK del cliente.<\/p>\n<\/div>\n
\n
Con MongoDB necesitas elegir un m\u00e9todo de fragmentaci\u00f3n y una clave de fragmentaci\u00f3n. La clave de fragmentaci\u00f3n es un campo indexado dentro del documento que determina en qu\u00e9 parte del cl\u00faster reside el documento.<\/p>\n<\/div>\n
\n
La principal diferencia aqu\u00ed es que Couchbase Server maneja autom\u00e1ticamente toda la fragmentaci\u00f3n por ti, mientras que MongoDB te da la opci\u00f3n de elegir el m\u00e9todo de fragmentaci\u00f3n y la clave de fragmentaci\u00f3n. Si tus aplicaciones dependen de una distribuci\u00f3n particular de datos a trav\u00e9s del cluster, entonces necesitar\u00e1s ajustarlo para permitir la distribuci\u00f3n basada en hash usada por Couchbase.<\/p>\n<\/div>\n
\n
La fragmentaci\u00f3n basada en hash simplifica enormemente el escalado en comparaci\u00f3n con MongoDB. Como desarrollador, podr\u00edas pensar que esto no te concierne, y que es un problema de operaciones. Sin embargo, significa que es m\u00e1s f\u00e1cil confiar en Couchbase Server si el uso de tu software crece.<\/p>\n<\/div>\n<\/div>\n
\n
Replicaci\u00f3n y coherencia<\/h3>\n
\n
\"Three<\/div>\n<\/div>\n
\n
Couchbase Server mantiene una \u00fanica copia activa de cada documento y luego hasta tres r\u00e9plicas; puedes configurar el n\u00famero de r\u00e9plicas a nivel de bucket o por operaci\u00f3n.<\/p>\n<\/div>\n
\n
Esto significa que, en condiciones normales de funcionamiento, cada vez que se escribe en un documento o se lee de \u00e9l, se trabaja con la misma copia. De este modo, no es necesario manejar versiones conflictivas de los documentos. Las r\u00e9plicas s\u00f3lo entran en juego cuando la copia activa no est\u00e1 disponible.<\/p>\n<\/div>\n
\n
Como desarrollador, la distribuci\u00f3n y replicaci\u00f3n de documentos se abstrae para ti. Usted escribe, lee y consulta utilizando su conexi\u00f3n al bucket y el SDK gestiona con precisi\u00f3n d\u00f3nde se almacenan los datos. No hay necesidad de tener en cuenta conjuntos de r\u00e9plica o esquemas de fragmentaci\u00f3n.<\/p>\n<\/div>\n
\n
Si conoce el Teorema CAP<\/a>entonces tambi\u00e9n sabr\u00e1 que favorecer la coherencia tiene un efecto sobre la disponibilidad. En caso de fallo de un nodo, sus documentos activos no estar\u00e1n disponibles durante un breve periodo de tiempo para permitir que el cl\u00faster promueva las r\u00e9plicas apropiadas al estado activo. En su c\u00f3digo, todo lo que necesita hacer es reintentar una operaci\u00f3n fallida.<\/p>\n<\/div>\n<\/div>\n
\n
Indexaci\u00f3n<\/h3>\n
\n
Couchbase Server ofrece dos grandes tipos de \u00edndices:<\/p>\n<\/div>\n
\n