Índices y partición geográfica

Spanner ofrece varios tipos de índices para mejorar el rendimiento de las consultas. Elegir el tipo de índice correcto para tu esquema y patrones de consulta es fundamental, en especial para las bases de datos que usan la partición geográfica. En esta página, se describen los beneficios de los diferentes tipos de índices y las prácticas recomendadas para seleccionar y usar índices de Spanner con particiones geográficas.

Tipos de índices

Spanner admite índices globales, locales y remotos. Cada tipo tiene diferentes características de rendimiento y casos de uso. En el caso de las bases de datos con particiones geográficas, es importante comprender estos tipos de índices. Elegir el índice correcto te ayuda a optimizar el esquema y las consultas de tu base de datos, lo que puede mejorar significativamente la latencia de tu base de datos particionada geográficamente. Para las bases de datos que no usan la partición geográfica, es menos importante comprender estos tipos de índices, ya que todos se almacenan en la posición predeterminada y tienen características de rendimiento similares.

Índices globales

Un índice global es el tipo de índice predeterminado en Spanner. Los datos del índice se almacenan en la partición predeterminada, que podría no estar ubicada junto con los datos de la tabla. Crear índices globales en tablas particionadas geográficamente puede generar latencias de escritura significativamente más altas para las escrituras que involucran las columnas indexadas, en especial si el cuórum de escritura predeterminado de la partición para el índice está lejos del cuórum de escritura de las filas de la tabla en las que se está escribiendo. Puedes mitigar las latencias de lectura de los índices globales con réplicas de solo lectura cercanas junto con regiones de arrendamiento de lectura o lecturas obsoletas.

Los índices globales tienen las siguientes características:

  • Aceleran las consultas que, de lo contrario, requerirían un análisis completo de la tabla y aplican la unicidad en todas las filas de la tabla, independientemente de la ubicación.
  • Son adecuadas para columnas que requieren valores únicos en una base de datos.
  • Aceleran las consultas que filtran u ordenan por columnas indexadas.

A continuación, se muestra un ejemplo de un índice único global:

CREATE UNIQUE INDEX idx_customer_email ON customer(email);

Índices locales

Un índice local se intercala en la jerarquía principal de la tabla indexada. Los nombres y tipos de las columnas de clave primaria deben coincidir con los de la tabla indexada.

Los índices locales tienen las siguientes características:

  • Almacenan los datos del índice en la misma partición que los datos indexados. La latencia de escritura está sujeta al quórum de escritura de la posición en particular, no al quórum de escritura predeterminado de la posición.

  • Proporcionan la latencia más baja para las consultas que segmentan un prefijo de clave específico, ya que tanto el índice como los datos de la tabla se encuentran en la misma ubicación.

Para crear un índice local, intercala el índice en la tabla principal. Si usas un índice local UNIQUE, la unicidad solo se aplica dentro de una fila principal en particular, no en toda la tabla.

A continuación, se muestra un ejemplo de cómo crear un índice local en la tabla customer, intercalado en la tabla principal locations:

GoogleSQL 

-- Create locations placement table
CREATE TABLE locations (
  location STRING(MAX) NOT NULL PLACEMENT KEY,
) PRIMARY KEY(location);

-- Create customer table interleaved in the locations table
CREATE TABLE customer (
  location STRING(MAX) NOT NULL,
  customerId  INT64 NOT NULL,
  email STRING(MAX),
  webcookie STRING(64),
) PRIMARY KEY(location, customerId), INTERLEAVE IN PARENT locations;

-- Create a local index on the interleaved customer table
CREATE INDEX idx_customer_email_local ON customer(location, email),
INTERLEAVE IN locations;

PostgreSQL 

-- Create locations placement table
CREATE TABLE locations (
  location varchar NOT NULL PLACEMENT KEY PRIMARY KEY
);

