Nota: esta entrada de blog es una revisión de Matthew Revell's Pasar de MongoDB a Couchbase Server
Esta es una guía centrada en el desarrollador para mover el almacén de datos de su aplicación de MongoDB a Servidor Couchbase. Si está interesado en migrar de una base de datos relacional a Couchbase, comience con el libro de Laurent Guía para pasar de PostgreSQLy en el futuro publicaré un post sobre la migración a SQL Server.
Aunque esta guía no cubre todos los casos, sí ofrece indicaciones sobre lo que debe tener en cuenta al planificar su migración. Si le interesa saber más sobre por qué usted haría esta migración, o aprender sobre un cliente de Couchbase que haya hecho esta migración, echa un vistazo a Viber.
Si actualmente utilizas MongoDB, y estás utilizando Mongoose ODM con Node, aquí tienes un vídeo de la conferencia Connect 2016 sobre Migración desde MongoDB con Ottoman.js.
Versiones
Esta guía está escrita para Couchbase Server 4.5 y MongoDB 3.4.
Principales diferencias
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.
Cuando empieces tu migración de MongoDB a Couchbase Server, tendrás que tener en cuenta las siguientes diferencias:
|
Servidor Couchbase |
MongoDB |
|
|
Modelos de datos |
Documento, clave-valor |
Documento |
|
Consulta |
N1QL (SQL para JSON), vistas map/reduce, clave-valor |
Consulta ad hoc, agregación map/reduce |
|
Concurrencia |
Bloqueo optimista y pesimista |
Bloqueo optimista y pesimista (con WiredTiger) |
|
Modelo de escala |
Distribuido maestro-maestro |
Maestro-esclavo con conjuntos de réplicas |
Modelo de datos
Couchbase Server es tanto un almacén de documentos como un almacén clave-valor.
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ás interesado en utilizar Couchbase como almacén de valores clave, lee mi entrada en el blog sobre Uso de Couchbase para almacenar datos no JSON.
Diferencias entre BSON y JSON
Es probable que tu aplicación almacene documentos de tipo JSON en MongoDB, así que empezaremos por ahí.
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ón de tipo adicional.
Al exportar datos de MongoDB mediante una herramienta como mongoexportla herramienta producirá JSON que conserva esa información de tipo en un formato denominado JSON extendido.
Veamos un ejemplo en JSON extendido:
|
1 2 3 4 5 |
{ "myInt": { "$numberLong": "123" } } |
Como puedes ver, el JSON extendido sigue siendo JSON válido. Eso significa que puedes almacenarlo, indexarlo, consultarlo y recuperarlo usando Couchbase Server. Sin embargo, tendrás que mantener esa información de tipo adicional (en el ejemplo anterior, Extended JSON está almacenando un entero largo como una cadena, por ejemplo) en la capa de aplicación.
Alternativamente, puedes convertir el JSON extendido a JSON estándar antes (o después) de importarlo a Couchbase Server. Con consultas N1QL, esto debería ser relativamente sencillo, aunque potencialmente tedioso. Aquí tienes un ejemplo que convierte el campo "myInt" anterior en un campo numérico JSON estándar:
|
1 2 3 |
ACTUALIZACIÓN `por defecto` SET miInt = TONÚMERO(miInt.`$númeroLargo`) DONDE miInt.`$númeroLargo` IS NO FALTA |
Lo que resultaría en:
|
1 2 3 |
{ "myInt": 123 } |
Datos no JSON
Tanto MongoDB como Couchbase Server pueden almacenar datos binarios opacos.
Aunque la representación interna de los datos binarios difiere mucho entre ambos, puedes seguir almacenando en Couchbase Server los datos binarios que has estado almacenando en MongoDB.
La principal diferencia es que Couchbase Server puede almacenar binarios de hasta 20 MB de tamaño, mientras que MongoDB ofrece una capa de conveniencia para fragmentar archivos muy grandes en múltiples documentos.
Hay argumentos de peso en contra de almacenar binarios de gran tamaño en la base de datos. 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.
Arquitectura
Fragmentación
Couchbase Server fragmenta los datos y escala horizontalmente distribuyendo automáticamente un espacio hash entre los nodos de un clúster.
A continuación, utiliza la clave de tu documento para decidir en qué parte del espacio hash -y, por tanto, en qué nodo del clúster- reside ese documento. Como desarrollador, esto se abstrae para ti en el SDK del cliente.
Con MongoDB necesitas elegir un método de fragmentación y una clave de fragmentación. La clave de fragmentación es un campo indexado dentro del documento que determina en qué parte del clúster reside el documento.
La principal diferencia aquí es que Couchbase Server maneja automáticamente toda la fragmentación por ti, mientras que MongoDB te da la opción de elegir el método de fragmentación y la clave de fragmentación. Si tus aplicaciones dependen de una distribución particular de datos a través del cluster, entonces necesitarás ajustarlo para permitir la distribución basada en hash usada por Couchbase.
La fragmentación basada en hash simplifica enormemente el escalado en comparación con MongoDB. Como desarrollador, podrías pensar que esto no te concierne, y que es un problema de operaciones. Sin embargo, significa que es más fácil confiar en Couchbase Server si el uso de tu software crece.
Replicación y coherencia
Couchbase Server mantiene una única copia activa de cada documento y luego hasta tres réplicas; puedes configurar el número de réplicas a nivel de bucket o por operación.
Esto significa que, en condiciones normales de funcionamiento, cada vez que se escribe en un documento o se lee de él, se trabaja con la misma copia. De este modo, no es necesario manejar versiones conflictivas de los documentos. Las réplicas sólo entran en juego cuando la copia activa no está disponible.
Como desarrollador, la distribución y replicación de documentos se abstrae para ti. Usted escribe, lee y consulta utilizando su conexión al bucket y el SDK gestiona con precisión dónde se almacenan los datos. No hay necesidad de tener en cuenta conjuntos de réplica o esquemas de fragmentación.
Si conoce el Teorema CAPentonces también sabrá que favorecer la coherencia tiene un efecto sobre la disponibilidad. En caso de fallo de un nodo, sus documentos activos no estarán disponibles durante un breve periodo de tiempo para permitir que el clúster promueva las réplicas apropiadas al estado activo. En su código, todo lo que necesita hacer es reintentar una operación fallida.
Indexación
Couchbase Server ofrece dos grandes tipos de índices:
- GSI: índices secundarios globales
- vistas: generadas por consultas map-reduce. La diferencia es más que un detalle de implementación, ya que ambos tipos de índices se crean y gestionan de forma diferente. En general, usarás índices GSI para replicar tus índices MongoDB.
|
MongoDB |
Servidor Couchbase |
|
Campo único |
|
|
Índice compuesto |
|
|
Índice multiclave |
|
|
Índice geoespacial |
|
|
Índice de texto |
Tipos de nodos
Cuando creces más allá de un servidor MongoDB necesitas introducir procesos de enrutamiento y servidores de configuración.
Con Couchbase Server, ambas funciones se encuentran en el SDK del cliente. Cuando te conectas al cluster desde tu aplicación, el SDK recibe un mapa de dónde vive cada fragmento en el cluster. Couchbase Server entonces actualiza automáticamente el mapa del cluster cada vez que la forma del cluster cambia. Cada petición pasa directamente del servidor de la aplicación al nodo de Couchbase correspondiente.
Una vez que su clúster crezca, podrá optar por ejecutar nodos especializados en datos, consultas e indexación. Más información sobre el escalado multidimensional.
Todo esto ocurre de forma transparente para usted como desarrollador.
Cubos y colecciones
Tanto Couchbase Server como MongoDB te permiten dividir tu conjunto de datos en grupos de documentos: Couchbase tiene buckets y MongoDB tiene colecciones.
Mientras que las colecciones de MongoDB tienen un alcance equivalente a las tablas relacionales, los buckets de Couchbase Server son quizás más el equivalente a una base de datos relacional.
Esta distinción es importante porque normalmente no querrás más de diez buckets en un único cluster de Couchbase. Esto los hace inadecuados como espacios de nombres. En su lugar, sirven para compartir decisiones de configuración y modelado entre tipos similares de documentos.
Esto tiene dos consecuencias principales:
- Necesita otra forma de asignar un espacio de nombres a sus documentos
- Hay que pensar cuándo conviene crear un nuevo cubo.
Cuándo utilizar cubos múltiples
En primer lugar, hay que pensar en cómo asignar recursos a los cubos. Las dos grandes consideraciones son:
- RAM
- Vistas e índices.
Cuando creas un bucket, le asignas una parte de la RAM de cada máquina. La memoria RAM que asignes a un bucket debe ser lo suficientemente grande como para almacenar el conjunto de trabajo de esos datos más los pocos bytes de metadatos asociados a cada documento.
Esto significa que puedes asignar diferentes cantidades de RAM a diferentes conjuntos de datos en función de cómo accedas a ellos.
Del mismo modo, las vistas y los índices de Couchbase se ejecutan a través de los documentos dentro de un bucket, al igual que una consulta map-reduce de MongoDB se ejecuta a través de una sola colección.
Si tienes algunos documentos que no necesitan indexación -porque sólo accedes a ellos a través de su clave- y tienes algunos grupos de documentos que tienen velocidades diferentes, puedes ver que sería prudente no ejecutar nunca los indexadores en el primer grupo de datos y ejecutar los indexadores con intervalos adecuados en el resto.
Dividir nuestros datos en distintos buckets nos permite lograr tanto un buen uso de la RAM como del tiempo de CPU que necesitan los indexadores.
Veamos un ejemplo de aplicación de comercio electrónico: los datos que almacenaría, su perfil y cómo respondería a ello en la configuración de su cubo.
|
Tipo de datos |
Perfil de datos |
Perfil del cubo |
|
Sesiones |
Respuestas rápidas, acceso clave-valor, sesiones concurrentes predecibles |
RAM para adaptarse al número típico de sesiones en directo, sin indexación |
|
Perfiles de usuario |
Respuestas rápidas mientras los usuarios están activos, los datos cambian lentamente |
RAM para adaptarse a los perfiles de usuario para el número típico de sesiones en directo, indexación en |
|
Datos del pedido |
Lectura intensiva tras la creación inicial, corta vida útil |
RAM para adaptarse a los pedidos de un número típico de sesiones en directo, indexación en |
|
Datos del producto |
Se necesitan respuestas rápidas, leer pesado |
RAM para todo el catálogo, indexación en |
Es algo más complicado que decidir si la indexación está activada o desactivada. Más bien, se eligen los tipos de índice, y la velocidad de las actualizaciones decide con qué frecuencia se ejecutan los indexadores. Mezclar datos lentos y rápidos puede resultar ineficaz, ya que los indexadores de un bucket recorren todos los documentos de ese bucket, incluidos los que no se han modificado.
Asignación de nombres a los documentos
Si no podemos utilizar cubos como espacios de nombres, ¿cómo distinguimos fácilmente los distintos tipos de documentos?
Deberías usar una combinación de:
- Nombres clave
- Utilizar un "tipo" en su documento JSON.
Utilización de prefijos y sufijos semánticos en los nombres de las claves es una forma sencilla de asignar un espacio de nombre a tus documentos, especialmente si utilizas Couchbase para clave-valor.
Al exigir un tipo en los esquemas de los documentos, se obtienen los datos necesarios para crear consultas que sólo se aplican a determinados tipos de documentos.
Modelo de programación
Hay tres formas de trabajar con Couchbase Server:
- Acceso simple clave-valor: gran coherencia, respuestas en submilisegundos
- Vistas: generadas por consultas map-reduce
- N1QL: Consultas tipo SQL (con JOINs)
Viniendo de MongoDB, puede que tengas la tentación de traducir todas tus consultas de MongoDB a N1QL. Sin embargo, vale la pena pensar en los méritos relativos de cada uno y luego usar la mezcla que se adapte a tus necesidades.
Se puede llegar muy lejos con el acceso clave-valor, por ejemplo utilizando índices secundarios manuales.
Consulta
Couchbase Server ofrece N1QL. N1QL es un lenguaje similar a SQL y es bastante diferente de las consultas en MongoDB.
Veamos un ejemplo en el que devolvemos el nombre de los empleados de la oficina de Mountain View que han trabajado allí durante dos años o más, ordenados por fecha de inicio:
|
1 2 3 4 5 6 |
SELECCIONE nombre DESDE `hr` DONDE oficina=Mountain View Y tipo=empleado Y FECHA_DIFF_MILLIS(fechaInicio, AHORA_MILLIS) >= 63113904000 PEDIR POR fechaInicio; |
N1QL debería resultarte muy familiar si alguna vez has trabajado con SQL. Podrás traducir tus consultas MongoDB a N1QL con relativamente poco esfuerzo.
Antes de empezar a reescribir sus consultas, debe tener en cuenta una gran ventaja que ofrece N1QL: puede realizar Se une a entre documentos. Tomemos nuestra consulta anterior y devolvamos también el nombre del responsable de cada persona.
|
1 2 3 4 5 6 7 |
SELECCIONE r.nombre, s.nombre AS director DESDE `hr` r ÚNASE A `hr` s EN TECLAS r.director DONDE r.oficina=Mountain View Y r.tipo=empleado Y FECHA_DIFF_MILLIS(r.fechaInicio, AHORA_MILLIS) >= 63113904000 PEDIR POR r.fechaInicio; |
Concurrencia
En Couchbase Server, el bloqueo siempre ocurre a nivel de documento y hay dos tipos:
- Pesimista: ningún otro actor puede escribir en ese documento hasta que se libere o se alcance un tiempo de espera.
- Optimista: utiliza valores CAS (check-and-set) para comprobar si el documento ha cambiado desde la última vez que lo tocó y actuar en consecuencia.
Bloqueo optimista puede ser más eficiente, pero el bloqueo pesimista puede ser necesario a veces. Más información sobre cómo elegir el tipo de cerradura adecuado.
Bibliotecas e integraciones
Existen SDK compatibles oficialmente para los principales lenguajes, incluidos Java, .NET, NodeJS, Python, Go, Ruby y C. También encontrará bibliotecas cliente desarrolladas por la comunidad para lenguajes como Erlang.
También existen integraciones oficiales con Datos de primavera, Spark, Hadoop, Kafka, Talend, Elasticsearch y ODBC/JDBC, Linq2Base para .NET, y hay una NodeJS ODM llamado Ottoman. Si actualmente utiliza Mongoose para MongoDB, vea esto vídeo sobre la migración desde MongoDB con Ottoman.js.
Conclusión
Pasar de un almacén de documentos a otro es relativamente sencillo, ya que la forma general de los datos no tiene por qué cambiar demasiado (a diferencia de una migración relacional).
Como desarrollador portando una aplicación de MongoDB a Couchbase Server, tus principales consideraciones son que necesitas:
- Sustituir el espaciado de nombres de las colecciones por nombres de claves y tipos de documentos
- Simplifique sus consultas utilizando N1QL JOINs
- Considere dónde el acceso clave-valor puede ser la mejor opción.
Si estás cambiando de MongoDB a Couchbase Server, seguro que no eres el primero. Eso es una gran noticia para ti porque encontrarás gente que ha hecho el cambio antes en los foros de Couchbase.
Si tiene alguna pregunta, comentario o encuentra algo inexacto, deje un comentario o póngase en contacto con yo en Twitter.
