Indexação e particionamento geográfico

O Spanner oferece vários tipos de índices para melhorar o desempenho das consultas. Escolher o tipo de índice correto para seu esquema e padrões de consulta é fundamental, especialmente para bancos de dados que usam geocategorização. Esta página descreve os benefícios de diferentes tipos de índice e as práticas recomendadas para selecionar e usar índices do Spanner com georregiões.

Tipos de índice

O Spanner é compatível com índices globais, locais e remotos. Cada tipo tem características de desempenho e casos de uso diferentes. Para bancos de dados com particionamento geográfico, é importante entender esses tipos de índice. Escolher o índice certo ajuda a otimizar o esquema e as consultas do banco de dados, o que pode melhorar significativamente a latência do banco de dados particionado geograficamente. Para bancos de dados que não usam o particionamento geográfico, é menos importante entender esses tipos de índice, porque todos são armazenados no posicionamento padrão e têm características de desempenho semelhantes.

Índices globais

Um índice global é o tipo de índice padrão no Spanner. Os dados de índice são armazenados na partição padrão, que pode não estar localizada com os dados da tabela. A criação de índices globais em tabelas particionadas por região geográfica pode resultar em latências de gravação significativamente maiores para gravações que envolvem as colunas indexadas, especialmente se o quorum de gravação da partição padrão para o índice estiver longe do quorum de gravação das linhas da tabela que estão sendo gravadas. É possível reduzir as latências de leitura dos índices globais usando réplicas somente leitura próximas, além de regiões de locação de leitura ou leituras obsoletas.

Os índices globais têm as seguintes características:

  • Eles aceleram consultas que, de outra forma, exigiriam uma verificação completa da tabela e impõem a exclusividade em todas as linhas da tabela, independentemente do local.
  • São adequadas para colunas que exigem valores exclusivos em um banco de dados.
  • Elas aceleram consultas que filtram ou classificam por colunas indexadas.

Confira um exemplo de índice global exclusivo:

CREATE UNIQUE INDEX idx_customer_email ON customer(email);

Índices locais

Um índice local é intercalado na hierarquia principal da tabela indexada. Os nomes e tipos de coluna de chave primária precisam corresponder à tabela indexada.

Os índices locais têm as seguintes características:

  • Eles armazenam dados de índice na mesma partição que os dados indexados. A latência de gravação está sujeita ao quorum de gravação do canal específico, não ao quorum de gravação padrão.

  • Elas oferecem a menor latência para consultas que têm como destino um prefixo de chave específico, porque os dados de índice e de tabela estão no mesmo local.

Para criar um índice local, intercale-o na tabela mãe. Se você usar um índice local UNIQUE, a exclusividade será aplicada apenas em uma linha mãe específica, não em toda a tabela.

Confira um exemplo de criação de um índice local na tabela customer, intercalado na tabela mãe 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;

Ao consultar dados em uma transação de leitura/gravação, é necessário especificar o prefixo da chave primária da tabela indexada na consulta. Caso contrário, a consulta poderá exigir uma verificação completa da tabela. Exemplo:

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 informações sobre otimizações que não exigem a especificação do local, consulte Usar índice global exclusivo com índice local ou remoto.

Um índice local também é útil quando a tabela de posicionamento é baseada em entidades e você quer indexar dados em uma entidade ou subentidade específica. Exemplo:

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

Um índice remoto intercala dados de índice em uma tabela que não é ancestral na hierarquia de intercalação da tabela indexada. Os tipos de chave primária precisam corresponder aos tipos das colunas de índice correspondentes, mas os nomes podem ser diferentes.

Com o georparticionamento, só é possível intercalar um índice remoto em uma tabela de posicionamento raiz gerenciada automaticamente. Essa tabela contém uma linha para cada posição no seu banco de dados.

Os índices remotos têm as seguintes características:

  • Elas são particularmente úteis quando a chave primária da tabela não tem um prefixo usando uma chave de posicionamento, mas você quer alocar geograficamente partições do índice de acordo com a chave de posicionamento.
  • Elas só são compatíveis com colunas de indexação na tabela de posicionamento, não em colunas nas tabelas filhas intercaladas.

