Spanner fornisce il tipo NUMERIC
che può memorizzare esattamente i numeri con precisione decimale.
La semantica del tipo NUMERIC
in Spanner varia in base ai due dialetti SQL (GoogleSQL e PostgreSQL), in particolare in relazione ai limiti di scala e precisione:
NUMERIC
nel dialetto PostgreSQL è un tipo numerico con precisione decimale arbitraria (la scala o la precisione può essere qualsiasi numero nell'intervallo supportato) e quindi è una scelta ideale per l'archiviazione di dati numerici di precisione arbitraria.NUMERIC
in GoogleSQL è un tipo numerico con precisione fissa (precisione=38 e scala=9) e non può essere utilizzato per memorizzare dati numerici di precisione arbitraria. Quando devi archiviare numeri di precisione arbitraria nei database in dialetto GoogleSQL, ti consigliamo di archiviarli come stringhe.
Precisione dei tipi numerici di Spanner
La precisione corrisponde al numero di cifre di un numero. La scala è il numero di cifre a destra del separatore decimale in un numero. Ad esempio, il numero 123,456 ha una precisione di 6 e una scala di 3. Spanner ha tre tipi numerici:
- Tipo di numero intero con segno a 64 bit chiamato
INT64
nel dialetto GoogleSQL eINT8
nel dialetto PostgreSQL. - Tipo a virgola mobile con precisione binaria IEEE a 64 bit (doppio) denominato
FLOAT64
nel dialetto GoogleSQL eFLOAT8
nel dialetto PostgreSQL. - Tipo di precisione decimale
NUMERIC
.
Vediamoli in termini di precisione e scala.
INT64
/ INT8
rappresenta valori numerici che non hanno un componente frazionario. Questo tipo di dati fornisce 18 cifre di precisione, con una scala pari a zero.
FLOAT64
/ FLOAT8
può rappresentare solo valori numerici decimali approssimativi con componenti frazionari e fornisce da 15 a 17 cifre significative (numero di cifre in un numero con tutti i zeri finali
rimossi) di precisione decimale. Diciamo che questo tipo rappresenta valori numerici decimali approssimazioni perché la rappresentazione binaria IEEE a virgola mobile a 64 bit utilizzata da Spanner non può rappresentare con precisione le frazioni decimali (base 10) (può rappresentare con precisione solo le frazioni di base 2).
Questa perdita di precisione introduce errori di arrotondamento per alcune frazioni decimali.
Ad esempio, quando memorizzi il valore decimale 0,2 utilizzando il tipo di dato FLOAT64
/ FLOAT8
, la rappresentazione binaria viene convertita nuovamente in un valore decimale di 0,20000000000000001 (con 18 cifre di precisione). Analogamente, (1,4 * 165) si riconverte in 230,999999999999971 e (0,1 + 0,2) si riconverte in 0,30000000000000004. Questo è il motivo per cui i numeri in virgola mobile a 64 bit sono descritti come aventi solo 15-17 cifre significative di precisione (solo alcuni numeri con più di 15 cifre decimali possono essere rappresentati come numeri in virgola mobile a 64 bit senza arrotondamento). Per ulteriori dettagli su come viene calcolata la precisione in virgola mobile, consulta la sezione Formato con virgola mobile a precisione doppia.
Né INT64
/ INT8
né FLOAT64
/ FLOAT8
hanno la precisione ideale per i calcoli finanziari, scientifici o ingegneristici, in cui in genere è richiesta una precisione di almeno 30 cifre.
Il tipo di dati NUMERIC
è adatto a queste applicazioni, in quanto è in grado di rappresentare valori numerici con precisione decimale esatta con una precisione di più di 30 cifre decimali.
Il tipo di dato NUMERIC
di GoogleSQL può rappresentare numeri con una precisione decimale fissa di 38 e una scala fissa di 9. L'intervallo di NUMERIC
di GoogleSQL è -99999999999999999999999999999.999999999
a 99999999999999999999999999999.999999999.
Il tipo NUMERIC
del dialetto PostgreSQL può rappresentare numeri con una precisione decimale massima di 147.455 e una scala massima di 16.383.
Se devi memorizzare numeri superiori alla precisione e alla scala offerte da NUMERIC
, le sezioni seguenti descrivono alcune soluzioni consigliate.
Consiglio: memorizza i numeri di precisione arbitraria come stringhe
Quando devi memorizzare un numero di precisione arbitraria in un database Spanner e hai bisogno di una precisione maggiore di quella fornita da NUMERIC
, ti consigliamo di memorizzare il valore come rappresentazione decimale in una colonna STRING
/ VARCHAR
. Ad esempio, il numero 123.4
viene memorizzato come stringa "123.4"
.
Con questo approccio, l'applicazione deve eseguire una conversione senza perdita di dati tra la rappresentazione interna dell'applicazione del numero e il valore della colonna STRING
/ VARCHAR
per le letture e le scritture del database.
La maggior parte delle librerie di precisione arbitraria dispone di metodi integrati per eseguire questa conversione senza perdita di dati. In Java, ad esempio, puoi utilizzare il metodo
BigDecimal.toPlainString()
e il costruttore BigDecimal(String)
.
L'archiviazione del numero come stringa ha il vantaggio che il valore viene archiviato con precisione esatta (fino al limite di lunghezza della colonna STRING
/ VARCHAR
) e rimane leggibile.
Esegui aggregazioni e calcoli esatti
Per eseguire aggregazioni e calcoli esatti sulle rappresentazioni di stringhe di numeri con precisione arbitraria, la tua applicazione deve eseguire questi calcoli. Non puoi utilizzare le funzioni di aggregazione SQL.
Ad esempio, per eseguire l'equivalente di un SUM(value)
SQL su un intervallo di righe, l'applicazione deve eseguire query sui valori di stringa delle righe, quindi convertirli e sommarli internamente nell'app.
Esegui aggregazioni, ordinamento e calcoli approssimativi
Puoi utilizzare le query SQL per eseguire calcoli aggregati approssimazioni eseguendo il casting dei valori in FLOAT64
/ FLOAT8
.
GoogleSQL
SELECT SUM(CAST(value AS FLOAT64)) FROM my_table
PostgreSQL
SELECT SUM(value::FLOAT8) FROM my_table
Analogamente, puoi ordinare in base al valore numerico o limitare i valori per intervallo con il casting:
GoogleSQL
SELECT value FROM my_table ORDER BY CAST(value AS FLOAT64);
SELECT value FROM my_table WHERE CAST(value AS FLOAT64) > 100.0;
PostgreSQL
SELECT value FROM my_table ORDER BY value::FLOAT8;
SELECT value FROM my_table WHERE value::FLOAT8 > 100.0;
Questi calcoli sono approssimativi ai limiti del tipo di dati FLOAT64
/ FLOAT8
.
Alternative
Esistono altri modi per memorizzare numeri con precisione arbitraria in Spanner. Se la memorizzazione di numeri con precisione arbitraria come stringhe non funziona per la tua applicazione, valuta le seguenti alternative:
Memorizza valori interi con scalabilità dell'applicazione
Per memorizzare numeri con precisione arbitraria, puoi eseguire la prescalatura dei valori prima della scrittura, in modo che i numeri vengano sempre memorizzati come numeri interi, e riscala i valori dopo la lettura. L'applicazione memorizza un fattore di scala fisso e la precisione è limitata alle 18 cifre fornite dal tipo di dati INT64
/ INT8
.
Prendiamo, ad esempio, un numero che deve essere memorizzato con una precisione di 5 cifre decimali. L'applicazione converte il valore in un numero intero moltiplicandolo per 100.000 (spostando la virgola decimale di 5 posizioni a destra), pertanto il valore 12,54321 viene memorizzato come 1254321
.
In termini monetari, questo approccio è come memorizzare i valori in dollari come multipli di mille centesimi, in modo simile alla memorizzazione delle unità di tempo in millisecondi.
L'applicazione determina il fattore di scalabilità fisso. Se modifichi il coefficiente di scala, devi convertire tutti i valori sottoposti a scalatura precedente nel database.
Questo approccio memorizza valori leggibili (supponendo che tu conosca il coefficiente di scala). Inoltre, puoi utilizzare le query SQL per eseguire calcoli direttamente sui valori memorizzati nel database, a condizione che il risultato sia scalato correttamente e non generi un overflow.
Memorizza il valore intero non scalato e la fare lo scale in colonne separate
In Spanner puoi anche memorizzare numeri con precisione arbitraria utilizzando due elementi:
- Il valore intero non scalato memorizzato in un array di byte.
- Un numero intero che specifica il fattore di scalabilità.
Innanzitutto, l'applicazione converte il numero decimale con precisione arbitraria in un valore intero non scalato. Ad esempio, l'applicazione converte 12.54321
in 1254321
.
La scala per questo esempio è 5
.
L'applicazione converte quindi il valore intero non scalato in un array di byte utilizzando una rappresentazione binaria portatile standard (ad esempio, complemento a due big-endian).
Il database memorizza quindi l'array di byte (BYTES
/ BYTEA
) e la scala di interi (INT64
/ INT8
)
in due colonne separate e li riconverte in fase di lettura.
In Java, puoi utilizzare BigDecimal
e BigInteger
per eseguire questi calcoli:
byte[] storedUnscaledBytes = bigDecimal.unscaledValue().toByteArray();
int storedScale = bigDecimal.scale();
Puoi leggere di nuovo in un BigDecimal
Java utilizzando il seguente codice:
BigDecimal bigDecimal = new BigDecimal(
new BigInteger(storedUnscaledBytes),
storedScale);
Questo approccio memorizza i valori con una precisione arbitraria e una rappresentazione portatile, ma i valori non sono leggibili dall'uomo nel database e tutti i calcoli devono essere eseguiti dall'applicazione.
Memorizza la rappresentazione interna dell'applicazione sotto forma di byte
Un'altra opzione è serializzare i valori decimali con precisione arbitraria in array di byte utilizzando la rappresentazione interna dell'applicazione, quindi archiviarli direttamente nel database.
I valori del database archiviati non sono leggibili e l'applicazione deve eseguire tutti i calcoli.
Questo approccio presenta problemi di portabilità. Se provi a leggere i valori con un linguaggio di programmazione o una libreria diversi da quelli utilizzati per la scrittura originale, la lettura potrebbe non funzionare. La lettura dei valori potrebbe non funzionare perché librerie di precisione arbitraria diverse possono avere rappresentazioni serializzate diverse per gli array di byte.
Passaggi successivi
- Scopri gli altri tipi di dati disponibili per Spanner.
- Scopri come configurare correttamente un modello di dati e una progettazione dello schema di Spanner.
- Scopri di più sull'ottimizzazione della progettazione dello schema per Spanner.