Organización de la estructura documental en bases de datos de documentos

Couchbase no tiene esquema. Esto va en contra de la historia y la experiencia de los RDBMS tradicionales, pero ha demostrado ser una de las características más elogiadas de las bases de datos NoSQL.

No tener que desarrollar un esquema antes de crear la aplicación ahorra mucho tiempo. Permite crear prototipos rápidamente y moldear la estructura del documento a medida que se profundiza en sus diferentes usos dentro de la aplicación.

Sin embargo, la falta de un esquema formal obligatorio no significa que sus documentos no obtengan valor por tener una estructura coherente o un esquema "inherente".

Una de las consideraciones clave a la hora de crear documentos para Couchbase es la granularidad de los datos: ¿un documento o varios documentos para un mismo concepto?

Estos son los factores clave a la hora de elegir cómo construir tus datos en Couchbase:

¿Qué aspecto tiene este documento en la vida real?
En nuestro caso, tenemos Cervecerías y su Cerveza. Tenemos un sustantivo para cada una y, en la entrada anterior, teníamos un documento para cada una. Es natural y tiene sentido.

¿Con qué frecuencia lo actualizaré?

Las cervecerías y las cervezas son temas bastante estáticos. Es más probable que añadamos documentos sobre Cervezas a la cartera de una Cervecería que que actualicemos la descripción de una Cerveza o cambiemos la dirección de una Cervecería. Esas cosas ocurren, pero son raras en comparación con las cotizaciones de bolsa, los datos de los sensores o las acciones de los juegos sociales.

¿Quiere que todos estos datos se actualicen juntos?
En Couchbase, el documento es el nivel más pequeño de atomicidad. Si combinamos los datos de Brewery y Beer en un único documento, todos los cambios en los datos de Beer requieren enviar también el documento completo de Brewery que los contiene. Todas las operaciones de creación y actualización se realizan sobre toda esa colección como si fuera una sola cosa. Esto tiene la ventaja de consolidar actualizaciones dispares en solicitudes únicas y racionalizadas, pero tiene la desventaja de requerir una actualización mayor cada vez que se realiza un cambio en cualquiera de los conceptos contenidos.

Actualmente parece que tenemos dos opciones disponibles a la hora de diseñar documentos:

• un documento por cada concepto distinto
• un documento para el mayor concepto de "contenedor

Sin embargo, hay una tercera opción: determinar los datos canónicos más tarde con MapReduce. El contenido puede estructurarse de tal manera que existirá más como un "libro mayor" a partir del cual puedes construir un índice que establezca cuáles son los datos canónicos de entre los documentos. Además, puede dejar los datos pasados (ahora "obsoletos") en la base de datos sin tener que preocuparse por los efectos de esos datos obsoletos en la forma de ver el material activo. Esto puede resultar ventajoso si prefieres disponer de esos datos históricos. En este caso, podríamos poner la dirección de la cervecería tanto en los documentos de la Cervecería como en los de la Cerveza y ser capaces de encontrar que una Cerveza fue elaborada originalmente en la ubicación original de la Cervecería. Hay muchas opciones interesantes.

Dado que Couchbase es amigable con la de-normalización, podríamos poner los datos de la Cervecería en cada documento de Cerveza:

Cerveza con objeto cervecero

Esto podría ahorrarnos mucho tiempo de solicitud. También podría servir como registro histórico de dónde se fabricó originalmente la cerveza (si la dirección de la fábrica de cerveza cambiara años después). Si necesitamos la información canónica de la cervecería en nuestra aplicación (frente a datos posiblemente obsoletos), podemos construir el ID de la cervecería a partir de su nombre (al menos en esta aplicación) y buscar la dirección en el documento autorizado de la cervecería. El documento de la cervecería sería la fuente canónica de información sobre la cervecería, y la información sobre la dirección de la cervecería en el documento de la cerveza podría servir como referencia histórica.

Pros:

• Obtenga un documento sobre la cerveza y tendrá la información de la cervecería en una sola solicitud
• La información sobre las fábricas de cerveza en los documentos cerveceros podría servir para algunos fines históricos
• No es necesario utilizar MapReduce View Collation para construir relaciones

Contras:

• Para obtener la información más reciente sobre la cervecería se necesita una segunda petición o un multiget (si conoce ambos ID) o una vista MapReduce

Cervecería con objetos de cerveza

Demos la vuelta al último ejemplo. Las cervecerías fabrican cervezas. Si no han dado la receta (o incluso si lo han hecho), no puedes conseguir esa cerveza en particular, hecha de esa manera en particular, con esa agua de montaña especial (o lo que sea) de nadie más que de esa cervecería. Entonces, ¿por qué no almacenar todas las cervezas en un documento de cervecería?

Veamos cómo podría ser esta nueva estructura. Las primeras líneas proceden del documento original de New Belgium Brewing. La nueva adición es la clave "beers" y el objeto de información de cerveza establecido como su valor.

Nuestro nuevo objeto hijo "cervezas" tiene claves para cada cerveza que utilizan casi los mismos identificadores que las claves de los documentos Cerveza que vimos anteriormente (sólo que sin el prefijo "beer_").

Pros:

• Cervecería y su cerveza en una única petición (posiblemente bastante grande)
• No es necesario utilizar View Collation para construir relaciones

Contras:

• Los documentos sobre la cerveza no se pueden recuperar directamente (requiere MapReduce)
• El tamaño de la respuesta podría ser bastante grande para las grandes cervecerías (+1 para las microcervecerías).

Conclusión

Cualquiera de estos enfoques puede ser válido para distintos casos de uso. En los casos en los que se desee una recuperación rápida de un "paquete" de relaciones, la ruta del documento único combinado puede ser una gran optimización.

Disfrute de la libertad, considere sus opciones y construya ese prototipo.

A continuación veremos cómo crear índices a partir de los documentos originales de Cerveza y Cervecería. Permanezca atento.