Para usar índices remotos com particionamento geográfico, crie a tabela de posicionamento raiz definindo a opção auto_managed_root_placement_table_name na instrução DDL ALTER DATABASE.

  1. Use a instrução ALTER DATABASE DDL para criar uma tabela de posicionamento raiz.

    GoogleSQL 

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

    Substitua:

    • DATABASE_NAME: o nome do banco de dados.
    • TABLE_NAME: o nome da tabela a ser criada. Recomendamos usar o nome root_placement_table.

    Por exemplo, o comando a seguir cria uma tabela chamada root_placement_table.

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

    Depois de criar a tabela de posicionamento raiz, o Spanner cria uma tabela interna e insere e exclui linhas automaticamente quando você cria ou exclui um posicionamento. Confira um exemplo de uma tabela de posicionamento definida pelo sistema criada pelo Spanner, em que o nome da tabela de exemplo é definido como root_placement_table. (Não execute este exemplo.)

    // 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';

    Substitua:

    • DATABASE_NAME: o nome do banco de dados.
    • TABLE_NAME: o nome da tabela a ser criada.

    Por exemplo, para criar uma tabela root_placement_table usada como uma raiz de intercalação, execute:

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

    Depois de criar a tabela de posicionamento raiz, o Spanner cria uma tabela interna e insere e exclui linhas automaticamente quando você cria ou exclui um posicionamento. Confira um exemplo de uma tabela de posicionamento definida pelo sistema criada pelo Spanner, em que o nome da tabela de exemplo é definido como root_placement_table. (Não execute este exemplo.)

    // 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. Crie um índice remoto intercalado na tabela root_placement_table gerenciada automaticamente.

    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. Ao consultar dados em uma transação de leitura/gravação, especifique o prefixo de chave do índice no predicado da consulta para que não seja necessária uma verificação completa da tabela. Exemplo:

    GoogleSQL 

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

    Para informações sobre otimização que não exige a especificação do local, consulte a seção Índice global exclusivo com índice local ou remoto.

    PostgreSQL 

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

    Para informações sobre otimização que não exige que você especifique o local, consulte a seção Índice global exclusivo com índice local ou remoto.

Otimizações para índices globais exclusivos

Ao usar um índice global exclusivo, o Spanner pode acionar melhorias na latência de consulta com otimizações baseadas em heurísticas nos seguintes casos de uso:

  • Ao usar um índice global exclusivo com um índice local ou remoto
  • Quando você usa um índice global exclusivo com chaves primárias parciais

As seções a seguir descrevem como o Spanner pode aplicar otimizações em cada caso de uso.

Índice global exclusivo com um índice local ou remoto

Para melhorar a latência de consultas locais, o Spanner pode iniciar uma otimização baseada em heurísticas quando um índice global exclusivo é combinado com um índice local ou remoto.

Essa otimização minimiza a latência para consultas intrarregionais, mesmo quando o local dos dados particionados por área geográfica não é especificado. Isso acontece porque o sistema adivinha que o posicionamento é o mesmo de onde o cliente está localizado e ignora a partição padrão do índice global ou elimina a necessidade de verificações filtradas de tabelas completas. Essa abordagem é especialmente benéfica quando os clientes acessam principalmente dados armazenados na própria região.

Usar uma mistura de diferentes tipos de índice é útil se a latência de consulta intrarregional for a principal preocupação e você puder tolerar um aumento na latência de gravação. A combinação de diferentes tipos de índice também melhora o desempenho das consultas intrarregionais, mesmo quando você não especifica o local na consulta.

Para essa otimização, é necessário criar um índice global exclusivo e um índice local ou remoto correspondente na mesma coluna. Os dados indexados precisam ser globalmente exclusivos. O Spanner aplica essa otimização à sua consulta se o seguinte for verdadeiro:

  • Você não sabe o prefixo da chave primária e não especifica o local dos dados.
  • Sua solicitação é originada da mesma região do líder padrão do posicionamento dos dados, que contém o fragmento de índice local ou remoto.

O Spanner aplica a otimização das seguintes maneiras:

  • Se a otimização for acionada e a linha for encontrada no posicionamento local: considerando o índice global exclusivo, o Spanner não precisa pesquisar outros locais. Sua consulta tem latência intrarregional.
  • Se a pesquisa inicial de local não retornar uma linha, isso indica que não é uma consulta intrarregional. O Spanner volta a usar o índice global.

O exemplo a seguir cria um índice global exclusivo e um í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;

O exemplo a seguir cria um índice global exclusivo e um í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;

Com base nos índices do exemplo anterior, a consulta de exemplo a seguir tem latência intrarregional:

GoogleSQL 

SELECT *
FROM customer
WHERE email= @email;

PostgreSQL 

SELECT *
FROM customer
WHERE email= @email;

Índice global exclusivo em chaves primárias parciais

O Spanner pode aplicar uma otimização semelhante à detalhada em Usar um índice global exclusivo com um índice local ou remoto ao empregar um índice global exclusivo em chaves primárias parciais.

O exemplo a seguir cria uma customer intercalada na tabela mãe locations e, em seguida, cria um índice global exclusivo na coluna 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);

A otimização se aplica a consultas como as seguintes:

GoogleSQL 

SELECT * FROM customer WHERE customerId= @customerId;

PostgreSQL 

SELECT * FROM customer WHERE customerId= @customerId;

