Modelado de datos de documentos NoSQL en MongoDB vs Couchbase Server

Cuando participo en eventos, recibo muchas preguntas sobre las diferencias entre MongoDB y Couchbase Server, ya que ambos pertenecen al espacio NoSQL y son bases de datos de documentos. Una pregunta en particular está relacionada con el modelado de datos. MongoDB usa BSON y Couchbase usa JSON, así que ¿no sería diferente el modelo de datos?

Vamos a echar un vistazo a algunos modelos de documentos MongoDB y ver cómo lograr lo mismo en Couchbase con un mínimo o ningún esfuerzo.

Permítanme empezar diciendo que ambos MongoDB y Couchbase tienen una gran documentación sobre el modelado de documentos NoSQL. Ambos hacen referencia a un conjunto similar de prácticas que exploraremos.

Modelos de datos integrados

Dado que puedes tener documentos NoSQL increíblemente complejos con objetos anidados y matrices anidadas, podemos hacer las cosas de forma un poco diferente que en una base de datos relacional.

Tomemos como ejemplo el siguiente documento de MongoDB:

En el ejemplo anterior, tenemos objetos anidados y arrays incrustados en un único documento que está definido por un id de objeto en alguna Colección MongoDB.

En Couchbase, el mismo documento de MongoDB podría tener este aspecto:

Probablemente se dará cuenta de que el ejemplo anterior de Couchbase es casi idéntico al de MongoDB con la excepción de la opción _id propiedad convirtiéndose en Tipo propiedad. En Couchbase, el id del documento existe como una meta propiedad en lugar de dentro del propio documento. Dado que no existe el concepto de Colecciones en Couchbase, los documentos suelen diferenciarse por una propiedad de tipo, pero no es un requisito.

Incrustar objetos y matrices en un único documento es estupendo porque limita el número de pasos necesarios para realizar operaciones comunes con los datos. Sin embargo, a medida que el documento se hace más grande, el rendimiento podría convertirse en un problema.

Aquí es donde entra en juego el siguiente enfoque de modelado de documentos.

Modelos de datos normalizados o referenciados

Cualquiera que proceda de una base de datos relacional sabe que los datos deben normalizarse en varias tablas de la base de datos. Estas tablas se unen de alguna manera cuando es necesario acceder a los datos de forma conjunta.

El concepto de esto todavía se puede aplicar en NoSQL, aunque no sea exactamente el mismo que encontraríamos en una base de datos relacional.

Volviendo al primer ejemplo, vamos a hacer lo que MongoDB denomina un modelo de datos normalizado:

El modelo incrustado ha cambiado ligeramente dirección en su propio documento. En este caso, el dirección es ahora igual a un id de objeto y el nuevo documento tiene este aspecto:

Dividir el documento en varios puede ayudar en varios aspectos. Los documentos son ahora más pequeños y las operaciones sobre ellos pueden ser potencialmente más rápidas. Los datos también se normalizan, en el sentido de que ahora pueden existir varias personas en la misma dirección sin tener que preocuparse por la duplicación de datos que existiría en el modelo incrustado.

Según la documentación de MongoDB:

... Sin embargo, las aplicaciones del lado del cliente deben realizar consultas de seguimiento para resolver las referencias. En otras palabras, los modelos de datos normalizados pueden requerir más viajes de ida y vuelta al servidor.

La capa de aplicación se encarga de gestionar las relaciones en el modelo normalizado. La aplicación también tendrá que hacer más peticiones contra la base de datos.

¿Qué aspecto tendría el modelo normalizado en Couchbase? En lugar de llamarlo normalizado, en Couchbase se suele llamar modelo referido, y tendría este aspecto:

Recuerde, el id se almacena como meta información y la mayoría de los documentos tienen una propiedad para definir qué tipo de documento es. Si nos fijamos en la propiedad dirección estamos utilizando una clave para un documento diferente. El concepto es el mismo que tiene MongoDB con los ids de objeto, pero en MongoDB, el id de objeto es un tipo de dato.

Si miramos el documento que contiene los datos de la dirección, tenemos algo así:

La clave o id del documento anterior sería dirección1 para que coincida con lo que se espera en el otro documento.

Aquí está el truco. Los documentos referidos en Couchbase pueden unirse en una única operación del lado del servidor a través de N1QL en lugar de forzar a la capa de aplicación a encargarse de ello.

Conclusión

Lo que probablemente podría haber resumido en una sola frase es que el modelado de datos en MongoDB y el modelado de datos en Couchbase es lo mismo. No importa si uno usa BSON o JSON, los conceptos se aplican en ambos. Si cambiaras de MongoDB a Couchbase, todo lo que sabías sobre los documentos de MongoDB podrías trasladarlo.

Las principales diferencias se encuentran en la forma de consultar los documentos. Es mucho más fácil consultar datos en Couchbase a través de N1QL y otras estrategias de consulta, independientemente de cómo hayas elegido modelar tus documentos.

Si te interesa ver un vídeo sobre modelado y consultas que grabé, échale un vistazo aquí.

Para obtener más información sobre el uso de Couchbase, consulte la página Portal para desarrolladores de Couchbase que contiene ejemplos y otra documentación.