-- Create customer table interleaved in the locations table
CREATE TABLE customer (
  location varchar NOT NULL,
  customerId  BIGINT NOT NULL,
  email varchar(1024),
  webcookie varchar(64),
  PRIMARY KEY(location, customerId)
) INTERLEAVE IN PARENT locations;

-- Create a local index on the interleaved customer table
CREATE INDEX idx_customer_email_local ON customer(location, email)
INTERLEAVE IN locations;

Cuando consultas datos en una transacción de lectura y escritura, debes especificar el prefijo de clave primaria de la tabla indexada en la consulta. De lo contrario, la consulta podría requerir un análisis completo de la tabla. Por ejemplo:

GoogleSQL 

-- The location (the index key prefix) must be specified
SELECT *
FROM customer
WHERE location= @location AND email= @email;

PostgreSQL 

-- The location (the index key prefix) must be specified
SELECT *
FROM customer
WHERE location= @location AND email= @email;

Para obtener información sobre la optimización que no requiere que especifiques la ubicación, consulta Usa un índice único global con un índice local o remoto.

Un índice local también es útil cuando la tabla de posiciones se basa en entidades y deseas indexar datos dentro de una entidad o subentidad en particular. Por ejemplo:

GoogleSQL 

-- Create entity based customer placement table
CREATE TABLE customer (
  customerId INT64 NOT NULL,
  email STRING(MAX),
  webcookie STRING(64),
  location STRING(MAX) NOT NULL PLACEMENT KEY
) PRIMARY KEY(customerId);

-- Create customerOrders child table
CREATE TABLE customerOrders (
  customerId INT64 NOT NULL,
  orderId INT64 NOT NULL,
  orderName STRING(MAX) NOT NULL
) PRIMARY KEY(customerId, orderId), INTERLEAVE IN PARENT customer;

-- Create a local index on the interleaved child table
CREATE INDEX idx_order_local ON customerOrders(customerId, orderName),
INTERLEAVE IN customer;

PostgreSQL 

-- Create entity based customer placement table
CREATE TABLE customer (
  customerId BIGINT NOT NULL PRIMARY KEY,
  email varchar(1024),
  webcookie varchar(64),
  location varchar NOT NULL PLACEMENT KEY
);

-- Create customerOrders child table
CREATE TABLE customerOrders (
  customerId BIGINT NOT NULL,
  orderId BIGINT NOT NULL,
  orderName varchar(1024) NOT NULL,
  PRIMARY KEY(customerId, orderId)
) INTERLEAVE IN PARENT customer;

-- Create a local index on the interleaved child table
CREATE INDEX idx_order_local ON customerOrders(customerId, orderName)
INTERLEAVE IN customer;

Índices remotos

Un índice remoto intercala datos de índice en una tabla que no es un elemento superior en la jerarquía de intercalación de la tabla indexada. Los tipos de clave primaria deben coincidir con los tipos de las columnas de índice correspondientes, pero los nombres pueden ser diferentes.

Con el particionado geográfico, solo puedes intercalar un índice remoto en la tabla de colocación raíz administrada automáticamente. Esta tabla contiene una fila para cada posición en tu base de datos.

Los índices remotos tienen las siguientes características:

  • Son especialmente útiles cuando la clave primaria de tu tabla no tiene un prefijo con una clave de posición, pero deseas ubicar geográficamente las particiones del índice según la clave de posición.
  • Solo admiten la indexación de columnas en la tabla de posiciones, no en ninguna columna de las tablas secundarias intercaladas.

