Contrôle de simultanéité

Les transactions Spanner proposent deux modes de contrôle de la concurrence : pessimiste et optimiste. Le choix du mode de contrôle de la concurrence affecte la façon dont les transactions gèrent les lectures et les écritures simultanées, ce qui a une incidence sur les performances, la latence et les taux d'abandon des transactions. Choisissez le mode qui correspond le mieux aux exigences de performances et de cohérence de votre application.

Le comportement par défaut dépend du niveau d'isolation utilisé par votre transaction :

• L'isolation sérialisable utilise par défaut un contrôle de concurrence pessimiste.
• L'isolation de lecture reproductible utilise le contrôle de simultanéité optimiste par défaut.

Contrôle de simultanéité pessimiste

Remarque : Spanner n'est pas compatible avec l'utilisation du contrôle de concurrence pessimiste avec l'isolation de lecture répétable.

Par défaut, Spanner utilise la concurrence pessimiste avec l'isolation sérialisable. Ce mode suppose que des transactions simultanées peuvent entrer en conflit pour les mêmes données. Il acquiert des verrous de manière proactive sur les données lorsqu'elles sont lues ou écrites dans une transaction. Il vérifie également que les verrous acquis plus tôt dans la transaction restent en place dans les instructions ultérieures. Lorsque Spanner détecte un conflit de verrouillage, il utilise l'algorithme wound-wait pour le résoudre.

Dans la simultanéité pessimiste, les transactions acquièrent des verrous sur les données pendant les phases d'exécution et de commit de la transaction.

• Pour les lectures : lorsqu'une transaction lit des données, elle acquiert un verrou en lecture partagé (ReaderShared) pendant la phase d'exécution. Ces verrouillages sont conservés jusqu'à ce que la transaction soit validée.
• Pour le LMD et les écritures :
  • Lors de l'exécution, pour les données modifiées par LMD ou les écritures, la transaction peut acquérir des verrous de lecture sur l'existence des lignes.
  • Au moment de la validation, la transaction tente d'acquérir des verrous d'écriture ou exclusifs pour les données écrites. Les verrous d'écriture bloquent les lectures simultanées, mais peuvent ne pas bloquer les écritures simultanées, en particulier lorsqu'elles utilisent toutes les deux des verrous d'écriture. Cela signifie que plusieurs transactions peuvent être validées et que les conflits d'écriture sont résolus au moment de la validation à l'aide de l'algorithme wound-wait. Tous les verrous sont conservés jusqu'à ce que la transaction soit validée.

Avantages de la concurrence pessimiste avec l'isolation sérialisable

Le principal avantage de l'utilisation de la simultanéité pessimiste avec l'isolation sérialisable est qu'elle permet aux transactions de progresser dans les charges de travail très conflictuelles. En cas de conflit, Spanner donne la priorité aux transactions plus anciennes par rapport aux plus récentes. Cela permet de s'assurer que les transactions finissent par se terminer, tout en réduisant le nombre de transactions annulées à plusieurs reprises.

Risques liés à la simultanéité pessimiste

La concurrence pessimiste avec isolation sérialisable présente les risques suivants :

• Les lectures de longue durée peuvent bloquer les écritures sensibles à la latence.
• Les transactions qui impliquent une interaction de l'utilisateur avant leur finalisation peuvent entraîner le maintien des verrous pendant une longue période, ce qui peut bloquer d'autres opérations.

Cas d'utilisation de la concurrence pessimiste

La simultanéité pessimiste convient aux charges de travail avec une forte contention en lecture/écriture et en écriture/écriture. Il convient également lorsque les annulations et les nouvelles tentatives de transactions sont coûteuses. Utilisez ce mode par défaut, sauf si votre charge de travail présente des délais de verrouillage longs excessifs ou est fortement affectée par les conflits de verrouillage.

Contrôle de simultanéité optimiste

Spanner fournit également un contrôle de simultanéité optimiste. Lorsque vous utilisez l'isolation de lecture reproductible, le mode par défaut est le contrôle de simultanéité optimiste. Vous pouvez également configurer l'isolation sérialisable pour utiliser le contrôle de concurrence optimiste.

