Riferimento a Oracle NoSQL Database Cloud Service

Tipi di dati supportati

Oracle NoSQL Database Cloud Service supporta molti tipi di dati comuni.

Tipo di dati	Descrizione
`BINARY`	Sequenza di zero o più byte. La dimensione di memorizzazione è il numero di byte più una codifica della dimensione dell'array di byte, che è una variabile, a seconda della dimensione dell'array.
`FIXED_BINARY`	Array di byte di dimensione fissa. Nessun sovraccarico di codifica aggiuntivo per questo tipo di dati.
`BOOLEAN`	Tipo di dati con uno dei due valori possibili: `TRUE` o `FALSE`. La dimensione di memorizzazione del valore booleano è di 1 byte.
`DOUBLE`	Numero in virgola mobile lungo, codificato mediante 8 byte di storage per le chiavi di indice. Se si tratta di una chiave primaria, utilizza 10 byte di storage.
`FLOAT`	Numero in virgola mobile lungo, codificato mediante 4 byte di storage per le chiavi di indice. Se si tratta di una chiave primaria, utilizza 5 byte di storage.
`LONG`	Un numero intero lungo ha una codifica di lunghezza variabile che utilizza 1-8 byte di storage a seconda del valore. Se si tratta di una chiave primaria, utilizza 10 byte di storage.
`INTEGER`	Un numero intero lungo ha una codifica di lunghezza variabile che utilizza 1-4 byte di storage a seconda del valore. Se si tratta di una chiave primaria, utilizza 5 byte di storage.
`STRING`	Una sequenza di zero o più caratteri Unicode. Il tipo String è codificato come UTF-8 e memorizzato in tale codifica. La dimensione dello storage è il numero di byte UTF-8 più la lunghezza, che può essere di 1-4 byte a seconda del numero di byte nella codifica. Se memorizzato in una chiave di indice, la dimensione di memorizzazione è il numero di byte UTF-8 più un singolo byte di terminazione nullo.
`NUMBER`	Numero decimale con firma di precisione arbitraria. Viene serializzato in un formato di array di byte che può essere utilizzato per i confronti ordinati. Il formato ha 2 parti: Il segno e l'esponente più una singola cifra. Questo richiede 1-6 byte, ma normalmente è 2 a meno che l'esponente è abbastanza grande La mantissa del valore che è di circa un byte per ogni 2 cifre Esempi 12.345678 serializza in 6 byte 1.234E+102 serializza in 5 byte Nota Quando è necessario utilizzare valori numerici nello schema, si consiglia di decidere i tipi di dati nell'ordine indicato di seguito: INTEGER, LONG, FLOAT, DOUBLE, NUMBER Evitare NUMBER a meno che non sia realmente necessario per il caso d'uso poiché NUMBER è costoso sia in termini di capacità di archiviazione che di elaborazione utilizzata.
`TIMESTAMP`	Un point-in-time con precisione. La precisione influisce sulle dimensioni e sull'utilizzo dello storage. L'indicatore orario viene memorizzato e gestito in UTC (Coordinated Universal Time). Il tipo di dati Timestamp richiede da 3 a 9 byte a seconda della precisione utilizzata. L'analisi stratificata riportata di seguito illustra la memorizzazione utilizzata da questo tipo di dati. bit[0~13] anno - 14 bit bit[14~17] mese - 4 bit bit[18~22] giorno - 5 bit bit[23~27] ora - 5 bit [opzionale] bit[28~33] minuto - 6 bit [facoltativo] bit[34~39] secondo - 6 bit [facoltativo] bit[40~71] frazionario secondo [opzionale con lunghezza variabile]
`UUID`	Nota: il tipo di dati UUID è considerato un sottotipo del tipo di dati STRING. La dimensione di storage è di 16 byte come chiave di indice. Se utilizzata come chiave primaria, la dimensione di storage è di 19 byte.
`ENUM`	Un'enumerazione è rappresentata come un array di stringhe. I valori `ENUM` sono identificatori simbolici (token) e vengono memorizzati come piccolo valore intero che rappresenta una posizione ordinata nell'enumerazione.
`ARRAY`	Raccolta ordinata di zero più articoli digitati. Gli array non definiti come JSON non possono contenere valori `NULL`. Gli array dichiarati come JSON possono contenere qualsiasi JSON valido, incluso il valore speciale nullo, rilevante per JSON.
`MAP`	Raccolta non ordinata di zero o più coppie chiave-articolo, in cui tutte le chiavi sono stringhe e tutti gli elementi sono dello stesso tipo. Tutte le chiavi devono essere univoche. Le coppie chiave-articolo vengono denominate campi, le chiavi sono nomi di campo e gli elementi associati sono valori di campo. I valori dei campi possono avere tipi diversi, ma le mappe non possono contenere valori di campo NULL.
`RECORD`	Raccolta fissa di una o più coppie chiave-elemento, in cui tutte le chiavi sono stringhe. Tutte le chiavi in un record devono essere univoche.
`JSON`	Qualsiasi dato JSON valido.

