Prácticas recomendadas para el lenguaje de manipulación de datos

En esta página, se describen las prácticas recomendadas para usar el lenguaje de manipulación de datos (DML) y el DML particionado para bases de datos con dialecto de GoogleSQL y bases de datos con dialecto de PostgreSQL.

Usa una cláusula WHERE para reducir el alcance de los bloqueos

Las declaraciones DML se pueden ejecutar dentro de transacciones de lectura y escritura. Cuando Spanner lee datos, adquiere bloqueos de lectura compartidos en partes limitadas de los rangos de fila que lees. En particular, adquiere estos bloqueos solo en las columnas a las que accedes. Los bloqueos pueden incluir datos que no satisfagan la condición del filtro de la cláusula WHERE.

Cuando Spanner modifica los datos con instrucciones DML, adquiere bloqueos exclusivos en los datos específicos que estás modificando. Además, adquiere bloqueos compartidos de la misma manera que cuando lees datos. Si tu solicitud incluye grandes rangos de filas o una tabla completa, es posible que los bloqueos compartidos impidan que otras transacciones avancen en paralelo.

Para modificar los datos de la manera más eficiente posible, usa una cláusula WHERE que permita a Spanner leer solo las filas necesarias. Puedes lograr este objetivo con un filtro en la clave primaria o en la clave de un índice secundario. La cláusula WHERE limita el alcance de los bloqueos compartidos y permite que Spanner procese la actualización de manera más eficiente.

Por ejemplo, supongamos que uno de los músicos de la tabla Singers cambia su nombre y tienes que actualizarlo en tu base de datos. Puedes ejecutar la siguiente declaración DML, pero eso obliga a Spanner a analizar toda la tabla y a adquirir bloqueos compartidos que cubran la tabla completa. Como resultado, Spanner debe leer más datos de los necesarios, y las transacciones simultáneas no pueden modificar los datos en paralelo: 

-- ANTI-PATTERN: SENDING AN UPDATE WITHOUT THE PRIMARY KEY COLUMN
-- IN THE WHERE CLAUSE

UPDATE Singers SET FirstName = "Marcel"
WHERE FirstName = "Marc" AND LastName = "Richards";

Para que la actualización sea más eficiente, incluye la columna SingerId en la cláusula WHERE. La columna SingerId es la única columna de clave primaria de la tabla Singers: 

-- ANTI-PATTERN: SENDING AN UPDATE THAT MUST SCAN THE ENTIRE TABLE

UPDATE Singers SET FirstName = "Marcel"
WHERE FirstName = "Marc" AND LastName = "Richards"

Si no hay un índice en FirstName o LastName, debes analizar toda la tabla para encontrar los cantantes objetivo. Si no deseas agregar un índice secundario para que la actualización sea más eficiente, incluye la columna SingerId en la cláusula WHERE.

La columna SingerId es la única columna de clave primaria de la tabla Singers. Para encontrarlo, ejecuta SELECT en una transacción independiente de solo lectura antes de la transacción de actualización: 


  SELECT SingerId
  FROM Singers
  WHERE FirstName = "Marc" AND LastName = "Richards"

  -- Recommended: Including a seekable filter in the where clause

  UPDATE Singers SET FirstName = "Marcel"
  WHERE SingerId = 1;

Evita usar declaraciones de DML y mutaciones en la misma transacción

Spanner almacena en búfer las inserciones, actualizaciones y eliminaciones que se realizaron con instrucciones DML del lado del servidor, y los resultados son visibles para las instrucciones de SQL y las declaraciones de DML posteriores dentro de la misma transacción. Este comportamiento es diferente al de la API de Mutation, en la que Spanner almacena en búfer las mutaciones del lado del cliente y las envía del lado del servidor como parte de la operación de confirmación. Como resultado, las mutaciones de la solicitud de confirmación no son visibles para las instrucciones de SQL o declaraciones de DML dentro de la misma transacción.

Evita usar declaraciones de DML y mutaciones en la misma transacción. Si usas ambos en la misma transacción, debes tener en cuenta el orden de ejecución en el código de tu biblioteca cliente. Si una transacción contiene mutaciones y declaraciones DML en la misma solicitud, Spanner ejecuta las declaraciones DML antes de las mutaciones.

En el caso de las operaciones que solo se admiten con mutaciones, es posible que desees combinar declaraciones DML y mutaciones en la misma transacción, por ejemplo, insert_or_update.

Si usas ambas opciones, almacena las escrituras en búfer solo al final de la transacción.

Usa la función PENDING_COMMIT_TIMESTAMP para escribir marcas de tiempo de confirmación

GoogleSQL

Usa la función PENDING_COMMIT_TIMESTAMP para escribir la marca de tiempo de confirmación en una declaración DML. Spanner selecciona la marca de tiempo de confirmación cuando se confirma la transacción.

PostgreSQL

