Index et partitionnement géographique

Spanner propose plusieurs types d'index pour améliorer les performances des requêtes. Il est essentiel de choisir le bon type d'index pour votre schéma et vos modèles de requête, en particulier pour les bases de données qui utilisent le partitionnement géographique. Cette page décrit les avantages des différents types d'index et les bonnes pratiques pour sélectionner et utiliser les index Spanner avec le partitionnement géographique.

Types d'index

Spanner est compatible avec les index globaux, locaux et distants. Chaque type présente des caractéristiques de performances et des cas d'utilisation différents. Pour les bases de données géopartitionnées, il est important de comprendre ces types d'index. Le choix du bon index vous aide à optimiser le schéma et les requêtes de votre base de données, ce qui peut améliorer considérablement la latence de votre base de données partitionnée par zone géographique. Pour les bases de données qui n'utilisent pas le partitionnement géographique, il est moins important de comprendre ces types d'index, car ils sont tous stockés dans l'emplacement par défaut et présentent des caractéristiques de performances similaires.

Index globaux

Un index global est le type d'index par défaut dans Spanner. Les données d'index sont stockées dans la partition par défaut, qui peut ne pas être colocalisée avec les données de la table. La création d'index globaux sur des tables géopartitionnées peut entraîner des latences d'écriture beaucoup plus élevées pour les écritures impliquant les colonnes indexées, en particulier si le quorum d'écriture par défaut pour l'index est loin du quorum d'écriture des lignes de table qui sont écrites. Vous pouvez réduire les latences de lecture des index globaux en utilisant des répliques en lecture seule à proximité des régions read lease ou des lectures obsolètes.

Les index globaux présentent les caractéristiques suivantes :

  • Ils accélèrent les requêtes qui nécessiteraient autrement une analyse complète de la table et garantissent l'unicité de toutes les lignes de la table, quel que soit leur emplacement.
  • Elles conviennent aux colonnes qui nécessitent des valeurs uniques dans une base de données.
  • Ils accélèrent les requêtes qui filtrent ou trient les colonnes indexées.

Voici un exemple d'index unique global :

CREATE UNIQUE INDEX idx_customer_email ON customer(email);

Index locaux

Un index local est entrelacé dans la hiérarchie parente de la table indexée. Les noms et les types des colonnes de clé primaire doivent correspondre à ceux de la table indexée.

Les index locaux présentent les caractéristiques suivantes :

  • Ils stockent les données d'index dans la même partition que les données indexées. La latence d'écriture est soumise au quorum d'écriture de l'emplacement spécifique, et non à celui de l'emplacement par défaut.

  • Elles offrent la latence la plus faible pour les requêtes ciblant un préfixe de clé spécifique, car les données d'index et de table sont colocalisées dans le même emplacement.

Pour créer un index local, entrelacez-le dans la table parente. Si vous utilisez un index local UNIQUE, l'unicité n'est appliquée qu'à une ligne parente spécifique, et non à l'ensemble de la table.

Voici un exemple de création d'un index local sur la table customer, entrelacée dans la table parente 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;

Lorsque vous interrogez des données dans une transaction en lecture/écriture, vous devez spécifier le préfixe de clé primaire de la table indexée dans la requête. Sinon, la requête peut nécessiter une analyse complète de la table. Exemple :

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;

Pour en savoir plus sur l'optimisation qui ne nécessite pas de spécifier l'emplacement, consultez Utiliser un index unique global avec un index local ou distant.

Un index local est également utile lorsque la table d'emplacements est basée sur des entités et que vous souhaitez indexer des données au sein d'une entité ou d'une sous-entité spécifique. Exemple :

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;

Index distants

Un index distant entrelace les données d'index sous une table qui n'est pas un ancêtre dans la hiérarchie d'entrelacement de la table indexée. Les types de clés primaires doivent correspondre à ceux des colonnes d'index correspondantes, mais les noms peuvent être différents.

Avec le partitionnement géographique, vous ne pouvez imbriquer un index distant que dans la table d'emplacement racine gérée automatiquement. Ce tableau contient une ligne pour chaque emplacement de votre base de données.