Le contrôle de simultanéité optimiste suppose que les conflits sont rares. Les lectures et les requêtes, même dans une transaction en lecture-écriture, se déroulent sans acquérir de verrous. Avec l'isolation sérialisable par défaut de Spanner, les lectures sont validées au moment du commit. Cela garantit qu'aucune autre transaction validée simultanément n'a modifié les données précédemment lues par la transaction. Si vous utilisez l'isolation de lecture reproductible, les lectures avec un indice FOR UPDATE ou lock_scanned_ranges=exclusive sont validées au moment de la validation. Si Spanner détecte un conflit, il abandonne la transaction.

Fonctionnement de la simultanéité optimiste

La simultanéité optimiste modifie la façon dont Spanner exécute les lectures, les requêtes et les commits de transactions. Il effectue une exécution sans verrouillage pendant la phase de lecture et valide la cohérence lors de la validation.

Pour les lectures et les requêtes

Les lectures et les requêtes sont sans verrouillage. Toutes les lectures et requêtes d'une transaction optimiste s'exécutent à un seul code temporel d'instantané. Spanner choisit cet horodatage lorsque la première lecture ou requête s'exécute. Cela garantit que toutes les lectures et requêtes ultérieures de la transaction voient les écritures validées avant la première lecture ou requête.

Pour les lectures et les écritures

Pour une transaction optimiste avec des lectures et des écritures, Spanner effectue une étape de validation au moment du commit. La transaction n'est validée que si aucun conflit n'est détecté et si les conditions suivantes sont remplies :

• Aucune écriture validée simultanément n'est en conflit avec les données lues par cette transaction. En d'autres termes, aucune écriture n'a été validée après l'horodatage de lecture, mais avant que cette transaction ne valide ses propres écritures.
• Le schéma n'a pas été modifié depuis l'horodatage de lecture.

Le niveau d'isolation détermine l'ensemble des lectures qui sont validées. Avec l'isolation sérialisable, toutes les lectures sont validées. Avec l'isolation de lecture répétable, les lectures avec un indice FOR UPDATE ou lock_scanned_ranges=exclusive sont validées au moment du commit.

En cas de forte contention, les transactions optimistes peuvent être abandonnées à plusieurs reprises. En revanche, les transactions pessimistes résolvent les conflits de lecture-écriture en permettant à l'ancienne transaction d'être validée et en relançant la nouvelle transaction.

Avantages de la simultanéité optimiste

La concurrence optimiste offre les avantages suivants :

• Les lectures n'acquièrent pas de verrous : les transactions optimistes n'acquièrent pas de verrous pour les lectures. Ainsi, les lectures de longue durée ne bloquent pas les écritures sensibles à la latence.
• Latence de validation réduite pour les transactions en lecture seule : étant donné que toutes les lectures d'une transaction optimiste sont basées sur le même horodatage d'instantané, il n'est pas nécessaire de vérifier la cohérence lors de l'exécution ou de la validation de ces lectures, ce qui réduit considérablement la latence.

Risques liés à la simultanéité optimiste

La concurrence optimiste présente des risques, en particulier en cas de forte contention en lecture/écriture lorsqu'elle est utilisée avec l'isolation sérialisable. Comprenez ces risques avant d'utiliser le contrôle de concurrence optimiste avec l'isolation sérialisable pour votre charge de travail.

• En cas de forte contention en lecture-écriture, les transactions optimistes peuvent présenter un taux d'abandon élevé, car les écritures simultanées peuvent invalider les lectures d'une transaction optimiste.
• En cas de contention élevée persistante, une transaction peut être annulée à plusieurs reprises et ne jamais être validée en raison d'un manque de transactions.

Cas d'utilisation de la simultanéité optimiste

La concurrence optimiste convient aux charges de travail transactionnelles avec une faible contention en lecture/écriture. Pour les transactions sérialisables, il profite également aux charges de travail qui peuvent tolérer les annulations de transactions.

Envisagez la concurrence optimiste pour les charges de travail suivantes :

