Formas de implementar versiones de datos en Cassandra

Question

¿Puede compartir sus ideas sobre cómo implementar versiones de datos en Cassandra?

Supongamos que necesito versionar registros en una libreta de direcciones simple. (Los registros de la libreta de direcciones se almacenan como filas en una familia de columnas). espero que la historia:

• se utiliza con poca frecuencia
• serán utilizados a la vez para presentarlo en forma de "máquina del tiempo"
• no habrá más versiones que unos pocos cientos a un solo registro.
• el historial no caducará.

estoy pensando en el siguiente enfoque:

• convierten la libreta de direcciones para el Super columna Familia y almacén de versiones múltiples de dirección registros de libros en una fila con guía (por el sello de tiempo) como Super columnas.

• Crear nueva familia de Super Column para almacenar registros antiguos o cambios en los registros. Dicha estructura se vería de la siguiente manera:

  { 'dirección clave de fila libro': { 'tiempo STAMP1': { 'nombre': 'nombre', 'modificado por': 'ID de usuario' , },

  'time stamp2': { 
       'first name': 'new name', 
       'modified by': 'user id', 
      }, 
  }, 
  

  'otra dirección clave de fila libro': { 'sello de tiempo': { ....

• versiones Store como objeto serializado (JSON) unidos en nueva Col umnFamilly. Representando conjuntos de versiones como filas y versiones como columnas. (Modelado después de Simple Document Versioning with CouchDB)

Answer 1

Si usted puede agregar el supuesto de que frente a los libros suelen tener menos de 10.000 entradas en ellos, a continuación, utilizando una fila por cada dirección de la línea de tiempo libro en una familia de columnas súper sería un enfoque decente.

Una fila sería el resultado:

{'address_book_18f3a8': 
    {1290635938721704: {'entry1': 'entry1_stuff', 'entry2': 'entry2_stuff'}}, 
    {1290636018401680: {'entry1': 'entry1_stuff_v2', ...}, 
    ... 
} 

donde la clave fila identifica la libreta de direcciones, cada nombre de súper columna es una marca de tiempo y los subcolumnas representan el contenido del libro de direcciones para esa versión.

Esto le permitiría leer la última versión de una libreta de direcciones con solo una consulta y también escribir una nueva versión con una sola inserción.

La razón por la que sugiero usar esto si las libretas de direcciones tienen menos de 10,000 elementos es que las súper columnas deben deserializarse por completo cuando se lee una sola subcolumna. En general, no es tan malo en este caso, pero es algo a tener en cuenta.

Un enfoque alternativo sería el uso de una sola fila por cada versión de la libreta de direcciones, y usar un CF separada con una línea fila vez por la libreta de direcciones como:

{'address_book_18f3a8': {1290635938721704: some_uuid1, 1290636018401680: some_uuid2...}} 

Aquí, some_uuid1 y some_uuid2 corresponden a la clave de fila para esas versiones de la libreta de direcciones. La desventaja de este enfoque es que requiere dos consultas cada vez que se lee la libreta de direcciones. Lo bueno es que le permite leer de manera eficiente solo las partes seleccionadas de una libreta de direcciones.

Answer 2

HBase (http://hbase.apache.org/) tiene esta funcionalidad incorporada. Pruébelo.