Contrôle de simultanéité

Les transactions Spanner proposent deux modes de contrôle de simultanéité : pessimiste et optimiste. Le choix du mode de contrôle de simultanéité 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 le contrôle de simultanéité pessimiste par défaut.
• L'isolation de lecture répétée, utilise le contrôle de simultanéité optimiste par défaut.

Contrôle de simultanéité pessimiste

Par défaut, Spanner utilise la simultanéité pessimiste avec l'isolation sérialisable. Vous pouvez également utiliser la simultanéité pessimiste avec l'isolation de lecture répétée.

Simultanéité pessimiste dans l'isolation sérialisable

Ce mode suppose que les transactions simultanées peuvent se disputer 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 actifs 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 de lecture partagé (ReaderShared) pendant la phase d'exécution. Ces verrous 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 le LMD ou les écritures, la transaction peut acquérir des verrous de lecture sur l'existence de la ligne.
  • Au moment du commit, 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 du commit à l'aide de l'algorithme wound-wait. Tous les verrous sont conservés jusqu'à ce que la transaction soit validée.

Simultanéité pessimiste dans l'isolation de lecture répétée

Utilisez la simultanéité pessimiste dans l'isolation de lecture répétée pour sérialiser les écritures. Dans ce mode, les opérations de lecture utilisent des instantanés, mais des verrous exclusifs s'appliquent aux données lues à partir de requêtes FOR UPDATE ou d'indices lock_scanned_ranges=exclusive ainsi qu'aux données écrites avec des requêtes LMD.

Avantages de la simultanéité pessimiste avec l'isolation sérialisable

Le principal avantage de l'utilisation de la simultanéité pessimiste avec l'isolation sérialisable est que, dans les charges de travail très conflictuelles, elle permet aux transactions de progresser. Spanner donne la priorité aux transactions plus anciennes par rapport aux plus récentes en cas de conflit, ce qui garantit que les transactions finissent par se terminer tout en réduisant le nombre de transactions abandonnées de manière répétée.

Avantages de la simultanéité pessimiste avec l'isolation de lecture répétée

Avec l'isolation de lecture répétée, les transactions qui acquièrent des verrous peuvent toujours être abandonnées au moment du commit si les données lues dans le cadre d'une requête avec FOR UPDATE ou d'une requête LMD ont été modifiées par une transaction simultanée avant le commit de la transaction. Toutefois, une fois les verrous acquis, elle empêche d'autres mises à jour simultanées jusqu'à ce que la transaction soit validée, ce qui sérialise les écritures.

Risques liés à la simultanéité pessimiste

La simultanéité pessimiste avec l'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 utilisateur avant la fin 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 simultanéité pessimiste avec l'isolation sérialisable

La simultanéité pessimiste convient aux charges de travail avec une forte contention en lecture-écriture et en écriture-écriture. Elle est également appropriée lorsque les abandons et les nouvelles tentatives de transaction sont coûteux. Utilisez ce mode par défaut, sauf si votre charge de travail présente des retards de verrouillage excessifs ou si elle est fortement affectée par des conflits de verrouillage.

Cas d'utilisation de la simultanéité pessimiste avec l'isolation de lecture répétée

Utilisez la simultanéité pessimiste avec la lecture répétée pour les charges de travail qui nécessitent une clause FOR UPDATE ou des requêtes LMD pour acquérir des verrous. Cette approche est particulièrement utile pour les charges de travail migrées vers Spanner à partir d'autres bases de données qui acquièrent des verrous pour ces instructions.

Contrôle de simultanéité optimiste

Spanner fournit également un contrôle de simultanéité optimiste. Lorsque vous utilisez l'isolation de lecture répétée, 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 simultanéité optimiste.

Le contrôle de simultanéité optimiste suppose que les conflits sont rares. Les lectures et les requêtes, même au sein d'une transaction en lecture-écriture, se poursuivent 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 répétée, les lectures avec un indice FOR UPDATE ou lock_scanned_ranges=exclusive sont validées au moment du commit. 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. Elle effectue une exécution sans verrouillage pendant la phase de lecture et valide la cohérence au moment du commit.

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 ce code temporel lors de l'exécution de la première lecture ou requête. 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 que les conditions suivantes sont remplies :

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