Stati tabella e cicli di vita

Scopri i diversi stati della tabella e il loro significato (processo del ciclo di vita della tabella).

Ogni tabella passa attraverso una serie di stati diversi, dalla creazione della tabella all'eliminazione (drop). Ad esempio, una tabella con stato DROPPING non può passare allo stato ACTIVE, mentre una tabella con stato ACTIVE può passare allo stato UPDATING. È possibile tenere traccia dei diversi stati delle tabelle monitorando il ciclo di vita delle tabelle. In questa sezione vengono descritti i vari stati della tabella.

Descrizione della tabella state.png:
Descrizione della tabella di figura: state.png

Stato tabella:	Descrizione
`CREATING`	La tabella è in fase di creazione. Non è pronto per l'utilizzo.
`UPDATING`	L'aggiornamento della tabella è in corso. Non è possibile apportare ulteriori modifiche alla tabella con questo stato. Una tabella si trova nello stato `UPDATING` quando: I limiti della tabella vengono modificati Lo schema della tabella si sta evolvendo Aggiunta o eliminazione di un indice di tabella
`ACTIVE`	La tabella può essere utilizzata nello stato corrente. È possibile che la tabella sia stata creata o modificata di recente, ma lo stato della tabella è ora stabile.
`DROPPING`	La tabella è in fase di eliminazione e non è possibile accedervi per alcuno scopo.
`DROPPED`	La tabella è stata eliminata e non esiste più per le attività di lettura, scrittura o query. Nota Una volta eliminata, è possibile creare di nuovo una tabella con lo stesso nome.

Errori dell'istruzione SQL di debug nella console OCI

Quando si utilizza la console OCI per creare una tabella utilizzando un'istruzione DDL o un'istruzione DML per inserire o aggiornare i dati o utilizzando una query SELECT per recuperare i dati, è possibile che venga visualizzato un errore che indica che l'istruzione è incompleta o errata in uno degli scenari comuni riportati di seguito.

Se si dispone di un punto e virgola alla fine dell'istruzione SQL.
Se c'è un errore di sintassi nell'istruzione SQL come l'uso errato delle virgole, l'uso di qualsiasi carattere non necessario nell'istruzione e così via.
In caso di errore di ortografia nell'istruzione SQL in una delle parole chiave SQL o nella definizione del tipo di dati.
Se la colonna è stata definita come NOT NULL ma non è stato assegnato un valore DEFAULT.
Se la colonna è stata definita come NOT NULL ma non è stato assegnato un valore DEFAULT.

Come gestire alcuni errori incompleti o errati durante l'utilizzo della console OCI per creare o gestire i dati:

Rimuovere il punto e virgola (se presente) alla fine dell'istruzione SQL.
Controllare se nell'istruzione SQL sono presenti caratteri indesiderati o punteggiatura errata.
Verificare la presenza di errori di ortografia nell'istruzione SQL.
Verificare che tutte le definizioni di colonna siano complete e corrette.
Verificare se è stata definita una chiave primaria per la tabella.

Se dopo aver eliminato alcune delle possibili situazioni descritte in precedenza si verifica ancora un errore, è possibile utilizzare Cloud Shell per eseguire la query e acquisire l'errore esatto, come illustrato nell'esempio riportato di seguito.

Esempio: recupero del messaggio di errore per un'istruzione SELECT dalla shell cloud shell

Il comando summarize controlla la sintassi e restituisce un breve riepilogo di un'istruzione SQL.

Nella console OCI aprire Cloud Shell dal menu in alto a destra.
Copiare l'istruzione SQL SELECT (ad esempio, query1.sql) in una variabile (SQL_SELECTSTMT).
Esempio:
```
SQL_SELECTSTMT=$(cat ~/query1.sql | tr '\n' ' ')
```

Richiamare il comando oci riportato di seguito per controllare la sintassi dell'istruzione SQL SELECT.

Nota

È necessario fornire compartment_id per questa istruzione SELECT.

oci raw-request --http-method GET --target-uri 
https://nosql.${OCI_REGION}.oci.oraclecloud.com/20190828/query/summarize?compartmentId=$NOSQL_COMPID\
&statement="$SQL_SELECTSTMT" | jq '.data'

Questo vi darà l'errore esatto nella vostra istruzione SQL.

Riferimento al linguaggio di definizione dei dati

Scopri come utilizzare DDL in Oracle NoSQL Database Cloud Service.

Utilizzare la DDL di Oracle NoSQL Database Cloud Service per creare, modificare ed eliminare tabelle e indici.

