mongodb - tutorial - nosql pdf

MongoDB/NoSQL: mantener el historial de cambios del documento

Question

Un requisito bastante común en las aplicaciones de bases de datos es rastrear los cambios en una o más entidades específicas en una base de datos. He escuchado esto llamado control de versiones de filas, una tabla de registro o una tabla de historial (estoy seguro de que hay otros nombres para ello). Hay varias formas de abordarlo en un RDBMS: puede escribir todos los cambios de todas las tablas fuente en una sola tabla (más de un registro) o tener una tabla de historial separada para cada tabla fuente. También tiene la opción de administrar el registro en el código de la aplicación o a través de activadores de la base de datos.

Estoy tratando de pensar qué aspecto tendría una solución para el mismo problema en una base de datos NoSQL / documentos (específicamente MongoDB) y cómo se resolvería de manera uniforme. ¿Sería tan simple como crear números de versión para documentos y nunca sobrescribirlos? ¿Crea colecciones separadas para documentos "reales" vs. "registrados"? ¿Cómo afectaría esto la consulta y el rendimiento?

De todos modos, ¿es este un escenario común con bases de datos NoSQL, y si es así, hay una solución común?

Answer 1

¿Por qué no una variación en los cambios de la Tienda dentro del documento ?

En lugar de almacenar versiones en cada par de claves, los pares de claves actuales en el documento siempre representan el estado más reciente y un ''registro'' de cambios se almacena dentro de una matriz de historial. Solo aquellas claves que han cambiado desde la creación tendrán una entrada en el registro.

{
  _id: "4c6b9456f61f000000007ba6"
  title: "Bar",
  body: "Is this thing on?",
  tags: [ "test", "trivial" ],
  comments: [
    { key: 1, author: "joe", body: "Something cool" },
    { key: 2, author: "xxx", body: "Spam", deleted: true },
    { key: 3, author: "jim", body: "Not bad at all" }
  ],
  history: [
    { 
      who: "joe",
      when: 20160101,
      what: { title: "Foo", body: "What should I write?" }
    },
    { 
      who: "jim",
      when: 20160105,
      what: { tags: ["test", "test2"], comments: { key: 3, body: "Not baaad at all" }
    }
  ]
}

Answer 2

Buena pregunta, también estaba investigando esto yo mismo.

Crea una nueva versión en cada cambio

Encontré el módulo de control de versiones del controlador Mongoid para Ruby. No lo he usado yo mismo, pero por lo que pude encontrar , agrega un número de versión a cada documento. Las versiones anteriores están incrustadas en el documento en sí. El principal inconveniente es que todo el documento se duplica en cada cambio , lo que dará lugar a que se almacene una gran cantidad de contenido duplicado cuando trabaje con documentos grandes. Sin embargo, este enfoque está bien cuando se trata de documentos de pequeño tamaño y / o no se actualizan documentos muy a menudo.

Solo almacenar cambios en una nueva versión

Otro enfoque sería almacenar solo los campos modificados en una nueva versión . Luego puede ''aplanar'' su historial para reconstruir cualquier versión del documento. Sin embargo, esto es bastante complejo, ya que necesita hacer un seguimiento de los cambios en su modelo y almacenar actualizaciones y eliminaciones de manera que su aplicación pueda reconstruir el documento actualizado. Esto puede ser complicado, ya que se trata de documentos estructurados en lugar de tablas SQL planas.

Almacenar cambios dentro del documento

Cada campo también puede tener una historia individual. Reconstruir documentos a una versión dada es mucho más fácil de esta manera. En su aplicación, no tiene que hacer un seguimiento explícito de los cambios, sino simplemente crear una nueva versión de la propiedad cuando cambie su valor. Un documento podría verse más o menos así:

{
  _id: "4c6b9456f61f000000007ba6"
  title: [
    { version: 1, value: "Hello world" },
    { version: 6, value: "Foo" }
  ],
  body: [
    { version: 1, value: "Is this thing on?" },
    { version: 2, value: "What should I write?" },
    { version: 6, value: "This is the new body" }
  ],
  tags: [
    { version: 1, value: [ "test", "trivial" ] },
    { version: 6, value: [ "foo", "test" ] }
  ],
  comments: [
    {
      author: "joe", // Unversioned field
      body: [
        { version: 3, value: "Something cool" }
      ]
    },
    {
      author: "xxx",
      body: [
        { version: 4, value: "Spam" },
        { version: 5, deleted: true }
      ]
    },
    {
      author: "jim",
      body: [
        { version: 7, value: "Not bad" },
        { version: 8, value: "Not bad at all" }
      ]
    }
  ]
}

Sin embargo, marcar una parte del documento como eliminado en una versión sigue siendo algo incómodo. Puede introducir un campo de state para las partes que se pueden eliminar / restaurar de su aplicación:

{
  author: "xxx",
  body: [
    { version: 4, value: "Spam" }
  ],
  state: [
    { version: 4, deleted: false },
    { version: 5, deleted: true }
  ]
}

Con cada uno de estos enfoques, puede almacenar una versión actualizada y aplanada en una colección y los datos de historial en una colección separada. Esto debería mejorar los tiempos de consulta si solo está interesado en la última versión de un documento. Pero cuando necesite tanto la última versión como los datos históricos, deberá realizar dos consultas, en lugar de una. Por lo tanto, la elección de usar una sola colección frente a dos colecciones separadas dependerá de la frecuencia con que su aplicación necesite las versiones históricas .

La mayor parte de esta respuesta es solo un recuerdo de mis pensamientos, aún no he probado nada de esto. En retrospectiva, la primera opción es probablemente la solución más fácil y la mejor, a menos que la sobrecarga de datos duplicados sea muy significativa para su aplicación. La segunda opción es bastante compleja y probablemente no vale la pena el esfuerzo. La tercera opción es básicamente una optimización de la opción dos y debería ser más fácil de implementar, pero probablemente no valga la pena el esfuerzo de implementación a menos que realmente no se pueda seguir con la opción uno.

Esperamos recibir comentarios sobre esto y las soluciones de otras personas al problema :)