Para usar índices remotos con el particionado geográfico, crea la tabla de posición raíz configurando la opción auto_managed_root_placement_table_name en la declaración DDL ALTER DATABASE.

  1. Usa la declaración ALTER DATABASE DDL para crear una tabla de posiciones raíz.

    GoogleSQL 

    ALTER DATABASE DATABASE_NAME SET OPTIONS
  (auto_managed_root_placement_table_name="TABLE_NAME");

    Reemplaza lo siguiente:

    • DATABASE_NAME: El nombre de tu base de datos.
    • TABLE_NAME es el nombre de la tabla que se creará. Te recomendamos que uses el nombre root_placement_table.

    Por ejemplo, el siguiente comando crea una tabla llamada root_placement_table.

    ALTER DATABASE example_db SET OPTIONS
  (auto_managed_root_placement_table_name='root_placement_table');

    Después de crear la tabla de posiciones raíz, Spanner crea una tabla interna y, automáticamente, inserta y borra filas cuando creas o quitas posiciones. A continuación, se muestra un ejemplo de una tabla de colocación definida por el sistema que crea Spanner, en la que el nombre de la tabla de ejemplo se establece en root_placement_table. (No ejecutes este ejemplo).

    // Automatically generated after you run the previous example.
// Don't put this in your schema explicitly.
CREATE TABLE root_placement_table (
location STRING(MAX) NOT NULL PLACEMENT KEY
) PRIMARY KEY(location);

    PostgreSQL 

    ALTER DATABASE DATABASE_NAME SET
  spanner.auto_managed_root_placement_table_name='TABLE_NAME';

    Reemplaza lo siguiente:

    • DATABASE_NAME: El nombre de tu base de datos.
    • TABLE_NAME es el nombre de la tabla que se creará.

    Por ejemplo, para crear una tabla root_placement_table que se use como raíz de intercalado, ejecuta lo siguiente:

    ALTER DATABASE example_db SET
  spanner.auto_managed_root_placement_table_name='root_placement_table';

    Después de crear la tabla de posiciones raíz, Spanner crea una tabla interna y, automáticamente, inserta y borra filas cuando creas o quitas posiciones. A continuación, se muestra un ejemplo de una tabla de colocación definida por el sistema que crea Spanner, en la que el nombre de la tabla de ejemplo se establece en root_placement_table. (No ejecutes este ejemplo).

    // Automatically generated after you run the previous example.
// Don't put this in your schema explicitly.
CREATE TABLE root_placement_table (
  location varchar NOT NULL PLACEMENT KEY,
  PRIMARY KEY (location)
);

  2. Crea un índice remoto intercalado en la tabla root_placement_table administrada automáticamente.

    GoogleSQL 

    -- Create a customer table with a primary key that is not the location
CREATE TABLE customer (
  customerId INT64 NOT NULL ,
  email STRING(MAX),
  webcookie STRING(64),
  location STRING(MAX) NOT NULL PLACEMENT KEY,
) PRIMARY KEY(customerId);

-- Create a remote index on the customer table
CREATE INDEX idx_customer_email_remote ON customer(location, email),
INTERLEAVE IN root_placement_table;

    PostgreSQL 

    -- Create a customer table with a primary key that is not the location
CREATE TABLE customer (
  customerId BIGINT NOT NULL PRIMARY KEY,
  email varchar(1024),
  webcookie varchar(64),
  location varchar NOT NULL PLACEMENT KEY
);

-- Creates a remote index on the customer table
CREATE INDEX idx_customer_email_remote ON customer(location, email)
INTERLEAVE IN root_placement_table;

  3. Cuando consultes datos en una transacción de lectura y escritura, especifica el prefijo de clave del índice en el predicado de la consulta para que no se requiera un análisis completo de la tabla. Por ejemplo:

    GoogleSQL 

    -- Specify the location (the index key prefix) in query
SELECT *
FROM customer
WHERE location= @location AND email= @email;

    Para obtener información sobre la optimización que no requiere que especifiques la ubicación, consulta la sección Índice único global con índice local o remoto.

    PostgreSQL 

    -- Specify the location (the index key prefix) in query
SELECT *
FROM customer
WHERE location= @location AND email= @email;

    Para obtener información sobre la optimización que no requiere que especifiques la ubicación, consulta la sección Índice único global con índice local o remoto.