Per informazioni sulla sintassi della lingua DDL, vedere Table Data Definition Language Guide. Questa guida documenta il linguaggio DDL supportato dal prodotto Oracle NoSQL Database on premise. Oracle NoSQL Database Cloud Service supporta un subset di questa funzionalità e le differenze vengono documentate nella sezione DDL Differences in the Cloud.

Inoltre, ogni driver NoSQL <language> fornisce un'interfaccia API per l'esecuzione di un'istruzione DDL. Per scrivere l'applicazione, vedere Uso delle interfacce API per creare tabelle e indici in Oracle NoSQL Database Cloud Service.

Istruzioni DDL tipiche

Pochi esempi di istruzioni DDL comuni sono i seguenti:

Crea tabella

CREATE TABLE [IF NOT EXISTS] (
    field-definition, field-definition-2 ...,
    PRIMARY KEY (field-name, field-name-2...),
) [USING TTL ttl]

Ad esempio:

CREATE TABLE IF NOT EXISTS audience_info (
    cookie_id LONG,
    ipaddr STRING,
    audience_segment JSON,
    PRIMARY KEY(cookie_id))

Modifica tabella

ALTER TABLE table-name (ADD field-definition)
ALTER TABLE table-name (DROP field-name)
ALTER TABLE table-name USING TTL ttl

Ad esempio:

ALTER TABLE audience_info USING TTL 7 days

Crea indice

CREATE INDEX [IF NOT EXISTS] index-name ON table-name (path_list)

Ad esempio:

CREATE INDEX segmentIdx ON audience_info
       (audience_segment.sports_lover AS STRING)

Elimina tabella

DROP TABLE [IF EXISTS] table-name

Ad esempio:

DROP TABLE audience_info

Consulta le guide di riferimento per un elenco completo:

Differenze DDL nel cloud

Il linguaggio DDL del servizio cloud differisce da quanto descritto nella guida di riferimento nel modo seguente:

Nomi di tabelle

Limitato a 256 caratteri e limitato a caratteri alfanumerici e caratteri di sottolineatura
Deve iniziare con una lettera
Non possono includere caratteri speciali.
Le tabelle figlio non sono supportate

Concetti non supportati

Istruzioni DESCRIBE e SHOW TABLE.
Indici di testo completo
Gestione utenti e ruoli
Region in locale

Riferimento lingua query

Scopri come utilizzare le istruzioni SQL per aggiornare ed eseguire query sui dati in Oracle NoSQL Database Cloud Service.

Oracle NoSQL Database utilizza il linguaggio di query SQL per aggiornare ed eseguire query sui dati nelle tabelle NoSQL. Per informazioni sulla sintassi del linguaggio di query, vedere SQL Reference for Oracle NoSQL Database.

Query tipiche

SELECT <expression>
FROM <table name>
[WHERE <expression>]
[GROUP BY <expression>]
[ORDER BY <expression> [<sort order>]]
[LIMIT <number>]
[OFFSET <number>]; 

For example:
SELECT * FROM Users;
SELECT id, firstname, lastname FROM Users WHERE firstname = "Taylor";

UPDATE <table_name> [AS <table_alias>]
    <update_clause>[, <update_clause>]*
WHERE <expr>[<returning_clause>];

For example:
UPDATE JSONPersons $j
  SET TTL 1 DAYS
  WHERE id = 6
  RETURNING remaining_days($j) AS Expires;

Differenze linguistiche delle query nel cloud

Il supporto delle query del servizio cloud è diverso da quanto descritto nella guida di riferimento del linguaggio di query nel modo seguente:

Limitazioni sulle espressioni utilizzate nella clausola SELECT

Oracle NoSQL Database Cloud Service supporta il raggruppamento di espressioni o espressioni aritmetiche tra funzioni di aggregazione. Nella clausola SELECT non sono consentiti altri tipi di espressioni. Ad esempio, le espressioni CASE non sono consentite nella clausola SELECT.

Ogni driver di database NoSQL fornisce un'API per eseguire un'istruzione di query.

Riferimento piano query

Un piano di esecuzione query è la sequenza di operazioni che Oracle NoSQL Database esegue per eseguire una query.

Un piano di esecuzione query è una struttura di iteratori del piano. Ogni tipo di iteratore valuta un tipo diverso di espressione che può apparire in una query. In generale, la scelta dell'indice e il tipo di predicati di indice associati possono avere un effetto drastico sulle prestazioni delle query. Di conseguenza, l'utente desidera spesso vedere quale indice viene utilizzato da una query e quali predicati sono stati sottoposti a push verso il basso. Sulla base di queste informazioni, si consiglia di forzare l'uso di un indice diverso tramite suggerimenti di indice. Queste informazioni sono contenute nel piano di esecuzione query. Tutti i driver Oracle NoSQL forniscono API per visualizzare il piano di esecuzione di una query.