Le niveau d'isolation détermine l'ensemble des lectures validées. Avec l'isolation sérialisable, toutes les lectures sont validées. Avec l'isolation de lecture répétée, 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 de manière répétée. En revanche, les transactions pessimistes résolvent les conflits de lecture-écriture en autorisant la validation de la transaction la plus ancienne et en relançant la transaction la plus récente.

Avantages de la simultanéité optimiste

La simultanéité 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. Par conséquent, les lectures de longue durée ne bloquent pas les écritures sensibles à la latence.
• Latence de commit 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 code temporel d'instantané, il n'est pas nécessaire de vérifier la cohérence lors de l'exécution ou du commit de ces lectures, ce qui réduit considérablement la latence.

Risques liés à la simultanéité optimiste

La simultanéité 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 simultanéité 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 abandonnée de manière répétée et ne jamais être validée en raison d'un manque de transactions.

Cas d'utilisation de la simultanéité optimiste

La simultanéité optimiste convient aux charges de travail transactionnelles avec une faible contention en lecture-écriture. Pour les transactions sérialisables, elle est également avantageuse pour les charges de travail qui peuvent tolérer les abandons de transactions.

Envisagez la simultanéité 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 simultanéité optimiste si les lectures ou requêtes de longue durée peuvent retarder les écritures sensibles à la latence. Cela évite les retards causés par les verrous de lecture. Par exemple, les transactions dans les clients mobiles avec des connexions lentes ou les transactions à faible contrat de niveau de service qui conservent 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 simultanéité 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 trafic de lecture irrégulier vers une division à chaud. Elle améliore également la disponibilité en lecture en cas de surcharge ou d'indisponibilité du responsable.
• Charges de travail transactionnelles où la plupart des transactions sont en lecture seule : le passage à la simultanéité optimiste réduit la latence de commit pour les transactions courantes en lecture seule dans ces charges de travail. Assurez-vous d'une faible contention en lecture-écriture 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 Spanner, REST et l'API RPC 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();
    }
}

C++

void ReadLockModeSetting(std::string const& project_id,
                         std::string const& instance_id,
                         std::string const& database_id) {
  namespace spanner = ::google::cloud::spanner;
  using ::google::cloud::Options;
  using ::google::cloud::StatusOr;

  auto db = spanner::Database(project_id, instance_id, database_id);

  // The read lock mode specified at the client-level will be applied
  // to all RW transactions.
  auto options = Options{}.set<spanner::TransactionReadLockModeOption>(
      spanner::Transaction::ReadLockMode::kOptimistic);
  auto client = spanner::Client(spanner::MakeConnection(db, options));

  auto commit = client.Commit(
      [&client](
          spanner::Transaction const& txn) -> StatusOr<spanner::Mutations> {
        // Read an AlbumTitle.
        auto sql = spanner::SqlStatement(
            "SELECT AlbumTitle from Albums WHERE SingerId = @SingerId and "
            "AlbumId = @AlbumId",
            {{"SingerId", spanner::Value(2)}, {"AlbumId", spanner::Value(1)}});
        auto rows = client.ExecuteQuery(txn, std::move(sql));
        for (auto const& row :
             spanner::StreamOf<std::tuple<std::string>>(rows)) {
          if (!row) return row.status();
          std::cout << "Current Album Title: " << std::get<0>(*row) << "\n";
        }

        // Update the title.
        auto update_sql = spanner::SqlStatement(
            "UPDATE Albums "
            "SET AlbumTitle = @AlbumTitle "
            "WHERE SingerId = @SingerId and AlbumId = @AlbumId",
            {{"AlbumTitle", spanner::Value("A New Title")},
             {"SingerId", spanner::Value(2)},
             {"AlbumId", spanner::Value(1)}});
        auto result = client.ExecuteDml(txn, std::move(update_sql));
        if (!result) return result.status();
        std::cout << result->RowsModified() << " record(s) updated.\n";

        return spanner::Mutations{};
      },
      // The read lock mode specified at the transaction-level takes
      // precedence over the read lock mode configured at the client-level.
      // kPessimistic is used here to demonstrate overriding the client-level
      // setting.
      Options{}.set<spanner::TransactionReadLockModeOption>(
          spanner::Transaction::ReadLockMode::kPessimistic));

  if (!commit) throw std::move(commit).status();
  std::cout << "Update was successful [spanner_read_lock_mode]\n";
}

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 de 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 la présentation des pilotes.

Étape suivante

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