Optimizaciones para índices únicos globales

Cuando usas un índice único global, Spanner puede activar mejoras en la latencia de las consultas con optimizaciones basadas en heurísticas en los siguientes casos de uso:

  • Cuando usas un índice único global con un índice local o remoto
  • Cuando usas un índice único global con claves primarias parciales

En las siguientes secciones, se describe cómo Spanner puede aplicar optimizaciones en cada caso de uso.

Índice único global con un índice local o remoto

Para mejorar la latencia de las consultas locales, Spanner puede iniciar una optimización basada en heurísticas cuando se combina un índice único global con un índice local o remoto.

Esta optimización minimiza la latencia de las consultas dentro de la región, incluso cuando no se especifica la ubicación de los datos particionados geográficamente, ya que supone que la ubicación es la misma que la del cliente y omite la partición predeterminada del índice global, o bien elimina la necesidad de realizar análisis completos filtrados de la tabla. Este enfoque es especialmente beneficioso cuando los clientes acceden principalmente a los datos almacenados en su propia región.

Usar una combinación de diferentes tipos de índices es útil si la latencia de las búsquedas dentro de la región es la principal preocupación y puedes tolerar un aumento en la latencia de escritura. La combinación de diferentes tipos de índices también mejora el rendimiento de las búsquedas dentro de la región, incluso cuando no especificas la ubicación en la búsqueda.

Esta optimización requiere que crees un índice único global y un índice local o remoto correspondiente en la misma columna. Los datos indexados deben ser únicos a nivel global. Spanner aplica esta optimización a tu consulta si se cumplen las siguientes condiciones:

  • No conoces el prefijo de la clave primaria y no especificas la ubicación de los datos.
  • Tu solicitud se origina en la misma región que el líder predeterminado de la ubicación de los datos, que contiene el fragmento del índice local o remoto.

Spanner aplica la optimización de las siguientes maneras:

  • Si se activa la optimización y se encuentra la fila en la colocación local, dado el índice único global, Spanner no necesita buscar otras ubicaciones. Tu búsqueda tiene latencia dentro de la región.
  • Si la búsqueda de ubicación inicial no devuelve una fila, esto indica que no se trata de una búsqueda dentro de la región. Spanner recurre al uso del índice global.

En el siguiente ejemplo, se crea un índice único global y un índice local:

GoogleSQL 

CREATE UNIQUE INDEX idx_customer_email ON customer(email);
CREATE INDEX idx_customer_email_local ON customer(location, email), INTERLEAVE IN locations;

PostgreSQL 

CREATE UNIQUE INDEX idx_customer_email ON customer(email);
CREATE INDEX idx_customer_email_local ON customer(location, email) INTERLEAVE IN locations;

En el siguiente ejemplo, se crea un índice único global y un índice remoto:

GoogleSQL 

CREATE UNIQUE INDEX idx_customer_email ON customer(email);
CREATE INDEX idx_customer_email_remote ON customer(location, email), INTERLEAVE IN root_placement_table;

PostgreSQL 

CREATE UNIQUE INDEX idx_customer_email ON customer(email);
CREATE INDEX idx_customer_email_remote ON customer(location, email) INTERLEAVE IN root_placement_table;

Según los índices del ejemplo anterior, la siguiente consulta de ejemplo tiene latencia dentro de la región:

GoogleSQL 

SELECT *
FROM customer
WHERE email= @email;

PostgreSQL 

SELECT *
FROM customer
WHERE email= @email;

Índice único global en claves primarias parciales

Spanner puede aplicar una optimización similar a la que se detalla en Usa un índice único global con un índice local o remoto cuando se emplea un índice único global en claves primarias parciales.

En el siguiente ejemplo, se crea un customer intercalado en la tabla principal locations y, luego, se crea un índice único global en la columna customerId.

GoogleSQL 

