historia - Maneras de implementar el versionado de datos en Cassandra

cassandra db linux

Question

¿Puede compartir sus opiniones sobre cómo implementaría el control de versiones de datos en Cassandra?

Supongamos que necesito versiones de 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:

• será utilizado con poca frecuencia
• se utilizarán todos a la vez para presentarlos en forma de "máquina del tiempo"
• No habrá más versiones que unos pocos cientos en un solo registro.
• la historia no expirará

Estoy considerando el siguiente enfoque:

• Convierta la libreta de direcciones a la familia Super Column y almacene varias versiones de registros de la libreta de direcciones en una fila (por marca de tiempo) como super columnas.

• Cree una nueva familia Super Column para almacenar registros antiguos o cambios en los registros. Dicha estructura se vería como sigue:

  {''tecla de fila de la libreta de direcciones'': {''time stamp1'': {''first name'': ''nuevo nombre'', ''modificado por'': ''id de usuario'',},

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

  ''otra tecla de la fila de la libreta de direcciones'': {''marca de tiempo'': {....

• Almacenar versiones como objeto serializado (JSON) adjunto en el nuevo ColumnFamilly. Representando conjuntos de versiones como filas y versiones como columnas. (modelado después de la versión simple de documentos con CouchDB )

Answer 1

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

Answer 2

Si puede agregar la suposición de que las libretas de direcciones generalmente tienen menos de 10,000 entradas, entonces usar una fila por línea de tiempo de la libreta de direcciones en una familia de super columnas sería un enfoque decente.

Una fila se vería como:

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

donde la clave de la fila identifica la libreta de direcciones, cada nombre de supercolumna es una marca de tiempo y las subcolumnas representan el contenido de la libreta 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 estar completamente deserializadas cuando se lee incluso una sola subcolumna. En general, no es tan malo en este caso, pero es algo a tener en cuenta.

Un enfoque alternativo sería usar una sola fila por versión de la libreta de direcciones, y usar un CF separado con una fila de línea de tiempo por libreta de direcciones como:

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

Aquí, some_uuid1 y some_uuid2 corresponden a la tecla 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. La ventaja es que le permite leer de manera eficiente solo partes seleccionadas de una libreta de direcciones.