• Charges de travail à faible priorité et tolérantes à la latence avec des transactions de longue durée : utilisez la concurrence optimiste si les lectures ou les requêtes de longue durée peuvent retarder les écritures sensibles à la latence. Cela permet d'éviter les retards causés par les verrouillages en lecture. Par exemple, les transactions dans les clients mobiles avec des connexions lentes, ou les transactions à faible SLA détenant des verrous de lecture pour de nombreuses lignes ou de grandes plages.
• Charges de travail transactionnelles sensibles à la latence de lecture avec une faible contention en lecture-écriture : dans une configuration multirégionale, utilisez la concurrence optimiste pour diffuser les lectures au niveau régional, réduire les latences de lecture et éviter les problèmes de production liés à un pic de trafic de lecture vers un fractionnement actif. Elle améliore également la disponibilité en lecture en cas de surcharge ou d'indisponibilité du leader.
• Charges de travail transactionnelles où la plupart des transactions sont en lecture seule : le passage à la simultanéité optimiste réduit la latence de validation pour les transactions en lecture seule courantes dans ces charges de travail. Assurez-vous que les conflits de lecture-écriture sont faibles pour éviter des taux d'abandon élevés pour les transactions en lecture-écriture.

Évitez d'utiliser la simultanéité optimiste pour les charges de travail transactionnelles sensibles à la latence où les conflits de lecture/écriture sont fréquents.

Configurer le contrôle de simultanéité

Vous pouvez utiliser les bibliothèques clientes, l'API REST et l'API RPC Spanner pour spécifier le mode de simultanéité des transactions en lecture/écriture.

Bibliothèques clientes

Java

static void readLockModeSetting(DatabaseId db) {
  // The read lock mode specified at the client-level will be applied to all
  // RW transactions.
  DefaultReadWriteTransactionOptions transactionOptions =
      DefaultReadWriteTransactionOptions.newBuilder()
          .setReadLockMode(ReadLockMode.OPTIMISTIC)
          .build();
  SpannerOptions options =
      SpannerOptions.newBuilder()
          .setDefaultTransactionOptions(transactionOptions)
          .build();
  Spanner spanner = options.getService();
  DatabaseClient dbClient = spanner.getDatabaseClient(db);
  dbClient
      // The read lock mode specified at the transaction-level takes precedence
      // over the read lock mode configured at the client-level.
      .readWriteTransaction(Options.readLockMode(ReadLockMode.PESSIMISTIC))
      .run(transaction -> {
        // Read an AlbumTitle.
        String selectSql =
            "SELECT AlbumTitle from Albums WHERE SingerId = 1 and AlbumId = 1";
        String title = null;
        try (ResultSet resultSet = transaction.executeQuery(Statement.of(selectSql))) {
          if (resultSet.next()) {
            title = resultSet.getString("AlbumTitle");
          }
        }
        System.out.printf("Current album title: %s\n", title);

        // Update the title.
        String updateSql =
            "UPDATE Albums "
                + "SET AlbumTitle = 'New Album Title' "
                + "WHERE SingerId = 1 and AlbumId = 1";
        long rowCount = transaction.executeUpdate(Statement.of(updateSql));
        System.out.printf("%d record updated.\n", rowCount);
        return null;
      });
}

Go

import (
	"context"
	"fmt"
	"io"

	"cloud.google.com/go/spanner"
	pb "cloud.google.com/go/spanner/apiv1/spannerpb"
)