-- Create locations placement table
CREATE TABLE locations (
location STRING(MAX) NOT NULL PLACEMENT KEY,
) PRIMARY KEY(location);

-- Create customer table interleaved in the locations table
CREATE TABLE customer (
  location STRING(MAX) NOT NULL,
  customerId  INT64 NOT NULL,
  email STRING(MAX),
  webcookie STRING(64),
) PRIMARY KEY(location, customerId), INTERLEAVE IN PARENT locations;

-- Create global unique index on customerId column
CREATE UNIQUE INDEX idx_customer_customerid ON customer(customerId);

PostgreSQL 

-- Create locations placement table
CREATE TABLE locations (
  location varchar NOT NULL PLACEMENT KEY PRIMARY KEY
);

-- Create customer table interleaved in the locations table
CREATE TABLE customer (
  location varchar NOT NULL,
  customerId  BIGINT NOT NULL,
  email varchar(1024),
  webcookie varchar(64),
  PRIMARY KEY(location, customerId)
) INTERLEAVE IN PARENT locations;

-- Create global unique index on customerId column
CREATE UNIQUE INDEX idx_customer_customerid ON customer(customerId);

La optimización se aplica a consultas como las siguientes:

GoogleSQL 

SELECT * FROM customer WHERE customerId= @customerId;

PostgreSQL 

SELECT * FROM customer WHERE customerId= @customerId;

Si no creas el índice único global, es posible que esta consulta requiera un análisis completo de la tabla. Si no usas el índice único global, deberás agregar el filtro de ubicación en tu consulta para lograr una buena latencia de consulta:

GoogleSQL 

SELECT * FROM customer WHERE location = @location AND customerId= @customerId;

PostgreSQL 

SELECT * FROM customer WHERE location = @location AND customerId= @customerId;

Lineamientos generales para elegir un tipo de índice que optimice la latencia

El tipo de índice que elijas afectará directamente la latencia de las consultas. La ubicación de los datos de índice en relación con los datos de la tabla es un factor principal en el rendimiento de las cargas de trabajo con particiones geográficas.

En esta sección, se describe cómo elegir entre índices globales, locales y remotos.

Cuándo elegir índices globales

Usa índices globales si tu carga de trabajo puede tolerar la latencia de lectura y escritura asociada, o si necesitas una unicidad global forzada en las columnas indexadas.

Ten en cuenta lo siguiente cuando elijas índices globales:

  • La distancia entre el cliente y el líder del quórum de escritura predeterminado, junto con la latencia predeterminada del quórum, determina el aumento en la latencia de escritura. Este efecto se limita específicamente a las operaciones que involucran columnas indexadas, como las inserciones de filas o las actualizaciones de columnas indexadas.
  • Agregar réplicas de solo lectura o usar concesiones de lectura puede aliviar el aumento de la latencia de lectura:
    • Agregar una réplica de solo lectura en una ubicación geográfica cercana puede reducir la latencia de lectura inactiva.
    • Agregar una réplica de solo lectura y usar regiones de concesión de lectura puede reducir la latencia de lectura sólida. Si agregas una réplica de solo lectura sin usar una región de concesión de lectura, no se reduce la latencia de lectura sólida, pero puede aumentar el rendimiento de lectura.
    • Spanner siempre entrega lecturas transaccionales pesimistas desde el líder. Agregar réplicas a la ubicación predeterminada no ayuda con las lecturas transaccionales pesimistas de los datos en las ubicaciones predeterminadas.
  • Los índices globales (incluidas las claves y los valores de almacenamiento) se colocan en la ubicación predeterminada, que no proporciona residencia de datos a nivel de la ubicación. Para obtener más información, consulta la descripción general de la residencia de datos de Spanner.

Cuándo elegir índices locales y remotos

