Lápida (almacén de datos)

Una lápida es un registro eliminado en una réplica de un almacén de datos distribuido . ^{[ 1 ]} La lápida es necesaria, ya que los almacenes de datos distribuidos utilizan consistencia eventual , donde solo un subconjunto de nodos donde se almacenan los datos debe responder para que una operación se considere exitosa.

Motivación

Si se elimina información en un almacén de datos distribuido con consistencia eventual, la parte "eventual" de la consistencia eventual hace que la información se propague a través de la estructura de nodos, donde algunos nodos pueden no estar disponibles en el momento de la eliminación. Pero una característica de la consistencia eventual causa un problema en caso de eliminación, ya que un nodo que no estaba disponible en ese momento intentará "actualizar" los demás nodos que ya no tienen la entrada eliminada, asumiendo que se les ha pasado por alto una inserción de información. Por lo tanto, en lugar de eliminar la información, el almacén de datos distribuido crea un registro de eliminación (generalmente temporal), que no se devuelve en respuesta a las solicitudes. ^{[ 1 ]}

Retirada de lápidas

Para evitar que el almacén de datos se llene de información inútil, existe una política para eliminar por completo los marcadores de eliminación. Para ello, el sistema comprueba la antigüedad del marcador y lo elimina tras un tiempo determinado. En Apache Cassandra , este tiempo se establece con el GCGraceSecondsparámetro ^{[ 1 ]} y el proceso se denomina compactación. ^{[ 2 ]} La compactación consume recursos del sistema y también reduce la capacidad de cálculo. ^{[ 2 ]}^{[ 3 ]}

Consecuencias

Debido a la eliminación diferida, la información borrada aparecerá vacía después de que se haya borrado el contenido de algunas columnas de varios registros. Tras la compactación, las columnas no utilizadas se eliminarán de estos registros. ^{[ 4 ]}

Referencias

1 2 3 "DistributedDeletes" . Apache Software Foundation . Archivado del original el 11 de mayo de 2011. Recuperado el 13 de abril de 2011. Por lo tanto, el "eventual" en consistencia eventual: si un cliente lee de una réplica que no obtuvo la actualización con un ConsistencyLevel suficientemente bajo, potencialmente verá datos antiguos. [...] Hay una pieza más del problema: ¿cómo sabemos cuándo es seguro eliminar los marcadores de eliminación? [...] [Esto] definió una constante, GCGraceSeconds, y cada nodo hizo un seguimiento de la edad del marcador de eliminación localmente. Una vez que ha envejecido más allá de la constante, se puede eliminar mediante GC durante la compactación (ver MemtableSSTable).
1 2 "¿Qué son las lápidas?" . Apache Cassandra . Consultado el 18 de junio de 2019 .
↑ "Eliminar lápidas en Cassandra" . IBM . 21 de mayo de 2018. Consultado el 18 de junio de 2019 .
↑ "Guía del usuario: Cómo lidiar con marcadores de eliminación" . GitHub . Recuperado el 13/04/2011 . Para poner esto en contexto con un ejemplo, supongamos que acabamos de crear 10 filas de datos con tres columnas cada una. Si la mitad de las columnas se eliminan posteriormente y aún no se ha producido una compactación, estas columnas aparecerán vacías en las consultas get_range_slices. Usando RangeSlicesQuery como se describe en la sección anterior, obtendríamos 10 resultados, pero solo cinco de ellos tendrán valores. Más importante aún, las llamadas a get (a través de ColumnQuery) asumen por diseño que la columna que se está recuperando existe en el almacén. Por lo tanto, si se llama a get en datos marcados como eliminados, se devuelve null (nota: esto es diferente de las versiones anteriores de Hector donde la NotFoundException subyacente se propagaba hacia arriba en la pila).

Enlaces externos

Eliminaciones distribuidas en Apache Cassandra. Archivado el 11 de mayo de 2011 en Wayback Machine.

[deletion-1] 1 2 3 "DistributedDeletes" . Apache Software Foundation . Archivado del original el 11 de mayo de 2011. Recuperado el 13 de abril de 2011. Por lo tanto, el "eventual" en consistencia eventual: si un cliente lee de una réplica que no obtuvo la actualización con un ConsistencyLevel suficientemente bajo, potencialmente verá datos antiguos. [...] Hay una pieza más del problema: ¿cómo sabemos cuándo es seguro eliminar los marcadores de eliminación? [...] [Esto] definió una constante, GCGraceSeconds, y cada nodo hizo un seguimiento de la edad del marcador de eliminación localmente. Una vez que ha envejecido más allá de la constante, se puede eliminar mediante GC durante la compactación (ver MemtableSSTable).

[cassandratombstone-2] 1 2 "¿Qué son las lápidas?" . Apache Cassandra . Consultado el 18 de junio de 2019 .

[3] "Eliminar lápidas en Cassandra" . IBM . 21 de mayo de 2018. Consultado el 18 de junio de 2019 .

[4] "Guía del usuario: Cómo lidiar con marcadores de eliminación" . GitHub . Recuperado el 13/04/2011 . Para poner esto en contexto con un ejemplo, supongamos que acabamos de crear 10 filas de datos con tres columnas cada una. Si la mitad de las columnas se eliminan posteriormente y aún no se ha producido una compactación, estas columnas aparecerán vacías en las consultas get_range_slices. Usando RangeSlicesQuery como se describe en la sección anterior, obtendríamos 10 resultados, pero solo cinco de ellos tendrán valores. Más importante aún, las llamadas a get (a través de ColumnQuery) asumen por diseño que la columna que se está recuperando existe en el almacén. Por lo tanto, si se llama a get en datos marcados como eliminados, se devuelve null (nota: esto es diferente de las versiones anteriores de Hector donde la NotFoundException subyacente se propagaba hacia arriba en la pila).

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]