Lindorm:Secondary indexes

Relación entre los índices y las tablas principales

Cada índice secundario se asigna a una tabla de datos física independiente, separada de la tabla principal. Es posible crear varios índices para una sola tabla principal, incluidos índices compuestos basados en una o más columnas. Cuando escribe en la tabla principal, Lindorm actualiza automáticamente todas las tablas de índice asociadas. Al consultar, especifique las condiciones en la cláusula WHERE sobre la tabla principal; Lindorm selecciona el mejor índice de forma automática e incluso recurre a la tabla principal si ningún índice resulta adecuado.

Online Schema Change

Las modificaciones de índices (agregar, deshabilitar o eliminar un índice) no afectan las operaciones normales de lectura o escritura en la tabla principal. Puede agregar, eliminar o actualizar índices en cualquier momento sin tiempo de inactividad.

Consistencia fuerte

La consistencia de los datos entre la tabla principal y las tablas de índice tiene las siguientes restricciones:

• No se admite el aislamiento de instantáneas. Los datos escritos en la tabla principal podrían no ser visibles de inmediato en las tablas de índice. Una vez que el servidor devuelve una respuesta exitosa, los datos se vuelven visibles en ambas.

• Comportamiento ante tiempos de espera del cliente o errores de E/S. Si una escritura falla por un tiempo de espera del cliente o un error de E/S, es posible que los datos no aparezcan ni en la tabla principal ni en las tablas de índice. Aun así, se garantiza la consistencia eventual entre ellas.

Mutabilidad

Cada escritura en una tabla indexada tiene un costo mayor que en una tabla simple, ya que se debe mantener el índice. El costo real depende de si su carga de trabajo actualiza o elimina filas existentes.

La propiedad MUTABILITY le indica a Lindorm qué operaciones ejecuta su carga de trabajo, de modo que pueda minimizar la sobrecarga del mantenimiento de índices. Establezca esta propiedad mediante Table_Options cuando cree o modifique una tabla. Consulte CREATE TABLE syntax.

Elija la configuración de mutabilidad según su patrón de escritura:

• Solo anexado, sin actualizaciones ni eliminaciones: use IMMUTABLE.

• Anexado y eliminación a nivel de fila, sin actualizaciones: use IMMUTABLE_ROWS.

• Actualizaciones y eliminaciones, sin marca de tiempo personalizada: use MUTABLE_LATEST (recomendado).

• Actualizaciones y eliminaciones con marca de tiempo personalizada: use MUTABLE_UDT.

Se recomienda usar MUTABLE_LATEST, que además es el valor predeterminado en LindormTable 2.7.9 y versiones posteriores. Si su instancia ejecuta una versión anterior, establezca MUTABILITY='MUTABLE_LATEST' de manera explícita.

Para escribir datos con una marca de tiempo personalizada, use MUTABLE_UDT (requiere LindormTable 2.6.7 o posterior). Planifique esto antes de crear los índices, ya que la propiedad de mutabilidad surte efecto al momento de crearlos.

IMMUTABLE y IMMUTABLE_ROWS no cuentan con validación del lado del servidor. Si su carga de trabajo actualiza datos pero la tabla está configurada como IMMUTABLE o IMMUTABLE_ROWS , el servidor no devuelve ningún error, pero los datos del índice pierden consistencia con la tabla principal. Utilice estas configuraciones solo cuando tenga la certeza de que no habrá actualizaciones. Dado que las tablas IMMUTABLE no implican eliminaciones, admiten por completo los despliegues activo-activo en múltiples centros de datos de Internet (IDC).

Índices de cobertura

Sin un índice de cobertura, una consulta que coincide con una entrada de índice aún necesita recuperar la fila completa desde la tabla principal. Las rowkeys que devuelve el índice pueden estar dispersas en la tabla principal, lo que exige varias llamadas a procedimientos remotos (RPC) y aumenta el tiempo de respuesta (RT) conforme crece el conjunto de resultados.

Un índice de cobertura incluye columnas de la tabla principal directamente en la tabla de índice, lo que elimina las búsquedas en la tabla principal para esas columnas. Lindorm admite tres modos de cobertura:

