Spanner fornisce statistiche di blocco che ti consentono di identificare la chiave di riga e le colonne della tabella che sono state le origini principali dei conflitti di blocco delle transazioni nel database durante un determinato periodo di tempo. Puoi recuperare queste statistiche dalle tabelle di sistema SPANNER_SYS.LOCK_STATS*
utilizzando le istruzioni SQL.
Disponibilità
I dati di SPANNER_SYS
sono disponibili solo tramite le interfacce SQL, ad esempio:
Pagina Spanner Studio di un database nella console Google Cloud
Il comando
gcloud spanner databases execute-sql
La dashboard Approfondimenti sui blocchi
API
executeQuery
Altri metodi di lettura singoli forniti da Spanner non supportano SPANNER_SYS
.
Bloccare le statistiche per chiave di riga
Le seguenti tabelle monitorano la chiave di riga con il tempo di attesa più alto:
SPANNER_SYS.LOCK_STATS_TOP_MINUTE
: chiavi di riga con il maggior numero di tempi di attesa per il blocco durante intervalli di 1 minuto.SPANNER_SYS.LOCK_STATS_TOP_10MINUTE
: chiavi di riga con il maggior numero di tempi di attesa per il blocco durante intervalli di 10 minuti.SPANNER_SYS.LOCK_STATS_TOP_HOUR
: chiavi di riga con i tempi di attesa per il blocco più alti a intervalli di 1 ora
Queste tabelle hanno le seguenti proprietà:
Ogni tabella contiene dati per intervalli di tempo non sovrapposti della lunghezza specificata dal nome della tabella.
Gli intervalli sono basati sugli orari dell'orologio. Gli intervalli di 1 minuto terminano al minuto, gli intervalli di 10 minuti terminano ogni 10 minuti a partire dall'ora e gli intervalli di 1 ora terminano ogni ora. Dopo ogni intervallo, Spanner raccoglie i dati da tutti i server e li rende disponibili nelle tabelle SPANNER_SYS poco dopo.
Ad esempio, alle 11:59:30, gli intervalli più recenti disponibili per le query SQL sono:
- 1 minuto: 11:58:00-11:58:59
- 10 minuti: 11:40:00-11:49:59
- 1 ora: 10:00:00–10:59:59
Spanner raggruppa le statistiche iniziando l'intervallo di chiave di riga.
Ogni riga contiene le statistiche per il tempo di attesa totale del blocco di un determinato intervallo di chiave di riga iniziale per cui Spanner acquisisce le statistiche durante l'intervallo specificato.
Se Spanner non è in grado di archiviare le informazioni su ogni intervallo di chiave di riga per i tempi di attesa del blocco durante l'intervallo, il sistema assegna la priorità all'intervallo di chiave di riga con il tempo di attesa per il blocco più alto durante l'intervallo specificato.
Tutte le colonne delle tabelle sono nulli.
Schema tabella
Nome colonna | Tipo | Descrizione |
---|---|---|
INTERVAL_END |
TIMESTAMP |
Fine dell'intervallo di tempo in cui si sono verificati conflitti nei blocchi inclusi. |
ROW_RANGE_START_KEY |
BYTES(MAX) |
La chiave di riga in cui si è verificato il conflitto di blocco. Quando il conflitto riguarda un intervallo di righe, questo valore rappresenta la chiave iniziale di quell'intervallo. Un segno più, + , indica un intervallo.
Per maggiori informazioni,
consulta la sezione Che cos'è una chiave iniziale di un intervallo di righe.
|
LOCK_WAIT_SECONDS |
FLOAT64 |
Il tempo di attesa cumulativo del blocco dei conflitti di blocco registrati per tutte le colonne nell'intervallo di chiave di riga, in secondi. |
SAMPLE_LOCK_REQUESTS |
ARRAY<STRUCT<
|
Ogni voce in questo array corrisponde a una richiesta di blocco di esempio che ha contribuito al conflitto di blocco attendendo un blocco o bloccando l'acquisizione del blocco da parte di altre transazioni per la chiave di riga specificata (intervallo). Il numero massimo di campioni in questo array è 20.
Ogni esempio contiene i seguenti tre campi:
|
Modalità di blocco
Le operazioni Spanner acquisiscono blocchi quando le operazioni fanno parte di una transazione di lettura-scrittura. Le transazioni di sola lettura non acquisiscono blocchi. Spanner utilizza diverse modalità di blocco per massimizzare il numero di transazioni che hanno accesso a una determinata cella di dati in un determinato momento. Serrature diverse hanno caratteristiche diverse. Ad esempio, alcuni blocchi possono essere condivisi tra più transazioni, mentre altri no.
Un conflitto di blocco può verificarsi quando tenti di acquisire una delle seguenti modalità di blocco in una transazione.
Blocco
ReaderShared
- Un blocco che consente ad altre operazioni di lettura di accedere ai dati fino a quando la transazione non è pronta per il commit. Questo blocco condiviso viene acquisito quando una transazione di lettura/scrittura legge i dati.Blocco
WriterShared
: questo blocco viene acquisito quando una transazione di lettura/scrittura tenta di eseguire il commit di una scrittura.Exclusive
Blocco: viene acquisito un blocco esclusivo quando una transazione di lettura/scrittura, che ha già acquisito un blocco ReaderShared, tenta di scrivere dati al termine della lettura. Un blocco esclusivo è un upgrade di un bloccoReaderShared
. Un blocco esclusivo è un caso speciale di una transazione che include contemporaneamente il bloccoReaderShared
e il bloccoWriterShared
. Nessun'altra transazione può acquisire blocchi sulla stessa cella.Blocco
WriterSharedTimestamp
: un tipo speciale di bloccoWriterShared
che viene acquisito quando si inseriscono nuove righe in una tabella contenente un timestamp di commit come parte della chiave primaria. Questo tipo di blocco impedisce ai partecipanti alla transazione di creare esattamente la stessa riga e, di conseguenza, di entrare in conflitto tra loro. Spanner aggiorna la chiave della riga inserita in modo che corrisponda al timestamp di commit della transazione che ha eseguito l'inserimento.
Per ulteriori informazioni sui tipi di transazioni e sui tipi di blocchi disponibili, consulta Transazioni.
Conflitti della modalità di blocco
La tabella seguente mostra i possibili conflitti tra le diverse modalità di blocco.
Modalità di blocco | ReaderShared |
WriterShared |
Exclusive |
WriterSharedTimestamp |
---|---|---|---|---|
ReaderShared |
No | Sì | Yes | Yes |
WriterShared |
Sì | No | Sì | Non applicabile |
Exclusive |
Sì | Yes | Sì | Non applicabile |
WriterSharedTimestamp |
Sì | Non applicabile | Non applicabile | Sì |
I blocchi WriterSharedTimestamp
vengono utilizzati solo quando inserisci nuove righe con un timestamp nella chiave primaria. I blocchi WriterShared
e Exclusive
vengono
utilizzati per la scrittura nelle celle esistenti o per l'inserimento di nuove righe senza timestamp. Di conseguenza, WriterSharedTimestamp
non può essere in conflitto con altri tipi di blocchi e
questi scenari sono indicati come Non applicabile nella tabella precedente.
L'unica eccezione è ReaderShared
, che può essere applicata a righe non esistenti
e, di conseguenza, potrebbe essere in conflitto con WriterSharedTimestamp
. Ad
esempio, una scansione completa della tabella blocca l'intera tabella anche per le righe che non sono state
create, pertanto è possibile che ReaderShared
entri in conflitto con
WriterSharedTimestamp
.
Che cos'è una chiave iniziale di un intervallo di righe?
La colonna ROW_RANGE_START_KEY
identifica la chiave primaria composita, ovvero la chiave primaria iniziale di un intervallo di righe, che presenta conflitti di blocco. Per illustrare un esempio, viene
utilizzato il seguente schema.
CREATE TABLE Singers (
SingerId INT64 NOT NULL,
FirstName STRING(1024),
LastName STRING(1024),
SingerInfo BYTES(MAX),
) PRIMARY KEY (SingerId);
CREATE TABLE Albums (
SingerId INT64 NOT NULL,
AlbumId INT64 NOT NULL,
AlbumTitle STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId),
INTERLEAVE IN PARENT Singers ON DELETE CASCADE;
CREATE TABLE Songs (
SingerId INT64 NOT NULL,
AlbumId INT64 NOT NULL,
TrackId INT64 NOT NULL,
SongName STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId, TrackId),
INTERLEAVE IN PARENT Albums ON DELETE CASCADE;
CREATE TABLE Users (
UserId INT64 NOT NULL,
LastAccess TIMESTAMP NOT NULL OPTIONS (allow_commit_timestamp=true),
...
) PRIMARY KEY (UserId, LastAccess);
Come mostra la seguente tabella di intervalli di chiave di riga e di chiave di riga, un intervallo è rappresentato dal segno più "+", nella chiave. In questi casi, la chiave rappresenta la chiave iniziale di un intervallo di chiavi in cui si è verificato un conflitto di blocco.
ROW_RANGE_START_KEY | Spiegazione |
---|---|
cantanti(2) | Tavolo dei cantanti alla chiave SingerId=2 |
album(2,1) | Tabella album nella chiave SingerId=2,AlbumId=1 |
brani(2,1,5) | Tabella dei brani al tasto SingerId=2,AlbumId=1,TrackId=5 |
brani(2,1,5+) | Intervallo tasti della tabella dei brani che inizia da SingerId=2,AlbumId=1,TrackId=5 |
album(2,1+) | Intervallo chiavi della tabella album che inizia da SingerId=2,AlbumId=1 |
utenti(3, 2020-11-01 12:34:56.426426+00:00) | Tabella degli utenti nella chiave UserId=3, LastAccess=commit_timestamp |
Statistiche aggregate
SPANNER_SYS
contiene anche tabelle per archiviare i dati aggregati per le statistiche di blocco acquisite da Spanner in un periodo di tempo specifico:
SPANNER_SYS.LOCK_STATS_TOTAL_MINUTE
: statistiche aggregate per tutte le serrature in attesa durante intervalli di 1 minuto.SPANNER_SYS.LOCK_STATS_TOTAL_10MINUTE
: statistiche aggregate per tutte le serrature in attesa durante intervalli di 10 minuti.SPANNER_SYS.LOCK_STATS_TOTAL_HOUR
: statistiche aggregate per tutti i tempi di attesa della serratura a intervalli di 1 ora.
Le tabelle delle statistiche aggregate hanno le seguenti proprietà:
Ogni tabella contiene dati per intervalli di tempo non sovrapposti della lunghezza specificata dal nome della tabella.
Gli intervalli sono basati sugli orari dell'orologio. Gli intervalli di 1 minuto terminano al minuto, gli intervalli di 10 minuti terminano ogni 10 minuti a partire dall'ora e gli intervalli di 1 ora terminano ogni ora.
Ad esempio, alle 11:59:30, gli intervalli più recenti disponibili per le query SQL sulle statistiche di blocco aggregate sono:
- 1 minuto: 11:58:00-11:58:59
- 10 minuti: 11:40:00-11:49:59
- 1 ora: 10:00:00–10:59:59
Ogni riga contiene statistiche per tutti i tempi di attesa del blocco sul database durante l'intervallo specificato, aggregati insieme. C'è una sola riga per intervallo di tempo.
Le statistiche acquisite nelle tabelle
SPANNER_SYS.LOCK_STATS_TOTAL_*
includono i tempi di attesa di blocco che Spanner non ha acquisito nelle tabelleSPANNER_SYS.LOCK_STATS_TOP_*
.Alcune colonne di queste tabelle sono esposte come metriche in Cloud Monitoring. Le metriche esposte sono:
- Tempo di attesa per il blocco
Per ulteriori informazioni, consulta Metriche di Spanner.
Schema tabella
Nome colonna | Tipo | Descrizione |
---|---|---|
INTERVAL_END |
TIMESTAMP |
Fine dell'intervallo di tempo in cui si è verificato il conflitto di blocco. |
TOTAL_LOCK_WAIT_SECONDS |
FLOAT64 |
Tempo totale di attesa del blocco per i conflitti di blocco registrati per l'intero database, in secondi. |
Esempi di query
Di seguito è riportato un esempio di istruzione SQL che puoi utilizzare per recuperare le statistiche di blocco. Puoi eseguire queste istruzioni SQL utilizzando le librerie client, gcloud spanner o la console Google Cloud.
Elenca le statistiche di blocco per l'intervallo di 1 minuto precedente
La seguente query restituisce le informazioni sull'attesa del blocco per ogni chiave di riga con un conflitto di blocco, inclusa la frazione dei conflitti totali del blocco, durante l'intervallo di tempo più recente di 1 minuto.
La funzione CAST()
converte il campo row_range_start_key BYTES
in una STRINGA.
SELECT CAST(s.row_range_start_key AS STRING) AS row_range_start_key,
t.total_lock_wait_seconds,
s.lock_wait_seconds,
s.lock_wait_seconds/t.total_lock_wait_seconds frac_of_total,
s.sample_lock_requests
FROM spanner_sys.lock_stats_total_minute t, spanner_sys.lock_stats_top_minute s
WHERE t.interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.lock_stats_total_minute)
AND s.interval_end = t.interval_end
ORDER BY s.lock_wait_seconds DESC;
Output query
row_range_start_key | total_lock_wait_seconds | lock_wait_seconds | frac_of_total | sample_lock_requests |
---|---|---|---|---|
Brani(2; 1; 1) | 2,37 | 1,76 | 0,7426 | LOCK_MODE: Condivisione con Reader COLONNA: Cantanti.SingerInfo LOCK_MODE: WriterShared COLONNA: Cantanti.SingerInfo |
Utenti(3, 2020-11-01 12:34:56.426426+00:00) | 2,37 | 0,61 | 0,2573 | LOCK_MODE: Condivisione con Reader COLONNA: users._exists1 LOCK_MODE: WriterShared COLONNA: users._exists1 |
1 _exists
è un campo interno utilizzato per verificare se una determinata riga esiste o meno.
Conservazione dei dati
Spanner conserva i dati di ogni tabella come minimo per i seguenti periodi di tempo:
SPANNER_SYS.LOCK_STATS_TOP_MINUTE
eSPANNER_SYS.LOCK_STATS_TOTAL_MINUTE
: intervalli che coprono le 6 ore precedenti.SPANNER_SYS.LOCK_STATS_TOP_10MINUTE
eSPANNER_SYS.LOCK_STATS_TOTAL_10MINUTE
: intervalli che coprono i 4 giorni precedenti.SPANNER_SYS.LOCK_STATS_TOP_HOUR
eSPANNER_SYS.LOCK_STATS_TOTAL_HOUR
: intervalli che coprono i 30 giorni precedenti.
Risolvere i conflitti dei blocchi nel database utilizzando le statistiche sui blocchi
Puoi utilizzare SQL o la dashboard Blocca insight per visualizzare i conflitti dei blocchi nel database.
I seguenti argomenti mostrano come esaminare questi conflitti di blocchi utilizzando il codice SQL.
Seleziona un periodo di tempo per l'indagine
Esaminerai le metriche di latenza per il tuo database Spanner e scopri un periodo di tempo in cui la tua app riscontra un'elevata latenza e un utilizzo della CPU elevata. Ad esempio, il problema ha iniziato a verificarsi intorno alle 22:50 del 12 novembre 2020.
Determina se la latenza di commit della transazione è aumentata insieme al tempo di attesa del blocco durante il periodo selezionato
I blocchi vengono acquisiti dalle transazioni. Pertanto, se i conflitti di blocco causano lunghi tempi di attesa, dovremmo essere in grado di vedere l'aumento della latenza di commit delle transazioni insieme all'aumento del tempo di attesa per il blocco.
Dopo aver selezionato un periodo di tempo per iniziare la nostra indagine, uniremo le
statistiche sulle transazioni TXN_STATS_TOTAL_10MINUTE
alle statistiche di blocco LOCK_STATS_TOTAL_10MINUTE
per quel periodo per aiutarci
a capire se l'aumento della latenza media di commit è contribuito all'aumento del tempo di attesa del blocco.
SELECT t.interval_end, t.avg_commit_latency_seconds, l.total_lock_wait_seconds
FROM spanner_sys.txn_stats_total_10minute t
LEFT JOIN spanner_sys.lock_stats_total_10minute l
ON t.interval_end = l.interval_end
WHERE
t.interval_end >= "2020-11-12T21:50:00Z"
AND t.interval_end <= "2020-11-12T23:50:00Z"
ORDER BY interval_end;
Prendi i seguenti dati come esempio dei risultati che otteniamo dalla nostra query.
interval_end | avg_commit_latency_seconds | total_lock_wait_seconds |
---|---|---|
2020-11-12 21:40:00-07:00 | 0,002 | 0,090 |
2020-11-12 21:50:00-07:00 | 0,003 | 0,110 |
12-11-2020 22:00:00-07:00 | 0,002 | 0,100 |
2020-11-12 22:10:00-07:00 | 0,002 | 0,080 |
12-11-2020 22:20:00-07:00 | 0,030 | 0,240 |
2020-11-12 22:30:00-07:00 | 0,034 | 0,220 |
2020-11-12 22:40:00-07:00 | 0,034 | 0,218 |
12-11-2020 22:50:00-07:00 | 3,741 | 780,193 |
12-11-2020 23:00:00-07:00 | 0,042 | 0,240 |
2020-11-12 23:10:00-07:00 | 0,038 | 0,129 |
2020-11-12 23:20:00-07:00 | 0,021 | 0,128 |
2020-11-12 23:30:00-07:00 | 0,038 | 0,231 |
I risultati precedenti mostrano un aumento significativo dei valori avg_commit_latency_seconds
e total_lock_wait_seconds
nello stesso periodo di tempo:
dal 12-11-2020
22:40:00 alle 22:50:00 del 12-11-2020, per poi diminuire. Una cosa da notare è che avg_commit_latency_seconds
è il tempo medio impiegato solo per il passaggio di commit. Al contrario, total_lock_wait_seconds
è il tempo di blocco aggregato per il periodo, quindi sembra molto più lungo di quello di commit della transazione.
Ora che abbiamo confermato che il tempo di attesa del blocco è strettamente correlato all'aumento della latenza di scrittura, nel passaggio successivo analizzeremo quali righe e colonne causano l'attesa lunga.
Scopri quali chiavi di riga e colonne hanno avuto lunghi tempi di attesa per il blocco durante il periodo selezionato
Per scoprire quali chiavi di riga e colonne hanno riscontrato i tempi di attesa per il blocco elevati
durante il periodo in cui stiamo esaminando, eseguiamo una query sulla tabella LOCK_STAT_TOP_10MINUTE
, che elenca le chiavi di riga e le colonne che contribuiscono maggiormente all'attesa
del blocco.
La funzione CAST()
nella seguente query converte il campo
row_range_start_key BYTES in una STRING.
SELECT CAST(s.row_range_start_key AS STRING) AS row_range_start_key,
t.total_lock_wait_seconds,
s.lock_wait_seconds,
s.lock_wait_seconds/t.total_lock_wait_seconds frac_of_total,
s.sample_lock_requests
FROM spanner_sys.lock_stats_total_10minute t, spanner_sys.lock_stats_top_10minute s
WHERE
t.interval_end = "2020-11-12T22:50:00Z" and s.interval_end = t.interval_end;
row_range_start_key | total_lock_wait_seconds | lock_wait_seconds | frac_of_total | sample_lock_requests |
---|---|---|---|---|
Cantanti(32) | 780,193 | 780,193 | 1 | LOCK_MODE: WriterShared COLONNA: Cantanti.SingerInfo LOCK_MODE: Condivisione con Reader COLONNA: Cantanti.SingerInfo |
Da questa tabella dei risultati, è possibile vedere che il conflitto si è verificato nella tabella Singers
nella chiave SingerId=32. Singers.SingerInfo
è la colonna in cui si è verificato il
conflitto di blocco tra ReaderShared
e WriterShared
.
Si tratta di un tipo comune di conflitto quando una transazione tenta di leggere una determinata cella e l'altra transazione tenta di scrivere nella stessa cella. Ora conosciamo l'esatta cella di dati per cui le transazioni si contendono il blocco, quindi nel passaggio successivo identificheremo le transazioni che concorrono per i blocchi.
Trovare le transazioni che accedono alle colonne coinvolte nel conflitto di blocco
Per identificare le transazioni con una latenza di commit significativa
in un intervallo di tempo specifico a causa di conflitti di blocco, devi eseguire una query
per le seguenti colonne dalla tabella
SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE
:
fprint
read_columns
write_constructive_columns
avg_commit_latency_seconds
Devi filtrare in base alle colonne bloccate identificate dalla tabella SPANNER_SYS.LOCK_STATS_TOP_10MINUTE
:
Transazioni che leggono le colonne in cui si è verificato un conflitto di blocco durante il tentativo di acquisire il blocco
ReaderShared
.Transazioni che scrivono in qualsiasi colonna in cui si è verificato un conflitto di blocco durante il tentativo di acquisire un blocco
WriterShared
.
SELECT
fprint,
read_columns,
write_constructive_columns,
avg_commit_latency_seconds
FROM spanner_sys.txn_stats_top_10minute t2
WHERE (
EXISTS (
SELECT * FROM t2.read_columns columns WHERE columns IN (
SELECT DISTINCT(req.COLUMN)
FROM spanner_sys.lock_stats_top_10minute t, t.SAMPLE_LOCK_REQUESTS req
WHERE req.LOCK_MODE = "ReaderShared" AND t.interval_end ="2020-11-12T23:50:00Z"))
OR
EXISTS (
SELECT * FROM t2.write_constructive_columns columns WHERE columns IN (
SELECT DISTINCT(req.COLUMN)
FROM spanner_sys.lock_stats_top_10minute t, t.SAMPLE_LOCK_REQUESTS req
WHERE req.LOCK_MODE = "WriterShared" AND t.interval_end ="2020-11-12T23:50:00Z"))
)
AND t2.interval_end ="2020-11-12T23:50:00Z"
ORDER BY avg_commit_latency_seconds DESC;
Il risultato della query viene ordinato in base alla colonna avg_commit_latency_seconds
, in modo che la transazione con la latenza di commit più elevata.
Fprint | read_columns | write_constructive_columns | avg_commit_latency_seconds |
---|---|---|---|
1866043996151916800 |
['Singers.SingerInfo', 'Singers.FirstName', 'Singers.LastName', 'Singers._exists'] |
['Cantanti.InfoSinger'] | 4,89 |
4168578515815911936 | [] | ['Cantanti.InfoSinger'] | 3,65 |
I risultati della query mostrano che due transazioni hanno tentato di accedere alla colonna Singers.SingerInfo
, ovvero la colonna con conflitti di blocco durante il periodo di tempo.
Dopo aver identificato le transazioni che causano i conflitti di blocco, puoi analizzarle utilizzando la relativa impronta, fprint
, per identificare i potenziali problemi che hanno contribuito a tale conflitto.
Dopo aver esaminato la transazione con fprint=1866043996151916800, puoi utilizzare le colonne read_columns
e write_constructive_columns
per identificare quale parte del codice dell'applicazione ha attivato la transazione. Puoi quindi visualizzare il
DML sottostante che non filtra in base alla chiave primaria, SingerId
. Questo ha causato una scansione completa della tabella e la è bloccata fino al commit della transazione.
Per risolvere il conflitto di blocchi, puoi procedere come segue:
- Utilizza una transazione di sola lettura per identificare i valori
SingerId
obbligatori. - Utilizza una transazione di lettura e scrittura separata per aggiornare le righe dei valori
SingerId
richiesti.
Applica le best practice per ridurre il conflitto di blocchi
Nel nostro scenario di esempio, siamo stati in grado di utilizzare le statistiche di blocco e le statistiche sulle transazioni per restringere il problema a una transazione che non utilizzava la chiave primaria della tabella durante l'aggiornamento. Abbiamo elaborato delle idee per migliorare la transazione a seconda che conoscessimo o meno le chiavi delle righe che volevamo aggiornare in anticipo.
Quando esamini potenziali problemi nella tua soluzione o anche quando progetti la tua soluzione, considera queste best practice per ridurre il numero di conflitti di blocchi nel database.
Evita letture di grandi dimensioni all'interno di transazioni di lettura-scrittura.
Se possibile, utilizza transazioni di sola lettura, perché non acquisiscono alcun blocco.
Evita scansioni complete delle tabelle in una transazione di lettura-scrittura. Ciò include la scrittura di un condizionale DML sulla chiave primaria o l'assegnazione di un intervallo di chiavi specifico quando si utilizza l'API Read.
Mantieni breve il periodo di blocco eseguendo il commit della modifica il prima possibile dopo aver letto i dati in una transazione di lettura-scrittura. Una transazione di lettura/scrittura garantisce che i dati rimangano invariati dopo la lettura dei dati fino a quando non esegui il commit della modifica. A questo scopo, la transazione richiede il blocco delle celle di dati durante la lettura e il commit. Di conseguenza, se riesci a prolungare il periodo di blocco di breve durata, è meno probabile che si verifichino conflitti di blocco delle transazioni.
Preferisci le transazioni di piccola entità rispetto a quelle di grandi dimensioni oppure prendi in considerazione la DML partizionata per le transazioni DML a lunga esecuzione. Una transazione a lunga esecuzione acquisisce un blocco per un lungo periodo di tempo, quindi valuta la possibilità di suddividere una transazione che tocca migliaia di righe in più transazioni più piccole che aggiornano centinaia di righe quando possibile.
Se non ti serve la garanzia fornita da una transazione di lettura-scrittura, evita di leggere i dati della transazione di lettura/scrittura prima di eseguire il commit della modifica, ad esempio leggendo i dati in una transazione di sola lettura separata. La maggior parte dei conflitti di blocco si verifica a causa della forte garanzia, per garantire che i dati rimangano invariati tra la lettura e il commit. Quindi, se la transazione di lettura/scrittura non legge nessun dato, non ha bisogno di bloccare le celle per molto tempo.
Specifica solo l'insieme minimo di colonne richieste in una transazione di lettura/scrittura. Poiché i blocchi di Spanner sono per cella di dati, quando una transazione di lettura/scrittura legge un numero eccessivo di colonne, acquisisce un blocco
ReaderShared
su queste celle. Ciò potrebbe causare conflitti di blocco quando altre transazioni acquisiscono un bloccoWriterShared
nelle scritture in un numero eccessivo di colonne. Ad esempio, valuta la possibilità di specificare un insieme di colonne anziché*
in lettura.Riduci al minimo le chiamate API in una transazione di lettura/scrittura. La latenza delle chiamate API potrebbe portare a conflitti di blocco in Spanner, poiché le chiamate API sono soggette a ritardi di rete e ritardi lato servizio. Ti consigliamo di effettuare chiamate API al di fuori delle transazioni di lettura/scrittura, quando possibile. Se devi eseguire chiamate API all'interno di una transazione di lettura/scrittura, assicurati di monitorare la latenza delle chiamate API per ridurre al minimo l'impatto sul periodo di acquisizione del blocco.
Passaggi successivi
- Scopri di più sugli altri strumenti di introspezione.
- Scopri di più sulle altre informazioni archiviate da Spanner per ogni database nella tabella schema delle informazioni dei database.
- Scopri di più sulle best practice SQL per Spanner.