Les index distants présentent les caractéristiques suivantes :

  • Elles sont particulièrement utiles lorsque la clé primaire de votre table n'est pas préfixée à l'aide d'une clé d'emplacement, mais que vous souhaitez colocaliser géographiquement les partitions de l'index en fonction de la clé d'emplacement.
  • Ils ne sont compatibles qu'avec l'indexation des colonnes de la table d'emplacement, et non avec les colonnes des tables enfants entrelacées.

Pour utiliser des index distants avec le partitionnement géographique, créez la table d'emplacement racine en définissant l'option auto_managed_root_placement_table_name dans l'instruction LDD ALTER DATABASE.

  1. Utilisez l'instruction ALTER DATABASE DDL pour créer une table d'emplacement racine.

    GoogleSQL 

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

    Remplacez les éléments suivants :

    • DATABASE_NAME : nom de votre base de données.
    • TABLE_NAME : nom de la table à créer. Nous vous recommandons d'utiliser le nom root_placement_table.

    Par exemple, la commande suivante crée une table appelée root_placement_table.

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

    Une fois la table d'emplacement racine créée, Spanner crée une table interne, puis insère et supprime automatiquement des lignes lorsque vous créez ou supprimez un emplacement. Voici un exemple de table d'emplacement définie par le système et créée par Spanner, où le nom de la table est défini sur root_placement_table. (N'exécutez pas cet exemple.)

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

    Remplacez les éléments suivants :

    • DATABASE_NAME : nom de votre base de données.
    • TABLE_NAME : nom de la table à créer.

    Par exemple, pour créer une table root_placement_table qui est utilisée comme racine d'entrelacement, exécutez la commande suivante :

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

    Une fois la table d'emplacement racine créée, Spanner crée une table interne, puis insère et supprime automatiquement des lignes lorsque vous créez ou supprimez un emplacement. Voici un exemple de table d'emplacement définie par le système et créée par Spanner, où le nom de la table est défini sur root_placement_table. (N'exécutez pas cet exemple.)

    // 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. Créez un index distant entrelacé sous la table root_placement_table gérée automatiquement.

    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. Lorsque vous interrogez des données dans une transaction en lecture/écriture, spécifiez le préfixe de clé de l'index dans le prédicat de requête afin qu'une analyse complète de la table ne soit pas nécessaire. Exemple :

    GoogleSQL 

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

    Pour en savoir plus sur l'optimisation qui ne nécessite pas de spécifier l'emplacement, consultez la section Index unique global avec index local ou distant.

    PostgreSQL 

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

    Pour en savoir plus sur l'optimisation qui ne nécessite pas de spécifier l'emplacement, consultez la section Index unique global avec index local ou distant.

Optimisations pour les index uniques globaux

Lorsque vous utilisez un index unique global, Spanner peut déclencher des améliorations de la latence des requêtes grâce à des optimisations basées sur des heuristiques dans les cas d'utilisation suivants :

  • Lorsque vous utilisez un index unique global avec un index local ou distant
  • Lorsque vous utilisez un index unique global avec des clés primaires partielles

Les sections suivantes décrivent comment Spanner peut appliquer des optimisations dans chaque cas d'utilisation.

Index unique global avec un index local ou distant

Pour améliorer la latence des requêtes locales, Spanner peut lancer une optimisation basée sur des heuristiques lorsqu'un index unique global est associé à un index local ou distant.

Cette optimisation réduit la latence des requêtes intrarégionales, même lorsque l'emplacement des données géopartitionnées n'est pas spécifié. Pour ce faire, elle suppose que l'emplacement est le même que celui du client et contourne la partition par défaut de l'index global, ou élimine la nécessité d'effectuer des analyses filtrées de tables complètes. Cette approche est particulièrement utile lorsque les clients accèdent principalement aux données stockées dans leur propre région.

Il est utile d'utiliser différents types d'index si la latence des requêtes intrarégionales est la principale préoccupation et que vous pouvez tolérer une augmentation de la latence d'écriture. La combinaison de différents types d'index améliore également les performances des requêtes intrarégionales, même lorsque vous ne spécifiez pas l'emplacement dans votre requête.

Pour cette optimisation, vous devez créer un index unique global et un index local ou distant correspondant sur la même colonne. Les données indexées doivent être uniques au niveau mondial. Spanner applique cette optimisation à votre requête si les conditions suivantes sont remplies :

  • Vous ne connaissez pas le préfixe de clé primaire et ne spécifiez pas l'emplacement des données.
  • Votre demande provient de la même région que le leader par défaut de l'emplacement des données, qui contient le segment d'index local ou distant.

Spanner applique l'optimisation de la manière suivante :

  • Si l'optimisation est déclenchée et que la ligne est trouvée dans l'emplacement local : étant donné l'index unique global, Spanner n'a pas besoin de rechercher d'autres emplacements. Votre requête présente une latence intrarégionale.
  • Si la recherche initiale de localisation ne renvoie aucune ligne : cela indique qu'il ne s'agit pas d'une requête intrarégionale. Spanner revient à l'utilisation de l'index global.

L'exemple suivant crée un index unique global et un index 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;

L'exemple suivant crée un index unique global et un index distant :

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;

En fonction des index de l'exemple précédent, l'exemple de requête suivant présente une latence intrarégionale :

GoogleSQL 

SELECT *
FROM customer
WHERE email= @email;

PostgreSQL 

SELECT *
FROM customer
WHERE email= @email;

Index unique global sur les clés primaires partielles

Spanner peut appliquer une optimisation semblable à celle décrite dans Utiliser un index unique global avec un index local ou distant lors de l'utilisation d'un index unique global sur des clés primaires partielles.

L'exemple suivant crée une table customer imbriquée dans la table parente locations, puis crée un index unique global sur la colonne 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);

L'optimisation s'applique aux requêtes telles que les suivantes :

GoogleSQL 

SELECT * FROM customer WHERE customerId= @customerId;

PostgreSQL 

SELECT * FROM customer WHERE customerId= @customerId;

Si vous ne créez pas l'index unique global, cette requête peut nécessiter une analyse complète de la table. Si vous n'utilisez pas l'index unique global, vous devez ajouter le filtre de localisation à votre requête pour obtenir une bonne latence :

GoogleSQL 

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

PostgreSQL 

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

Consignes générales pour choisir un type d'index pour une latence optimale

Le type d'index que vous choisissez a un impact direct sur la latence des requêtes. L'emplacement des données d'index par rapport aux données de table est un facteur de performances essentiel pour les charges de travail géopartitionnées.

Cette section explique comment choisir entre les index globaux, locaux et distants.

Quand choisir les index mondiaux ?

Utilisez des index globaux si votre charge de travail peut tolérer la latence de lecture et d'écriture associée, ou si vous avez besoin d'une unicité globale forcée sur les colonnes indexées.

Tenez compte des éléments suivants lorsque vous choisissez des index globaux :

  • L'augmentation de la latence d'écriture est déterminée par la distance entre le client et le leader du quorum d'écriture par défaut, ainsi que par la latence par défaut du quorum. Cet effet est spécifiquement limité aux opérations impliquant des colonnes indexées, telles que les insertions de lignes ou les mises à jour de colonnes indexées.
  • L'ajout d'instances répliquées en lecture seule ou l'utilisation de baux de lecture peuvent atténuer l'augmentation de la latence de lecture :
    • L'ajout d'une instance répliquée en lecture seule à proximité géographique peut réduire la latence de lecture non actualisée.
    • L'ajout d'une instance répliquée en lecture seule et l'utilisation de régions de bail de lecture peuvent réduire la latence de lecture forte. Si vous ajoutez une instance répliquée en lecture seule sans utiliser de région de bail de lecture, la latence de lecture forte n'est pas réduite, mais le débit de lecture peut augmenter.
    • Spanner diffuse toujours les lectures transactionnelles pessimistes à partir du leader. L'ajout de répliques à l'emplacement par défaut n'aide pas à effectuer des lectures transactionnelles pessimistes des données dans les emplacements par défaut.
  • Les index globaux (y compris les clés et les valeurs de stockage) sont placés dans l'emplacement par défaut, qui ne fournit pas de résidence des données au niveau de l'emplacement. Pour en savoir plus, consultez la présentation de la résidence des données Spanner.

Quand choisir des index locaux et distants

Tenez compte des éléments suivants lorsque vous choisissez des index locaux et distants :

  • Les index locaux et distants offrent des performances de lecture et d'écriture locales à l'emplacement, mais sacrifient l'unicité globale et les propriétés d'ordre des colonnes d'index uniques. En revanche, les index locaux et distants fournissent l'ordre et l'unicité des colonnes indexées dans la ligne parente dans laquelle elles sont entrelacées.
  • Lorsque vous utilisez des index locaux ou distants, vous devez inclure l'emplacement de la zone dans le prédicat de requête, sauf s'il existe également un index unique global qui permet à Spanner de deviner l'emplacement de la zone locale. Sinon, le plan de requête et les performances ne sont pas déterministes. Spanner peut effectuer une analyse de la table de base ou une opération de dispersion et collecte à partir de l'index dans les emplacements en fonction des statistiques de requête, ce qui augmente la latence.

Quand choisir des index uniques globaux avec des index locaux ou distants

Tenez compte des éléments suivants lorsque vous choisissez une combinaison d'index uniques globaux avec des index locaux ou distants :

  • Lorsque l'emplacement spécifique est inconnu, utilisez une combinaison d'index uniques globaux avec des index locaux ou distants. Cette approche est idéale lorsque la plupart des requêtes proviennent de services situés géographiquement dans la même région que l'emplacement des données demandées.
  • Lorsque vous écrivez des index globaux, la latence d'écriture est soumise à une latence de quorum d'écriture par défaut supplémentaire.
  • Avec l'optimisation basée sur l'heuristique, les requêtes sont traitées par des partitions d'index locales et présentent une latence intrarégionale la plupart du temps.

Consignes détaillées pour choisir un index pour des conceptions de schéma spécifiques

La stratégie d'index optimale dépend de la structure de la clé primaire de votre table et des modèles de requête de votre application. Cette section fournit des conseils pour sélectionner le type d'index approprié pour trois conceptions de schéma courantes :

  • Schémas qui utilisent une entité comme clé primaire
  • Schémas qui utilisent l'emplacement comme clé primaire
  • Schémas qui utilisent des valeurs liées à la localisation comme clé primaire

Conception du schéma : l'entité comme clé primaire

Si votre schéma utilise une entité comme clé primaire, choisissez votre stratégie d'indexation en fonction de la présence ou non d'un emplacement dans vos requêtes.

Si une entité telle que customerID est la clé primaire et qu'une colonne non clé distincte telle que location est la clé d'emplacement, déterminez votre stratégie d'indexation pour la table d'emplacement en fonction de vos modèles de requête. (N'utilisez pas d'entité comme clé primaire de la table d'emplacement si la latence d'insertion est un problème pour les entités.)

Si vous souhaitez indexer des données sous une entité particulière, telle que customerID, utilisez un index local. Les données sont indexées et triées au sein de l'entité, mais pas entre elles. Par exemple, si vous souhaitez indexer les commandes de chaque client par date, vous pouvez créer un index local entrelacé sous l'identité customerID.

Lorsque la localisation est toujours connue dans vos requêtes, utilisez l'une des stratégies suivantes :

  • Si la localisation est toujours connue dans vos requêtes et que l'application de l'unicité globale n'est pas requise, utilisez des index distants. Ces index fournissent la latence intrarégionale pour les opérations de lecture et d'écriture.

    Les index distants ne permettent d'indexer que les colonnes de la table d'emplacements, et non celles des tables entrelacées. L'index distant doit être entrelacé sous la table d'emplacement racine. L'index distant indexe les données de toutes les lignes d'emplacement pour l'emplacement.

Dans les cas où la localisation n'est pas toujours connue dans vos requêtes, utilisez l'une des stratégies suivantes :

  • Si la colonne indexée est unique au niveau mondial, créez un index unique global pour appliquer cette unicité.

    Pour obtenir des lectures fortes à faible latence, créez un index distant en plus d'un index unique global.

    Avec cette combinaison, les écritures peuvent entraîner une latence interrégionale, tandis que les requêtes avec un emplacement spécifié (avec WHERE location= @location) bénéficient d'une latence intrarégionale en utilisant l'index distant. Pour les requêtes sans emplacement spécifié, Spanner utilise une optimisation basée sur l'heuristique en effectuant d'abord une recherche locale. Si les données ne sont pas trouvées, elles sont redirigées vers l'index mondial.

    Si vous utilisez des régions de bail de lecture et que vous disposez d'une instance répliquée en lecture seule de la partition par défaut dans la même région que vos données, un index distant n'est pas nécessaire, car les régions de bail de lecture offrent déjà une faible latence de lecture forte pour les lectures d'un index global.

  • Si votre requête ne spécifie pas d'emplacement et que les colonnes indexées ne sont pas uniques au niveau mondial, ne créez qu'un index global (non unique). Dans ce cas, l'ajout d'un index local ou distant n'améliore pas la latence de lecture, car Spanner ne peut pas déterminer s'il existe des données correspondantes dans un autre emplacement, même s'il en trouve dans l'emplacement local.

Conception du schéma : l'emplacement comme clé primaire

Lorsqu'une colonne location sert à la fois de clé primaire et de clé d'emplacement, votre sélection d'index est basée sur les problèmes de latence croisée et sur le fait que vos requêtes spécifient ou non l'emplacement.

  • Si la latence entre les régions n'est pas un problème ou si vous avez besoin d'une unicité globale, utilisez des index globaux.
  • Si la latence interrégionale vous inquiète, vos requêtes incluent toujours l'emplacement. Si vous n'avez pas besoin que Spanner applique l'unicité globale, utilisez uniquement des index locaux. Cela garantit une latence locale pour les lectures et les écritures.

  • Si la latence des requêtes interrégionales est un problème, mais que la latence des écritures interrégionales est acceptable et que l'emplacement n'est pas toujours connu, les stratégies suivantes s'appliquent :

    Condition Recommandation
    Interroger par clé primaire partielle unique au niveau mondial

    Créez un index global unique pour garantir l'unicité. Un index local n'est pas nécessaire, car la clé primaire remplit une fonction similaire. L'optimisation basée sur les heuristiques s'applique. Tout d'abord, Spanner vérifie la clé primaire complète avec l'emplacement local avant de revenir à l'index global.

    Pour obtenir un exemple, consultez Index unique global sur les clés primaires partielles.

    Interroger par colonne non clé unique au niveau mondial

    Créez un index global unique pour garantir l'unicité.

    Pour la latence intrarégionale, les scénarios suivants sont possibles :

    • Créez un index local sur la même colonne que l'index global. L'optimisation basée sur les heuristiques s'applique. La combinaison d'index mondiaux et locaux offre une faible latence pour les requêtes fortes et obsolètes intrarégionales, tandis que les écritures et les requêtes et écritures interrégionales ont une latence interrégionale.
    • S'il existe une instance dupliquée en lecture/écriture ou en lecture seule de la partition par défaut dans la même région que vos données, alors :
      • Si vous n'avez besoin de la latence intrarégionale que pour les lectures non actualisées, mais pas pour les lectures fortes, vous n'avez pas besoin d'index local. La réplique locale fournit une latence intrarégionale.
      • Si vous avez besoin d'une latence intrarégionale pour les lectures fortes, vous pouvez créer un index local sur la même colonne que l'index global ou utiliser des régions de bail de lecture. Les régions avec bail de lecture offrent une faible latence de lecture forte au détriment de la latence d'écriture.
    La colonne indexée n'est pas unique au niveau mondial Créer uniquement un index global. Un index local n'améliore pas la latence de lecture, car Spanner peut avoir besoin de vérifier tous les emplacements.

Si ces trois scénarios ne s'appliquent pas à votre cas d'utilisation, vous devrez probablement sacrifier la simplicité de l'application ou la latence d'écriture en fournissant systématiquement la position.

Si la clé primaire de votre tableau est basée sur des valeurs liées à la localisation, mais qu'il ne s'agit pas directement de la colonne de clé d'emplacement (par exemple, si vous utilisez country comme clé primaire alors que vous avez moins d'emplacements que de pays), vous pouvez utiliser un index global ou un index local (entrelacé sous la colonne country). Toutefois, les index distants ne sont pas acceptés pour les tables entrelacées sous ce type de table d'emplacement.

L'optimisation basée sur l'heuristique n'est pas compatible avec les index locaux dans ce scénario. Par conséquent, vous n'obtenez une latence locale que lorsque votre requête spécifie explicitement le préfixe de clé primaire.