CouchDB y versiones de documentos

12

Actualmente estoy trabajando en una aplicación wiki-esque usando CouchDB y estoy tratando de implementar un esquema de versiones de documentos. A mi modo de ver, hay dos formas de hacerlo:

Almacene cada versión como un documento separado
Almacene versiones anteriores como archivos adjuntos en un solo documento.

En este momento, tengo una forma de # 1 funcionando. Cuando un usuario edita un documento y lo guarda, el back-end primero copia la revisión anterior a un nuevo documento y luego guarda la nueva versión. Cada documento tiene una matriz de "historial" que contiene datos sobre cada versión (el documento _id de la versión anterior, una marca de tiempo, el editor, etc.).

Dado que esta matriz de historial podría ser bastante larga para un documento actualizado con frecuencia, tengo una vista que recupera un documento sin historial durante una lectura normal (y otra vista para recuperar el historial).

Mi pregunta es esta: me siento incómodo con mi enfoque actual y he estado pensando en cambiar al método de "apego". Pero no estoy seguro. Espero que alguien que conozca CouchDB mejor que yo (solo he estado en esto durante un par de semanas, y este es mi primer proyecto con CouchDB ... y NoSQL) pueda decirme cuáles son los pros y los contras de cada uno. Acercarse. ¿O tal vez hay algún otro esquema de versiones que estoy pasando por alto?

database-design couchdb

— James Adam
fuente

2

Si bien no puedo hablar sobre el impacto en el rendimiento, el sistema que está utilizando está "espiritualmente" en línea con CouchDB. Almacenar versiones anteriores como una jerarquía de respuestas es idiomático, ya que está en el "antepasado espiritual" de CouchDB, la base de datos de documentos de Lotus Notes (NSF) (Damien Katz trabajó profundamente en una antes de desarrollar la otra, manteniendo y mejorando lo mejor de ella) mientras arroja los requisitos de compatibilidad cruda y hacia atrás / hacia atrás, muchas de las preguntas estructurales más básicas tendrán respuestas en las Notas.)

2

Almacenar solo los cambios será una buena idea, porque almacenar documentos más antiguos como documentos separados o archivos adjuntos a la revisión final de la base de datos creará una sobrecarga en el servidor de la base de datos.

Cada vez que cambie un valor clave en su documento, agregue una nueva clave llamada _h_i_s_<key_name>. En el recién creado (o creado durante la última actualización), agregue objetos como a continuación después de cada edición / actualización: -

{
key_name: "Hello",
_h_i_s_key_name:{time_of_update:value_of_key_name_before_update},
....
}

o

    {
    key_name: "Hello",
    _h_i_s_key_name:[{time:time_of_update,value:value_of_key_name_before_update}, {time:time_of_last_update,value:value_of_key_name_before_last_update}],
    ....
    }

Este enfoque ahorrará mucho espacio en disco y ancho de banda de replicación a largo plazo.

— Ravinder Payal
fuente

0

Sin ningún conocimiento de CouchDB. Sin embargo, almacenar cada versión solo puede diferir marginalmente de su predecesor es un desperdicio de almacenamiento. Recomiendo almacenar solo los cambios.

Es posible que desee echar un vistazo aquí o buscar versiones de datos.

— xuma202
fuente

Esta respuesta no dice cuál de las opciones 1 (documentos separados) o 2 (como parte del documento) es mejor.

— binki

0

años después ;-)

no tiene que almacenar los cambios porque CouchDB lo hará por usted. Si se cambia un documento, se creará una nueva revisión. Tenga en cuenta que este es físicamente otro documento con el mismo _idpero nuevo _rev(revisión) y consumirá espacio en su disco.

Seguro que tendría que mantener todas las revisiones lo que significaría, que necesita un disco muy grande.

— awenkhh
fuente