Alcuni degli iteratori più comuni e importanti utilizzati nelle query sono:

iteratore della tabella: un iteratore della tabella è responsabile di:

Scansione dell'indice utilizzato dalla query (che potrebbe essere l'indice principale).
Applicazione di eventuali predicati di filtraggio inviati all'indice
Se necessario, recuperare le righe a cui fanno riferimento le voci di indice qualificanti. Se l'indice copre, il set di risultati dell'iteratore TABLE è un set di voci di indice, altrimenti si tratta di un set di righe di tabella.

Nota

Un indice viene definito indice di copertura rispetto a una query se la query può essere valutata utilizzando solo le voci di tale indice, ovvero senza la necessità di recuperare le righe associate.

iteratore SELECT: è responsabile dell'esecuzione dell'espressione SELECT.

Ogni query contiene una clausola SELECT. Quindi ogni piano di query avrà un iteratore SELECT. Un iteratore SELECT ha la seguente struttura:


"iterator kind" : "SELECT",
"FROM" :
  {
  },
"FROM variable" : "...",
"SELECT expressions" : 
[
  {
  }
]

L'iteratore SELECT contiene campi quali: "FROM", "WHERE", "FROM variable" e "SELECT expression". "FROM" e "FROM variable" rappresentano la clausola FROM dell'espressione SELECT, WHERE rappresenta la clausola di filtro e "SELECT expression" rappresenta la clausola SELECT.

iteratore RECEIVE: è un iteratore interno speciale che separa il piano di query in 2 parti:

L'iteratore RECEIVE stesso e tutti gli iteratori che si trovano sopra di esso nella struttura dell'iteratore vengono eseguiti sul driver.
Tutti gli iteratori al di sotto dell'iteratore RECEIVE vengono eseguiti nei nodi di replica (RN); questi iteratori formano una struttura secondaria con origine nel figlio univoco dell'iteratore RECEIVE.

In generale, l'iteratore RECEIVE funge da coordinatore query. Invia il suo piano secondario agli RN appropriati per l'esecuzione e raccoglie i risultati. Può eseguire operazioni aggiuntive come l'ordinamento e l'eliminazione dei duplicati e propaga i risultati agli eventuali iteratori predecessori per un'ulteriore elaborazione.

Tipi di distribuzione:

Un tipo di distribuzione specifica il modo in cui la query verrà distribuita per l'esecuzione tra gli RN che partecipano a un database NoSQL (un negozio) Oracle. Il tipo di distribuzione è una proprietà dell'iteratore RECEIVE.

Diverse scelte di distribuzione tipi sono:

SINGLE_PARTITION: una query SINGLE_PARTITION specifica una chiave di partizione completa nella relativa clausola WHERE. Di conseguenza, il suo set di risultati completo è contenuto in una singola partizione e l'iteratore RECEIVE invierà il suo piano secondario a un singolo RN che memorizza tale partizione. Una query SINGLE_PARTITION può utilizzare l'indice di chiave primaria o un indice secondario.
ALL_PARTITIONS: le query utilizzano qui l'indice della chiave primaria e non specificano una chiave di partizione completa. Di conseguenza, se il negozio ha partizioni M, l'iteratore RECEIVE invierà M copie del suo piano secondario da eseguire su una delle partizioni M ciascuna.
ALL_SHARDS: le query utilizzano un indice secondario e non specificano una chiave partizione completa. Di conseguenza, se il negozio ha N partizioni, l'iteratore RECEIVE invierà N copie del suo piano secondario da eseguire su una delle partizioni N ciascuna.

Anatomia di un piano di esecuzione di query:

L'esecuzione della query viene eseguita in batch. Quando un piano secondario di query viene inviato a una partizione o a una partizione per l'esecuzione, verrà eseguito fino al raggiungimento di un limite batch. Il limite batch è un numero di unità di lettura utilizzate localmente dalla query. Il valore predefinito è 2000 unità di lettura (circa 2 MB di dati) e può essere ridotto solo tramite un'opzione a livello di query.

Quando viene raggiunto il limite del batch, tutti i risultati locali prodotti vengono inviati all'iteratore RECEIVE per un'ulteriore elaborazione insieme a un flag booleano che indica se possono essere disponibili altri risultati locali. Se il flag è true, la risposta include informazioni sul curriculum. Se l'iteratore RECEIVE decide di inviare di nuovo la query alla stessa partizione/shard, includerà queste informazioni di curriculum nella richiesta, in modo che l'esecuzione della query venga riavviata nel punto in cui si è interrotta durante il batch precedente. Questo perché non viene mantenuto alcuno stato di query all'RN al termine di un batch. Il batch successivo per la stessa partizione / partizione può avvenire allo stesso RN del batch precedente o in un RN diverso che memorizza anche la stessa partizione / partizione.