replicacion - install cassandra
¿Cómo garantizar la coherencia de los datos en Cassandra en diferentes tablas? (2)
Soy nuevo en Cassandra y he leído que Cassandra fomenta la desnormalización y la duplicación de datos. Esto me deja un poco confundido. Imaginemos el siguiente escenario:
Tengo un espacio de teclado con cuatro tablas: A, B, C y D.
CREATE TABLE A ( tableID int, column1 int, column2 varchar, column3 varchar, column4 varchar, column5 varchar, PRIMARY KEY (column1, tableID) );
Imaginemos que las otras tablas (B, C, D) tienen la misma estructura y los mismos datos que la tabla A, solo con una clave primaria diferente, para responder a otras consultas.
Si actualizo una fila en la tabla A, ¿cómo puedo garantizar la coherencia de los datos en otras tablas que tienen los mismos datos?
Cassandra proporciona BATCH para este propósito. De la documentación :
Una instrucción BATCH combina declaraciones de lenguaje de modificación de datos (DML) (INSERT, UPDATE, DELETE) en una única operación lógica y establece una marca de tiempo suministrada por el cliente para todas las columnas escritas por las instrucciones en el lote. Las sentencias en lotes múltiples pueden guardar intercambios de red entre el cliente / servidor y el coordinador / réplicas del servidor. Sin embargo, debido a la naturaleza distribuida de Cassandra, distribuya las solicitudes entre los nodos cercanos tanto como sea posible para optimizar el rendimiento. El uso de lotes para optimizar el rendimiento generalmente no es exitoso, como se describe en Uso y uso incorrecto de la sección de lotes. Para obtener información sobre la forma más rápida de cargar datos, consulte "Cassandra: carga por lotes sin la palabra clave Batch".
Los lotes son atómicos por defecto. En el contexto de una operación de lote de Cassandra, atómico significa que si cualquiera del lote tiene éxito, todo lo hará. Para lograr la atomicidad, Cassandra primero escribe el lote serializado en la tabla del sistema de registro por lotes que consume el lote serializado como datos de blob. Cuando las filas del lote se han escrito y conservado (o insinuado) correctamente, se eliminan los datos del registro por lotes. Hay una penalización de rendimiento por atomicidad. Si no desea incurrir en esta penalización, evite que Cassandra escriba en el sistema de registro de lotes utilizando la opción DESBLOQUEADO: COMIENZO EL LOTE DESCARGADO
LOTE DESBLOQUEADO casi siempre es indeseable y creo que se elimina en futuras versiones. Los lotes normales brindan la funcionalidad que usted desea.
También puede explorar una nueva característica de Cassandra 3.0 llamada vistas materializadas :
Las reglas básicas de modelado de datos en Cassandra implican la desnormalización manual de datos en tablas separadas basadas en las consultas que se ejecutarán en esa tabla. Actualmente, la única forma de consultar una columna sin especificar la clave de partición es usar índices secundarios, pero no sustituyen la desnormalización de datos en nuevas tablas, ya que no son aptos para datos de cardinalidad alta. Las consultas de índices secundarios de alta cardinalidad a menudo requieren respuestas de todos los nodos en el anillo, lo que agrega latencia a cada solicitud. En cambio, se utiliza la desnormalización del lado del cliente y varias tablas independientes, lo que significa que el mismo código se reescribe para muchos usuarios diferentes.
En 3.0, Cassandra presentará una nueva característica llamada Vistas Materializadas. Las vistas materializadas manejan la desnormalización automatizada del lado del servidor, eliminando la necesidad del manejo del lado del cliente de esta desnormalización y asegurando la consistencia final entre la base y los datos de visualización. Esta desnormalización permite búsquedas muy rápidas de datos en cada vista usando la ruta normal de lectura de Cassandra.
La idea es exactamente la misma que sugirió Jeff Jirsa, pero no requerirá que maneje toda la lógica de coherencia de múltiples tablas dentro de su aplicación, Cassandra lo hará automáticamente.