Se você não criar o índice global exclusivo, essa consulta poderá exigir uma verificação completa da tabela. Se você não estiver usando o índice global exclusivo, adicione o filtro de local à sua consulta para ter uma boa latência:

GoogleSQL 

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

PostgreSQL 

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

Diretrizes gerais para escolher um tipo de índice e otimizar a latência

O tipo de índice escolhido afeta diretamente a latência da consulta. A localização dos dados de índice em relação aos dados da tabela é um fator principal no desempenho das cargas de trabalho particionadas geograficamente.

Nesta seção, descrevemos como escolher entre índices globais, locais e remotos.

Quando escolher índices globais

Use índices globais se a carga de trabalho tolerar a latência de leitura e gravação associada ou se você precisar de unicidade global forçada em colunas indexadas.

Considere o seguinte ao escolher índices globais:

  • A distância entre o cliente e o líder do quorum de gravação padrão, junto com a latência padrão do quorum, determina o aumento na latência de gravação. Esse efeito é limitado especificamente a operações que envolvem colunas indexadas, como inserções de linhas ou atualizações em colunas indexadas.
  • Adicionar réplicas somente leitura ou usar concessões de leitura pode reduzir o aumento da latência de leitura:
    • Adicionar uma réplica somente leitura em proximidade geográfica pode reduzir a latência de leitura desatualizada.
    • Adicionar uma réplica somente leitura e usar regiões de concessão de leitura pode reduzir a latência de leitura consistente. Se você adicionar uma réplica somente leitura sem usar uma região de concessão de leitura, a latência de leitura forte não será reduzida, mas a capacidade de processamento poderá aumentar.
    • O Spanner sempre veicula leituras transacionais pessimistas do líder. Adicionar réplicas ao posicionamento padrão não ajuda com leituras transacionais pessimistas de dados nos posicionamentos padrão.
  • Os índices globais (incluindo chaves e valores de armazenamento) são colocados no local padrão, que não oferece residência de dados no nível da posição. Para mais informações, consulte a Visão geral da residência de dados do Spanner.

Quando escolher índices locais e remotos

Considere o seguinte ao escolher índices locais e remotos:

  • Os índices locais e remotos oferecem desempenho de leitura e gravação local de posicionamento, mas sacrificam as propriedades de unicidade e ordenação globais das colunas de índice exclusivas. Em vez disso, os índices locais e remotos fornecem ordenação e exclusividade das colunas indexadas na linha principal em que estão entrelaçados.
  • Ao usar índices locais ou remotos, inclua o local de posicionamento no predicado de consulta, exceto nos casos em que também há um índice global exclusivo que permite ao Spanner adivinhar o local de posicionamento local. Caso contrário, o plano de consulta e o desempenho não serão deterministas. O Spanner pode realizar uma verificação da tabela de base ou dispersar e coletar do índice em locais de posicionamento com base nas estatísticas de consulta, aumentando a latência.

Quando escolher índices globais únicos com índices locais ou remotos

Considere o seguinte ao escolher uma combinação de índices globais exclusivos com índices locais ou remotos:

  • Quando o local de posicionamento específico é desconhecido, use uma combinação de índices globais exclusivos com índices locais ou remotos. Essa abordagem é ideal quando a maioria das consultas se origina de serviços geograficamente situados na mesma região em que os dados solicitados estão localizados.
  • Ao gravar índices globais, a latência de gravação está sujeita a uma latência de quorum de gravação padrão adicional.
  • Com a otimização baseada em heurística, as consultas são atendidas por fragmentos de índice local e demonstram latência intrarregional na maioria das vezes.

Diretrizes detalhadas para escolher um índice para projetos de esquema específicos

A estratégia de indexação ideal depende da estrutura da chave primária da tabela e dos padrões de consulta do aplicativo. Esta seção fornece orientações para selecionar o tipo de índice adequado para três designs de esquema comuns:

  • Esquemas que usam uma entidade como chave primária
  • Esquemas que usam a localização como chave primária
  • Esquemas que usam valores relacionados a locais como chave primária

Design do esquema: entidade como chave primária

Se o esquema usar uma entidade como chave primária, escolha a estratégia de indexação com base na especificação ou não de um local nas consultas.

Nos casos em que uma entidade como customerID é a chave primária e uma coluna separada sem chave, como location, é a chave de posicionamento, determine sua estratégia de indexação para a tabela de posicionamento com base nos padrões de consulta. Não use uma entidade como chave primária da tabela de posição se a latência de inserção for uma preocupação para as entidades.

Se você quiser indexar dados em uma entidade específica, como customerID, use um índice local. Os dados são indexados e classificados dentro da entidade, mas não entre elas. Por exemplo, se você quiser indexar os pedidos de cada cliente por data, crie um índice local intercalado na identidade customerID.