Usa la función SPANNER.PENDING_COMMIT_TIMESTAMP() para escribir la marca de tiempo de confirmación en una declaración DML. Spanner selecciona la marca de tiempo de confirmación cuando se confirma la transacción.

DML particionado y funciones de fecha y marca de tiempo

El DML particionado usa una o más transacciones que pueden ejecutarse y confirmarse en momentos diferentes. Si usas las funciones de fecha o marca de tiempo, las filas modificadas pueden contener valores diferentes.

Mejora la latencia con DML por lotes

Para reducir la latencia, usa DML por lotes para enviar varias instrucciones DML a Spanner en un solo viaje de ida y vuelta entre el cliente y el servidor.

El DML por lotes puede aplicar optimizaciones a grupos de sentencias dentro de un lote para permitir actualizaciones de datos más rápidas y eficientes.

  • Ejecuta escrituras con una sola solicitud

    Spanner optimiza automáticamente los grupos contiguos de instrucciones INSERT, UPDATE o DELETE por lotes similares que tienen diferentes valores de parámetros, si no incumplen las dependencias de datos.

    Por ejemplo, considera una situación en la que deseas insertar un conjunto grande de filas nuevas en una tabla llamada Albums. Para permitir que Spanner optimice todas las instrucciones INSERT necesarias en una sola acción eficiente del servidor, comienza por escribir una declaración DML adecuada que use parámetros de consulta en SQL:

    INSERT INTO Albums (SingerId, AlbumId, AlbumTitle) VALUES (@Singer, @Album, @Title);

    Luego, envía a Spanner un lote de DML que invoque esta instrucción de forma repetida y contigua, con las repeticiones que solo difieren en los valores que vinculas a los tres parámetros de consulta de la instrucción. Spanner optimiza estas instrucciones DML estructuralmente idénticas en una sola operación del servidor antes de ejecutarla.

  • Ejecuta escrituras en paralelo

    Spanner optimiza automáticamente los grupos contiguos de instrucciones DML ejecutándolos en paralelo cuando esto no infringe las dependencias de datos. Esta optimización brinda beneficios de rendimiento a un conjunto más amplio de declaraciones DML por lotes, ya que se puede aplicar a una combinación de tipos de declaración DML (INSERT, UPDATE y DELETE) y a declaraciones DML con o sin parámetros.

    Por ejemplo, nuestro esquema de muestra tiene las tablas Singers, Albums y Accounts. Albums se intercala dentro de Singers y almacena información sobre los álbumes de Singers. El siguiente grupo contiguo de instrucciones escribe filas nuevas en varias tablas y no tiene dependencias de datos complejas.

    INSERT INTO Singers (SingerId, Name) VALUES(1, "John Doe");
INSERT INTO Singers (SingerId, Name) VALUES(2, "Marcel Richards");
INSERT INTO Albums(SingerId, AlbumId, AlbumTitle) VALUES (1, 10001, "Album 1");
INSERT INTO Albums(SingerId, AlbumId, AlbumTitle) VALUES (1, 10002, "Album 2");
INSERT INTO Albums(SingerId, AlbumId, AlbumTitle) VALUES (2, 10001, "Album 1");
UPDATE Accounts SET Balance = 100 WHERE AccountId = @AccountId;

    Spanner optimiza este grupo de instrucciones DML ejecutándolas en paralelo. Las escrituras se aplican en el orden de las instrucciones del lote y mantienen la semántica de DML por lotes si una instrucción falla durante la ejecución.

Habilita el procesamiento por lotes del cliente en JDBC

En el caso de las aplicaciones de Java que usan un controlador JDBC compatible con Spanner, puedes reducir la latencia si habilitas el procesamiento por lotes de DML del cliente. El controlador JDBC tiene una propiedad de conexión llamada auto_batch_dml que, cuando está habilitada, almacena en búfer las instrucciones DML en el cliente y las envía a Spanner como un solo lote. Esto puede reducir la cantidad de viajes de ida y vuelta al servidor y mejorar el rendimiento general.

De forma predeterminada, auto_batch_dml se configura como false. Para habilitarlo, configúralo como true en tu cadena de conexión JDBC.

Por ejemplo:

String url = "jdbc:cloudspanner:/projects/my-project/instances/my-instance/databases/my-database;auto_batch_dml=true";
try (Connection connection = DriverManager.getConnection(url)) {
    // Include your DML statements for batching here
}

Con esta propiedad de conexión habilitada, Spanner envía las instrucciones DML almacenadas en búfer como un lote cuando se ejecuta una instrucción que no es DML o cuando se confirma la transacción actual. Esta propiedad solo se aplica a las transacciones de lectura y escritura. Las instrucciones DML en modo de confirmación automática se ejecutan directamente.

De forma predeterminada, el recuento de actualizaciones para las instrucciones DML almacenadas en búfer se establece en 1. Puedes cambiar esto si configuras la variable de conexión auto_batch_dml_update_count con un valor diferente. Para obtener más información, consulta Propiedades de conexión compatibles con JDBC.