// writeWithTransactionUsingReadLockMode sets the ReadLockMode globally
// by using ClientConfig and shows how to override it for a specific
// transaction. ReadLockMode determines the locking strategy used during
// transaction execution.
func writeWithTransactionUsingReadLockMode(w io.Writer, db string) error {
	ctx := context.Background()

	// Client-level configuration: Applies to all read-write transactions
	// for this client. OPTIMISTIC mode avoids locks during reads and
	// verifies changes during the commit phase.
	cfg := spanner.ClientConfig{
		TransactionOptions: spanner.TransactionOptions{
			ReadLockMode: pb.TransactionOptions_ReadWrite_OPTIMISTIC,
		},
	}
	client, err := spanner.NewClientWithConfig(ctx, db, cfg)
	if err != nil {
		return fmt.Errorf("failed to create client: %w", err)
	}
	defer client.Close()

	// Transaction-level options take precedence over client-level
	// configuration. PESSIMISTIC mode is used here to override the
	// client-level setting and ensure immediate locking during reads.
	txnOpts := spanner.TransactionOptions{
		ReadLockMode: pb.TransactionOptions_ReadWrite_PESSIMISTIC,
	}

	_, err = client.ReadWriteTransactionWithOptions(ctx, func(ctx context.Context, txn *spanner.ReadWriteTransaction) error {
		// In PESSIMISTIC mode with SERIALIZABLE isolation, the transaction
		// acquires a shared lock during this read.
		key := spanner.Key{1, 2}
		row, err := txn.ReadRow(ctx, "Albums", key, []string{"AlbumTitle"})
		if err != nil {
			return fmt.Errorf("failed to read album: %w", err)
		}
		var title string
		if err := row.Column(0, &title); err != nil {
			return fmt.Errorf("failed to get album title: %w", err)
		}
		fmt.Fprintf(w, "Current album title: %s\n", title)

		// Update the album title
		stmt := spanner.Statement{
			SQL: `UPDATE Albums
				SET AlbumTitle = @AlbumTitle
				WHERE SingerId = @SingerId AND AlbumId = @AlbumId`,
			Params: map[string]interface{}{
				"SingerId":   1,
				"AlbumId":    2,
				"AlbumTitle": "New Album Title",
			},
		}
		count, err := txn.Update(ctx, stmt)
		if err != nil {
			return fmt.Errorf("failed to update album: %w", err)
		}
		fmt.Fprintf(w, "Updated %d record(s).\n", count)
		return nil
	}, txnOpts)

	if err != nil {
		return fmt.Errorf("transaction failed: %w", err)
	}
	return nil
}

Node.js

// Imports the Google Cloud Spanner client library
const {Spanner, protos} = require('@google-cloud/spanner');
// The read lock mode specified at the client-level will be applied
// to all RW transactions.
const defaultTransactionOptions = {
  readLockMode:
    protos.google.spanner.v1.TransactionOptions.ReadWrite.ReadLockMode
      .OPTIMISTIC,
};

// Instantiates a client with defaultTransactionOptions
const spanner = new Spanner({
  projectId: projectId,
  defaultTransactionOptions,
});

function runTransactionWithReadLockMode() {
  // Gets a reference to a Cloud Spanner instance and database
  const instance = spanner.instance(instanceId);
  const database = instance.database(databaseId);
  // The read lock mode specified at the request-level takes precedence over
  // the read lock mode configured at the client-level.
  const readLockModeOptionsForTransaction = {
    readLockMode:
      protos.google.spanner.v1.TransactionOptions.ReadWrite.ReadLockMode
        .PESSIMISTIC,
  };

  database.runTransaction(
    readLockModeOptionsForTransaction,
    async (err, transaction) => {
      if (err) {
        console.error(err);
        return;
      }
      try {
        const query =
          'SELECT AlbumTitle FROM Albums WHERE SingerId = 2 AND AlbumId = 1';
        const results = await transaction.run(query);
        // Gets first album's title
        const rows = results[0].map(row => row.toJSON());
        const albumTitle = rows[0].AlbumTitle;
        console.log(`previous album title ${albumTitle}`);

        const update =
          "UPDATE Albums SET AlbumTitle = 'New Album Title' WHERE SingerId = 2 AND AlbumId = 1";
        const [rowCount] = await transaction.runUpdate(update);
        console.log(
          `Successfully updated ${rowCount} record in Albums table.`,
        );
        await transaction.commit();
        console.log(
          'Successfully executed read-write transaction with readLockMode option.',
        );
      } catch (err) {
        console.error('ERROR:', err);
        transaction.end();
      } finally {
        // Close the database when finished.
        await database.close();
      }
    },
  );
}
runTransactionWithReadLockMode();

Python