• Specific columns: enumere las columnas que desea replicar desde la tabla principal.

• Todas las columnas del esquema (COVERED_ALL_COLUMNS_IN_SCHEMA): incluye todas las columnas definidas actualmente en el esquema de la tabla principal. Cuando se agrega una nueva columna a la tabla principal, el índice la incorpora de forma automática, sin necesidad de reindexar.

• Columnas dinámicas (DYNAMIC): incluye todas las columnas dinámicas de la tabla principal, además de todas las columnas definidas en el esquema.

Marcas de tiempo personalizadas (User-Defined Timestamp, UDT)

Lindorm admite marcas de tiempo personalizadas a nivel de columna. Escribir datos con una marca de tiempo personalizada es común en sistemas basados en HBase para controlar el tiempo de vida (TTL) y gestionar escrituras fuera de orden o idempotentes. Los índices secundarios en Lindorm también permiten actualizar los datos del índice cuando se usan marcas de tiempo personalizadas, una capacidad poco habitual en los sistemas NoSQL.

A continuación se presentan dos casos de uso donde esto resulta relevante:

• Importación simultánea y actualizaciones en tiempo real: utilice la hora actual para las escrituras en tiempo real y una marca de tiempo anterior (por ejemplo, las 23:59:59 del día anterior) para las importaciones históricas. Las escrituras en tiempo real tienen prioridad, mientras que las importaciones históricas solo completan los datos que aún no se han actualizado.

• Puesta al día de mensajes: cuando un sistema omite los mensajes acumulados y procesa primero los actuales, cada mensaje lleva su propia marca de tiempo. Procesar posteriormente los mensajes anteriores aplica el orden de sobrescritura correcto, sin importar la secuencia de procesamiento.

-- Create the primary table
CREATE TABLE orders (
  order_id VARCHAR NOT NULL,
  user_id  VARCHAR,
  status   VARCHAR,
  amount   DOUBLE,
  created  BIGINT,
  PRIMARY KEY(order_id)
) WITH (CONSISTENCY = 'strong', MUTABILITY = 'MUTABLE_LATEST');

-- Create a covering index on user_id, including all schema columns
-- Queries filtering on user_id hit this index and avoid primary table lookups
CREATE INDEX idx_user ON orders(user_id) WITH (INDEX_COVERED_TYPE = 'COVERED_ALL_COLUMNS_IN_SCHEMA');

-- This query uses idx_user automatically
SELECT * FROM orders WHERE user_id = 'u123';

SHOW INDEX FROM orders;

-- Activate an index
ALTER INDEX IF EXISTS idx_user ON orders ACTIVE;

-- Disable an index
ALTER INDEX idx_user ON orders DISABLED;

DROP INDEX IF EXISTS idx_user ON orders;

CREATE TABLE dt (rowkey VARCHAR, c1 VARCHAR, c2 VARCHAR, c3 VARCHAR, c4 VARCHAR, c5 VARCHAR, PRIMARY KEY(rowkey));
CREATE INDEX idx1 ON dt(c1);
CREATE INDEX idx2 ON dt(c2, c3, c4);
CREATE INDEX idx3 ON dt(c3) INCLUDE(c1, c2, c4);
CREATE INDEX idx4 ON dt(c5 DESC) WITH (INDEX_COVERED_TYPE = 'COVERED_ALL_COLUMNS_IN_SCHEMA');

¿Por qué aparece el error User-Defined-Timestamp(UDT) is not supported by table in MUTABLE_LATEST mode?

Creó un índice mientras la mutabilidad de la tabla estaba configurada como MUTABLE_LATEST, pero su aplicación escribe datos con una marca de tiempo personalizada. MUTABLE_LATEST no admite marcas de tiempo personalizadas.

Para solucionarlo:

1. Elimine el índice de la tabla principal.

2. Cambie la propiedad de mutabilidad a MUTABLE_UDT.

3. Vuelva a crear el índice.

Para otros problemas relacionados con índices, únase al grupo de DingTalk de Lindorm o envíe un ticket. Consulte Technical support.