Ten en cuenta lo siguiente cuando elijas índices locales y remotos:

  • Los índices locales y remotos proporcionan un rendimiento de lectura y escritura local para la ubicación, pero sacrifican las propiedades de unicidad y ordenamiento globales de las columnas de índice único. En cambio, los índices locales y remotos proporcionan orden y unicidad de las columnas indexadas dentro de la fila principal en la que se intercalan.
  • Cuando usas índices locales o remotos, debes incluir la ubicación de la posición en el predicado de la búsqueda, excepto en los casos en los que también hay un índice único global que permite que Spanner adivine la ubicación de la posición local. De lo contrario, el plan de consultas y el rendimiento no son determinísticos. Spanner puede realizar un análisis de la tabla base o una dispersión y recopilación desde el índice en las ubicaciones de colocación según las estadísticas de la consulta, lo que aumenta la latencia.

Cuándo elegir índices únicos globales con índices locales o remotos

Ten en cuenta lo siguiente cuando elijas una combinación de índices únicos globales junto con índices locales o remotos:

  • Cuando se desconoce la ubicación específica de la posición, usa una combinación de índices únicos globales con índices locales o remotos. Este enfoque es ideal cuando la mayoría de las consultas se originan en servicios ubicados geográficamente en la misma región que la ubicación de los datos solicitados.
  • Cuando se escriben índices globales, la latencia de escritura está sujeta a una latencia de quórum de escritura predeterminada adicional.
  • Con la optimización basada en heurísticas, las búsquedas se publican a través de fragmentos de índices locales y demuestran latencia dentro de la región la mayoría de las veces.

Lineamientos detallados para elegir un índice para diseños de esquemas específicos

La estrategia de indexación óptima depende de la estructura de la clave primaria de tu tabla y de los patrones de consulta de tu aplicación. En esta sección, se brinda orientación para seleccionar el tipo de índice adecuado para tres diseños de esquema comunes:

  • Esquemas que usan una entidad como clave primaria
  • Esquemas que usan la ubicación como clave primaria
  • Esquemas que usan valores relacionados con la ubicación como clave primaria

Diseño del esquema: La entidad como clave primaria

Si tu esquema usa una entidad como clave primaria, elige tu estrategia de indexación según si se especifica o no la ubicación en tus búsquedas.

En los casos en que una entidad como customerID es la clave primaria y una columna no clave independiente como location es la clave de posición, determina tu estrategia de indexación para la tabla de posición en función de tus patrones de búsqueda. (No uses una entidad como clave primaria de la tabla de posiciones si la latencia de inserción es un problema para las entidades).

Si deseas indexar datos en una entidad en particular, como customerID, usa un índice local. Los datos se indexan y ordenan dentro de la entidad, pero no entre ellas. Por ejemplo, si deseas indexar los pedidos de cada cliente por fecha, puedes crear un índice local intercalado bajo la identidad customerID.

Cuando la ubicación siempre se conoce en tus búsquedas, usa una de las siguientes estrategias:

  • Si la ubicación se conoce de forma coherente en tus búsquedas y no es necesario aplicar la unicidad global, usa índices remotos. Estos índices proporcionan latencia dentro de la región para las operaciones de lectura y escritura.

    Los índices remotos solo admiten la indexación de columnas en la tabla de colocación, no en columnas de tablas intercaladas. El índice remoto debe intercalarse en la tabla de colocación raíz. El índice remoto indexa los datos en todas las filas de la posición para la posición.