Answer 3

Hemos implementado esto parcialmente en nuestro sitio y utilizamos las "Revisiones de tienda en un documento separado" (y una base de datos separada). Escribimos una función personalizada para devolver los dif y los almacenamos. No es tan difícil y puede permitir la recuperación automática.

Answer 4

Uno puede tener una base de datos NoSQL actual y una base de datos histórica NoSQL. Habrá un ETL nocturno que se ejecuta todos los días. Este ETL registrará cada valor con una marca de tiempo, por lo tanto, en lugar de valores, siempre serán tuplas (campos versionados). Solo registrará un nuevo valor si hubo un cambio en el valor actual, ahorrando espacio en el proceso. Por ejemplo, este archivo json histórico de la base de datos NoSQL puede verse así:

{
  _id: "4c6b9456f61f000000007ba6"
  title: [
    { date: 20160101, value: "Hello world" },
    { date: 20160202, value: "Foo" }
  ],
  body: [
    { date: 20160101, value: "Is this thing on?" },
    { date: 20160102, value: "What should I write?" },
    { date: 20160202, value: "This is the new body" }
  ],
  tags: [
    { date: 20160101, value: [ "test", "trivial" ] },
    { date: 20160102, value: [ "foo", "test" ] }
  ],
  comments: [
    {
      author: "joe", // Unversioned field
      body: [
        { date: 20160301, value: "Something cool" }
      ]
    },
    {
      author: "xxx",
      body: [
        { date: 20160101, value: "Spam" },
        { date: 20160102, deleted: true }
      ]
    },
    {
      author: "jim",
      body: [
        { date: 20160101, value: "Not bad" },
        { date: 20160102, value: "Not bad at all" }
      ]
    }
  ]
}