¿Cómo lidiar con la gestión eficiente de versiones y la compresión de múltiples versiones para bases de datos científicas?

Examina este documento.

http://db.csail.mit.edu/pubs/Arr…

El problema en general se puede solucionar eliminando cualquier posibilidad de que un registro se actualice o elimine una vez creado. Las nuevas versiones son nuevos registros y si desea ver el último registro, cree números de versión en cada registro.

Cuando comienzas a ver el requisito de versiones “eficientes”, se convierte en una pregunta si quieres hacer versiones completas o deltas entre versiones. Si hace lo último, ocasionalmente desea hacer una versión “condensada” de todos los registros anteriores.

Luego, para ver el registro más reciente o un registro a partir de una fecha determinada, vaya a la versión condensada justo antes de esa, léala, luego aplique todos los registros incrementales a los que están en la fecha objetivo o antes.

Si está utilizando algún tipo de número de cambio de sistema en lugar de fechas objetivo, funciona exactamente igual.

Este modelo es lo mismo que los registros incrementales y luego las copias de seguridad completas a intervalos específicos en el crecimiento de los datos.

Para los registros más antiguos que la versión condensada más actual, debe decidir si los conserva o los envejece o los traslada a un almacenamiento más barato.

Si solo desea copiar registros completos, eso también funciona. Si a menudo hay muchos cambios y sus registros tienen una huella pequeña que funciona bastante bien.

Eficiente puede significar acceder a un registro para una fecha y hora determinada y saber que no tiene que recuperar cambios incrementales. Eficiente puede significar el almacenamiento más eficiente y luego el método de cambio incremental es a menudo mejor.

La pregunta que está respondiendo es “¿qué quiero decir cuando llamo a un método dado más eficiente?”.

La otra pregunta que debe hacerse es “qué hace una versión completa y consistente de un conjunto de registros para este proyecto”. El estándar utilizado por la mayoría de los sistemas relacionales es que toda la base de datos debe ser coherente en cada registro. Eso se basa en la idea de que no debe elegir y elegir la coherencia en la mayoría de los escenarios de db.

Si necesita que toda la base de datos sea coherente, entonces construye su sistema en torno a ese concepto. Si solo necesita que un registro determinado sea coherente a partir de una fecha y hora determinada, puede escribir su sistema para eso.

La mayoría de los proyectos solo se preocuparán por los cambios recientes si no están mirando los registros más actualizados y el interés en los registros más antiguos disminuye. En ese momento, el mejor enfoque, si tiene que mantener todo, es migrar los registros más antiguos a un sistema más barato, con unidades más lentas y un tiempo de respuesta más lento.