En los casos en los que la ubicación no siempre se conoce en tus búsquedas, usa una de las siguientes estrategias:

  • Si la columna indexada es única a nivel global, crea un índice único global para aplicar esa unicidad.

    Para lograr lecturas sólidas con baja latencia, crea un índice remoto además de un índice único global.

    Con esta combinación, es posible que las escrituras generen latencia entre regiones, mientras que las consultas con una ubicación especificada (con WHERE location= @location) se benefician de la latencia dentro de la región con el índice remoto. En el caso de las búsquedas sin una ubicación especificada, Spanner usa una optimización basada en la heurística que primero realiza una búsqueda local. Si no se encuentran los datos, se recurre al índice global.

    Si usas regiones de concesión de lectura y tienes una réplica de solo lectura de la partición predeterminada en la misma región que tus datos, no es necesario un índice remoto porque las regiones de concesión de lectura ya proporcionan una latencia de lectura sólida baja para las lecturas de un índice global.

  • Si tu consulta no especifica una ubicación y las columnas indexadas no son únicas a nivel global, crea solo un índice global (no único). En este caso, agregar un índice local o remoto no mejora la latencia de lectura, ya que Spanner no puede determinar si hay datos coincidentes en otra ubicación, incluso si encuentra datos en la ubicación local.

Diseño del esquema: La ubicación como clave primaria

Cuando una columna location sirve como clave primaria y clave de posición, la selección del índice se basa en las consideraciones de latencia cruzada y en si las búsquedas siempre especifican la ubicación.

  • Si la latencia entre regiones no es un problema o necesitas unicidad global, usa índices globales.
  • Si la latencia entre regiones es un problema, tus consultas siempre incluyen la ubicación y no necesitas que Spanner aplique la unicidad global, usa solo índices locales. Esto garantiza la latencia local para las lecturas y escrituras.

  • Si la latencia de las consultas entre regiones es un problema, la latencia de escritura entre regiones es aceptable y la ubicación no siempre se conoce, se aplican las siguientes estrategias:

    Condición Recomendación
    Consulta por clave primaria parcial que es única a nivel global

    Crea un índice global único para aplicar la unicidad. No se necesita un índice local porque la clave primaria realiza una función similar. Se aplica la optimización basada en la heurística. Primero, Spanner verifica la clave primaria completa con la ubicación local antes de recurrir al índice global.

    Para ver un ejemplo, consulta Índice único global en claves principales parciales.

    Consulta por columna única a nivel global que no es clave

    Crea un índice global único para aplicar la unicidad.

    En el caso de la latencia dentro de la región, son posibles las siguientes situaciones:

    • Crea un índice local en la misma columna que el índice global. Se aplica la optimización basada en heurísticas. La combinación de índices globales y locales proporciona baja latencia para las consultas sólidas y obsoletas dentro de la región, mientras que las escrituras y las consultas y escrituras entre regiones tienen latencia entre regiones.
    • Si hay una réplica de lectura y escritura o de solo lectura de la partición predeterminada en la misma región que tus datos, sucede lo siguiente:
      • Si solo necesitas latencia dentro de la región para las lecturas inactivas, pero no para las lecturas sólidas, no necesitas un índice local. La réplica local proporciona latencia dentro de la región.
      • Si necesitas latencia dentro de la región para lecturas sólidas, puedes crear un índice local en la misma columna que el índice global, o usar regiones de concesión de lectura. Las regiones de arrendamiento de lectura proporcionan una latencia de lectura sólida baja a expensas de la latencia de escritura.
    La columna indexada no es única a nivel global Crea solo un índice global. Un índice local no mejora la latencia de lectura porque es posible que Spanner deba verificar todas las ubicaciones.

Si estos tres casos no se aplican a tu caso de uso, es probable que debas sacrificar la simplicidad de la aplicación o la latencia de escritura proporcionando la ubicación de forma coherente.

Si la clave primaria de tu tabla se basa en valores relacionados con la ubicación, pero no es directamente la columna de clave de posición (por ejemplo, si usas country como clave primaria cuando tienes menos posiciones que países), puedes usar un índice global o un índice local (intercalado en la columna country). Sin embargo, no se admiten los índices remotos para ninguna tabla intercalada en este tipo de tabla de posición.

La optimización basada en heurísticas no es compatible con los índices locales en esta situación. Por lo tanto, solo lograrás una latencia local cuando tu consulta especifique de forma explícita el prefijo de la clave primaria.