# instance_id = "your-spanner-instance"
# database_id = "your-spanner-db-id"
from google.cloud.spanner_v1 import TransactionOptions, DefaultTransactionOptions

# The read lock mode specified at the client-level will be applied to all
# RW transactions.
read_lock_mode_options_for_client = TransactionOptions.ReadWrite.ReadLockMode.OPTIMISTIC

# Create a client that uses Serializable isolation (default) with
# optimistic locking for read-write transactions.
spanner_client = spanner.Client(
    default_transaction_options=DefaultTransactionOptions(
        read_lock_mode=read_lock_mode_options_for_client
    )
)
instance = spanner_client.instance(instance_id)
database = instance.database(database_id)

# The read lock mode specified at the request level takes precedence over
# the read lock mode configured at the client level.
read_lock_mode_options_for_transaction = (
    TransactionOptions.ReadWrite.ReadLockMode.PESSIMISTIC
)

def update_albums_with_read_lock_mode(transaction):
    # Read an AlbumTitle.
    results = transaction.execute_sql(
        "SELECT AlbumTitle from Albums WHERE SingerId = 2 and AlbumId = 1"
    )
    for result in results:
        print("Current Album Title: {}".format(*result))

    # Update the AlbumTitle.
    row_ct = transaction.execute_update(
        "UPDATE Albums SET AlbumTitle = 'A New Title' WHERE SingerId = 2 and AlbumId = 1"
    )

    print("{} record(s) updated.".format(row_ct))

database.run_in_transaction(
    update_albums_with_read_lock_mode,
    read_lock_mode=read_lock_mode_options_for_transaction
)

C#

using Google.Cloud.Spanner.Data;
using System;
using System.Threading;
using System.Threading.Tasks;

public class ReadLockModeAsyncSample
{
    public async Task ReadLockModeAsync(string projectId, string instanceId, string databaseId)
    {
        // Create client with ReadLockMode.Optimistic.
        string connectionString = $"Data Source=projects/{projectId}/instances/{instanceId}/databases/{databaseId};ReadLockMode=Optimistic";

        using var connection = new SpannerConnection(connectionString);
        await connection.OpenAsync();

        // Create transaction options with ReadLockMode.Pessimistic.
        var transactionOptions = SpannerTransactionCreationOptions.ReadWrite
            .WithReadLockMode(ReadLockMode.Pessimistic);

        using var transaction = await connection.BeginTransactionAsync(transactionOptions, null, CancellationToken.None);

        var cmd = connection.CreateSelectCommand("SELECT AlbumTitle FROM Albums WHERE SingerId = 2 AND AlbumId = 1");
        cmd.Transaction = transaction;
        using (var reader = await cmd.ExecuteReaderAsync())
        {
            while (await reader.ReadAsync())
            {
                Console.WriteLine($"AlbumTitle: {reader.GetFieldValue<string>("AlbumTitle")}");
            }
        }

        var updateCmd = connection.CreateDmlCommand("UPDATE Albums SET AlbumTitle = 'A New Title' WHERE SingerId = 2 AND AlbumId = 1");
        updateCmd.Transaction = transaction;
        var rowCount = await updateCmd.ExecuteNonQueryAsync();
        Console.WriteLine($"{rowCount} records updated.");

        await transaction.CommitAsync();
    }
}

REST

L'API REST TransactionOptions de Spanner fournit une énumération ReadLockMode dans le message ReadWrite qui vous permet de sélectionner le mode de verrouillage PESSIMISTIC ou OPTIMISTIC.

RPC

L'API RPC Transactionoptions de Spanner fournit une énumération ReadLockMode dans le message ReadWrite qui vous permet de sélectionner le mode de verrouillage PESSIMISTIC ou OPTIMISTIC.

Pilotes

Vous pouvez utiliser les pilotes Spanner pour définir read_lock_mode comme paramètre de connexion au niveau de la connexion ou comme option d'instruction SET au niveau de la transaction. Pour en savoir plus sur chaque pilote, consultez Présentation des pilotes.

Étapes suivantes

• En savoir plus sur les niveaux d'isolation Spanner
• Découvrez comment utiliser l'isolation de lecture répétable.