Quando a localização é sempre conhecida nas suas consultas, use uma das seguintes estratégias:

  • Se a localização for sempre conhecida nas suas consultas e não for necessário impor a exclusividade global, use índices remotos. Esses índices fornecem latência intrarregional para operações de leitura e gravação.

    Os índices remotos só são compatíveis com colunas de indexação na tabela de posicionamento, não em colunas de tabelas intercaladas. O índice remoto precisa ser intercalado na tabela de posicionamento raiz. O índice remoto indexa dados em todas as linhas de posição da posição.

Nos casos em que a localização não é sempre conhecida nas suas consultas, use uma das seguintes estratégias:

  • Se a coluna indexada for globalmente exclusiva, crie um índice global exclusivo para impor essa exclusividade.

    Para conseguir leituras consistentes de baixa latência, crie um índice remoto além de um índice global exclusivo.

    Com essa combinação, as gravações podem gerar latência entre regiões, enquanto as consultas com um local especificado (com WHERE location= @location) se beneficiam da latência intrarregional usando o índice remoto. Para consultas sem um local especificado, o Spanner usa uma otimização baseada em heurística, pesquisando primeiro localmente. Se os dados não forem encontrados, o sistema vai usar o índice global.

    Se você estiver usando regiões de concessão de leitura e tiver uma réplica somente leitura da partição padrão na mesma região dos seus dados, um índice remoto será desnecessário porque as regiões de concessão de leitura já oferecem baixa latência de leitura forte para leituras de um índice global.

  • Se a consulta não especificar um local e as colunas indexadas não forem globalmente exclusivas, crie apenas um índice global (não exclusivo). Adicionar um índice local ou remoto não melhora a latência de leitura nesse caso porque o Spanner não consegue determinar se há dados correspondentes em outro posicionamento, mesmo que encontre dados no posicionamento local.

Design do esquema: local como chave primária

Quando uma coluna location serve como chave primária e de posição, a seleção de índice é informada por problemas de latência cruzada e se as consultas sempre especificam o local.

  • Se a latência entre regiões não for um problema ou se você precisar de exclusividade global, use índices globais.
  • Se a latência entre regiões for uma preocupação, suas consultas sempre incluirão o local, e você não precisará que o Spanner aplique a exclusividade global. Use apenas índices locais. Isso garante a latência local para leituras e gravações.

  • Se a latência de consulta entre regiões for um problema, a latência de gravação entre regiões for aceitável e o local nem sempre for conhecido, as seguintes estratégias serão aplicáveis:

    Condição Recomendação
    Consultar por chave primária parcial que seja globalmente exclusiva

    Crie um índice global exclusivo para garantir a exclusividade. Um índice local não é necessário porque a chave primária realiza uma função semelhante. A otimização baseada em heurística é aplicada. Primeiro, o Spanner verifica a chave primária completa com o local antes de voltar ao índice global.

    Para ver um exemplo, consulte Índice global exclusivo em chaves primárias parciais.

    Consultar por coluna globalmente exclusiva sem chave

    Crie um índice global exclusivo para garantir a exclusividade.

    Para latência intrarregional, os seguintes cenários são possíveis:

    • Crie um índice local na mesma coluna do índice global. A otimização baseada em heurística é aplicada. A combinação de índices globais e locais oferece baixa latência para consultas fortes e desatualizadas na mesma região, enquanto gravações e consultas e gravações entre regiões têm latência entre regiões.
    • Se houver uma réplica de leitura/gravação ou somente leitura da partição padrão na mesma região dos seus dados, faça o seguinte:
      • Se você só precisar de latência intrarregional para leituras desatualizadas, mas não para leituras consistentes, não será necessário um índice local. A réplica local oferece latência intrarregional.
      • Se você precisar de latência intrarregional para leituras consistentes, crie um índice local na mesma coluna do índice global ou use regiões de concessão de leitura. As regiões de leitura de lease oferecem baixa latência de leitura forte à custa da latência de gravação.
    A coluna indexada não é globalmente exclusiva Crie apenas um índice global. Um índice local não melhora a latência de leitura porque o Spanner pode precisar verificar todos os locais.

Se esses três cenários não se aplicarem ao seu caso de uso, provavelmente será necessário sacrificar a simplicidade do aplicativo ou a latência de gravação fornecendo o local de forma consistente.

Se a chave primária da sua tabela for baseada em valores relacionados a locais, mas não for diretamente a coluna de chave de posicionamento (por exemplo, usando country como chave primária quando você tem menos posicionamentos do que países), use um índice global ou local (intercalado na coluna country). No entanto, os índices remotos não são compatíveis com tabelas intercaladas em tabelas de posicionamento desse tipo.

A otimização baseada em heurística não é compatível com índices locais neste cenário. Portanto, você só alcança a latência local quando sua consulta especifica explicitamente o prefixo da chave primária.