Pianificare il servizio
Prima di crearlo, pianificare il servizio Oracle NoSQL Database Cloud Service. Pensa alle domande qui descritte e decidi cosa vuoi fare, prima di iniziare.
Questo articolo contiene i seguenti argomenti:
Panoramica per sviluppatori
Ottieni una panoramica generale dell'architettura del servizio e seleziona un SDK/Driver che soddisfi le tue esigenze di sviluppo delle applicazioni.
Task sviluppatore NDCS
Oracle NoSQL Database Cloud Service (NDCS) è un servizio completamente HA. È progettato per applicazioni altamente impegnative che richiedono tempi di risposta a bassa latenza, un modello di dati flessibile e un ridimensionamento elastico per carichi di lavoro dinamici. In qualità di servizio completamente gestito, Oracle gestisce tutte le attività amministrative, come gli upgrade del software, le patch di sicurezza, i guasti hardware e l'applicazione di patch.

Descrizione dell'immagine developer_overview.png
SDK/Driver di NoSQL Database - Questi SDK sono concessi in licenza in Universal Permissive License (UPL) e possono essere utilizzati sia su NoSQL Cloud Service che sul database on-premise. Questi sono SDK completi e offrono un ricco set di funzionalità. Questi driver possono essere utilizzati anche nelle applicazioni in esecuzione su cluster Oracle NoSQL in esecuzione in altri fornitori nel cloud.
Puoi fare riferimento alla tabella seguente per i collegamenti agli SDK, alle guide API e agli esempi:
-
SDK (GitHub) - Fornisce dettagli su come installare, connettersi e iniziare a utilizzare l'SDK
-
Guida API - Fornisce i pacchetti, le classi, i metodi e le interfacce disponibili nell'SDK
-
Esempi - Fornisce esempi di codice che è possibile provare
OCI Console: offre la possibilità di creare tabelle rapidamente, modificare tabelle, eliminare tabelle, caricare dati, creare indici rapidamente, eliminare indici, query di base, modificare le capacità delle tabelle e visualizzare le metriche.
SDK/Driver OCI - Oracle Cloud Infrastructure fornisce una serie di kit di sviluppo software (SDK) per facilitare lo sviluppo di soluzioni personalizzate. Questi sono in genere concessi in licenza sotto UPL.
Differenza tra SDK/Driver di NoSQL Database e SDK/Driver OCI:
Gli SDK OCI sono basati su REST. Sono facili da usare ma hanno funzionalità limitate. Gli SDK NoSQL Database, invece, offrono un ricco set di funzionalità. Si consiglia di utilizzare gli SDK di NoSQL Database in quanto offrono i vantaggi riportati di seguito rispetto agli SDK OCI.
-
Gli SDK NoSQL Database possono essere utilizzati nelle applicazioni che si connettono al servizio cloud, ai data store on-premise e al simulatore NoSQL Cloud.
-
Gli SDK NoSQL Database offrono un'esperienza di sviluppo molto più ricca. Supporta più funzioni SQL che non sono supportate tramite REST.
-
Puoi utilizzare implementazioni di terze parti come Jakarta NoSQL o Eclipse TopLink con NoSQL Database SDK.
Riferimenti:
Limiti di Oracle NoSQL Database Cloud Service
Oracle NoSQL Database Cloud Service prevede vari limiti predefiniti. Ogni volta che crei una tabella di Oracle NoSQL Database Cloud Service, il sistema garantisce che le tue richieste rientrino nei limiti del limite specificato. Alcuni limiti sono imposti a livello di tabella e alcuni sono imposti a livello di regione.
Per ulteriori informazioni sui limiti del servizio, sul loro ambito e su come aumentare i limiti del servizio inviando una richiesta, vedere Limiti del servizio. Di seguito sono riportati i limiti correnti applicabili a Oracle NoSQL Database Cloud Service.
| Limite | L'ambito. | Descrizione | Valore in un ambiente non ospitato | Valore in un ambiente hosted |
|---|---|---|---|---|
| Dimensione massima storage tabella | Tabella | Dimensione massima di storage totale per tenant. Lo spazio totale utilizzato per una o più tabelle non può superare questo valore. | 5 TB | 17.5TB |
| Nomi di tabelle | Tabella | Numero massimo di caratteri, caratteri consentiti e caratteri iniziali per i nomi di tabella. | I nomi delle tabelle possono contenere al massimo 256 caratteri. Tutti i nomi devono iniziare con una lettera (a-z, A-Z). I caratteri successivi possono essere lettere (a-z, A-Z), cifre (0-9) o caratteri di sottolineatura. | Come un ambiente non ospitato |
| Capacità con provisioning eseguito - Throughput massimo di lettura e scrittura | Tabella | Throughput massimo di lettura e scrittura durante il provisioning di una tabella. | 40.000 unità di lettura e 20.000 unità di scrittura per tabella. | Fino a 420.000 unità di lettura e 280.000 unità di scrittura totali per tutte le tabelle nell'ambiente hosted |
| Capacità su richiesta - Throughput massimo di lettura e scrittura | Tabella | Throughput massimo di lettura e scrittura durante l'utilizzo della capacità On Demand per il provisioning delle tabelle. | 10.000 unità di lettura e 5.000 unità di scrittura per tabella. | Non consentito/necessario in un ambiente hosted |
| Capacità su richiesta - Numero di tabelle | Area | Numero di tabelle con capacità On Demand. | 3 | Non consentito/necessario in un ambiente hosted |
| Modificare la modalità di provisioning | Tabella | Modificare la modalità di provisioning per la tabella da Provisioning eseguito a On Demand o viceversa. | Può essere modificato solo una volta al giorno. | ND |
| Numero massimo di tabelle | Area | Il numero massimo di tabelle. | 30 | È possibile personalizzarla utilizzando l'aggiornamento dei limiti del servizio Richiesta |
| Numero massimo di colonne | Tabella | Numero massimo di colonne. | 50 | È possibile personalizzarla utilizzando l'aggiornamento dei limiti del servizio Richiesta |
| Numero massimo di aggiornamenti dello schema di tabella | Tabella | Numero massimo di aggiornamenti dello schema di tabella. | 100 | È possibile personalizzarla utilizzando l'aggiornamento dei limiti del servizio Richiesta |
| Numero massimo di indici | Tabella | Il numero massimo di indici. | 5 | È possibile personalizzarla utilizzando l'aggiornamento dei limiti del servizio Richiesta |
| Numero massimo di modifiche per i limiti di throughput e storage | Tabella | Numero massimo di modifiche per i limiti di throughput e storage. | Oracle consente di:
|
È possibile personalizzarla utilizzando l'aggiornamento dei limiti del servizio Richiesta |
| Nomi indice | Indice | Numero massimo di caratteri, caratteri consentiti e carattere iniziale. | I nomi di indice possono contenere al massimo 64 caratteri. Tutti i nomi devono iniziare con una lettera (a-z, A-Z). I caratteri successivi possono essere lettere (a-z, A-Z), cifre (0-9) o caratteri di sottolineatura. | È possibile personalizzarla utilizzando l'aggiornamento dei limiti del servizio Richiesta |
Numero massimo di singole operazioni per richiesta WriteMultiple |
Richiesta | Numero massimo di singole operazioni per ogni richiesta WriteMultiple. |
50 | Come un ambiente non ospitato. È possibile aumentarlo anche utilizzando l'aggiornamento dei limiti del servizio richieste |
Dimensione massima dei dati per la richiesta WriteMultiple. |
Richiesta | La dimensione massima dei dati per la richiesta WriteMultiple. |
25 MB | Come un ambiente non ospitato. È possibile aumentarlo anche utilizzando l'aggiornamento dei limiti del servizio richieste |
| Nomi colonne | A colonne | Numero massimo di caratteri, caratteri consentiti e carattere iniziale. | I nomi dei campi possono contenere al massimo 64 caratteri. Tutti i nomi devono iniziare con una lettera (a-z, A-Z). I caratteri successivi possono essere lettere (a-z, A-Z), cifre (0-9) o caratteri di sottolineatura. | Come un ambiente non ospitato. |
| Dimensione massima chiave indice secondario | Indice | Dimensione massima della chiave di indice. | 64 byte | È possibile personalizzarla utilizzando l'aggiornamento dei limiti del servizio Richiesta |
| Dimensione massima chiave indice primario | Indice | Dimensione massima della chiave primaria. | 64 byte | È possibile personalizzarla utilizzando l'aggiornamento dei limiti del servizio Richiesta |
| Dimensione massima riga | Riga | Dimensione massima riga. | 512 KB | È possibile personalizzarla utilizzando l'aggiornamento dei limiti del servizio Richiesta |
| Lunghezza massima della stringa di query. | Query | Lunghezza massima della stringa di query. | 10 KB | È possibile personalizzarla utilizzando l'aggiornamento dei limiti del servizio Richiesta |
| Frequenza massima supportata delle operazioni DDL. | Area | Frequenza massima supportata delle operazioni DDL. | 4 al minuto | È possibile personalizzarla utilizzando l'aggiornamento dei limiti del servizio Richiesta |
| Valori massimi per le risorse di throughput e storage dei dati. | Area | Valori massimi per le risorse di throughput e storage dei dati. | Per regione, Oracle consente di:
Oracle consente una dimensione massima di storage pari a 5 TB per tenant. L'area può avere una singola tabella con dimensioni di storage di 5 TB, nel qual caso l'area non è in grado di creare un'altra tabella. In alternativa, disporre di più tabelle e assicurarsi che i dati all'interno di tutte queste tabelle rientrino nella dimensione massima di storage di 5 TB. |
420.000 unità di scrittura, 280.000 unità di lettura, 17,5 TB di storage |
Capacità di stima
Scopri come stimare le capacità di throughput e storage per Oracle NoSQL Database Cloud Service.
Informazioni di base dietro il calcolo
Prima di imparare a stimare il throughput e lo storage per il servizio, esaminiamo le definizioni di throughput e unità di storage.
-
Write Unit (WU): per One Write Unit si intende il throughput per un massimo di 1 kilobyte (KB) di dati al secondo. Un'operazione di scrittura è qualsiasi chiamata API di Oracle NoSQL Database Cloud Service che determina l'inserimento, l'aggiornamento o l'eliminazione di un record. Una tabella NoSQL ha un valore limite di scrittura che specifica il numero di unità di scrittura che possono essere utilizzate ogni secondo. Gli aggiornamenti dell'indice utilizzano anche unità di scrittura.
Ad esempio, una dimensione del record inferiore a 1 KB richiede una WU per un'operazione di scrittura. Una dimensione record di 1,5 KB richiede due WU per l'operazione di scrittura.
-
Read Unit (RU): One Read Unit viene definita come throughput per un massimo di 1 KB di dati al secondo per un'operazione di lettura eventualmente coerente. La tabella NoSQL dispone di un valore limite di lettura che specifica il numero di unità di lettura che possono essere utilizzate ogni secondo.
Ad esempio, una dimensione record inferiore a 1 KB richiede una RU per un'operazione di lettura eventualmente coerente. Una dimensione record di 1,5 KB richiede due RU per un'operazione di lettura eventualmente coerente e quattro RU per un'operazione di lettura assolutamente coerente.
-
Capacità di storage: un'unità di storage è un singolo gigabyte (GB) di storage dei dati.
-
Assoluta coerenza: i dati restituiti dovrebbero essere i dati scritti più di recente nel database.
-
Consistenza finale: i dati restituiti potrebbero non essere i dati scritti più di recente nel database; se non vengono apportati nuovi aggiornamenti ai dati, alla fine tutti gli accessi a tali dati restituiranno il valore aggiornato più recente.
Nota: Oracle NoSQL Database Cloud Service gestisce automaticamente le capacità di lettura e scrittura per soddisfare le esigenze dei carichi di lavoro dinamici quando si utilizza la capacità on-demand. Si consiglia di verificare che le esigenze di capacità non superino i limiti di capacità On Demand. Per ulteriori dettagli, consulta la sezione relativa ai limiti di Oracle NoSQL Database Cloud Service.
Fattori che influiscono sull'unità di capacità
Prima di eseguire il provisioning delle unità di capacità, è importante considerare i seguenti fattori che influiscono sulle capacità di lettura, scrittura e storage.
-
Dimensione record: man mano che la dimensione del record aumenta, aumenta anche il numero di unità di capacità utilizzate per scrivere o leggere i dati.
-
Coerenza dei dati: le letture di coerenza assoluta sono il doppio del costo di eventuali letture di coerenza.
-
Indici secondari: in una tabella, quando un record esistente viene modificato (aggiunto, aggiornato o eliminato), l'aggiornamento degli indici secondari utilizza le unità di scrittura. Il costo di throughput totale di cui è stato eseguito il provisioning per un'operazione di scrittura è la somma delle unità di scrittura utilizzate dalla scrittura nella tabella e dall'aggiornamento degli indici secondari locali.
-
Scelta di modellazione dei dati: con JSON senza schema, ogni documento è auto-descrizione che aggiunge il sovraccarico dei metadati alla dimensione complessiva del record. Con tabelle di schema fisse, il sovraccarico per ogni record è esattamente di 1 byte.
-
Modello di query: il costo di un'operazione di query dipende dal numero di righe recuperate, dal numero di predicati, dalla dimensione dei dati di origine, dalle proiezioni e dalla presenza di indici. Le query meno costose specificano una chiave partizione o una chiave indice (con un indice associato) per consentire al sistema di sfruttare gli indici primari e secondari. Un'applicazione può provare query diverse ed esaminare il throughput utilizzato per ottimizzare le operazioni.
Esempio del mondo reale: come stimare il carico di lavoro dell'applicazione
Considera un esempio di applicazione di e-commerce per scoprire come stimare letture e scritture al secondo. In questo esempio, Oracle NoSQL Database Cloud Service viene utilizzato per memorizzare le informazioni del catalogo prodotti dell'applicazione.
-
Identifica il modello dati (JSON o tabella fissa), la dimensione del record e la dimensione della chiave per l'applicazione.
Si supponga che l'applicazione di e-commerce segua il modello di dati JSON e che lo sviluppatore abbia creato una tabella semplice con due colonne. Un identificativo di record (chiave primaria) e un documento JSON per le funzioni e gli attributi del prodotto. Il documento JSON, che è inferiore a 1 KB (0,8 KB) è il seguente:
{ "additionalFeatures": "Front Facing 1.3MP Camera", "os": "Macintosh OS X 10.7", "battery": { "type": "Lithium Ion (Li-Ion) (7000 mAH)", "standbytime" : "24 hours" }, "camera": { "features": ["Flash","Video"], "primary": "5.0 megapixels" }, "connectivity": { "bluetooth": "Bluetooth 2.1", "cell": "T-mobile HSPA+ @ 2100/1900/AWS/850 MHz", "gps": true, "infrared": false, "wifi": "802.11 b/g" }, "description": "Apple iBook is the best in class computer for your professional and personal work.", "display": { "screenResolution": "WVGA (1280 x 968)", "screenSize": "13.0 inches" }, "hardware": { "accelerometer": true, "audioJack": "3.5mm", "cpu": "Intel i7 2.5 GHz", "fmRadio": false, "physicalKeyboard": false, "usb": "USB 3.0" }, "id": "appleproduct_1", "images": ["img/apple-laptop.jpg"], "name": "Myshop.com : Apple iBook", "sizeAndWeight": { "dimensions": [ "300 mm (w)", "300 mm (h)", "12.4 mm (d)" ], "weight": "1250.0 grams" }, "storage": { "hdd": "750GB", "ram": "8GB" } }Si supponga che l'applicazione abbia 100.000 record di questo tipo e che la chiave primaria abbia una dimensione di circa 20 byte. Si supponga inoltre che esistano query che consentono di leggere i record utilizzando l'indice secondario. Ad esempio, per trovare tutti i record con dimensioni dello schermo di 13 pollici. Viene quindi creato un indice nel campo
screenSize.Le informazioni in sintesi sono le seguenti:
Tabelle Righe per tabella Colonne per tabella Dimensione chiave in byte Dimensione valore in byte (somma di tutte le colonne) Indici Dimensione chiave indice in byte 1 100000 2 20 1 KB 1 20 -
Identificare l'elenco delle operazioni (in genere operazioni CRUD e letture dell'indice) sulla tabella e a quale velocità (al secondo) sono previste.
Operazione Numero di operazioni (al secondo) Esempio Crea record. 3 Per creare un prodotto, procedere nel seguente modo. Leggere i record utilizzando la chiave primaria. 200 Per leggere i dettagli del prodotto utilizzando l'ID prodotto. Leggere i record utilizzando l'indice secondario. 1 Per recuperare tutti i prodotti che hanno una dimensione dello schermo di 13 pollici. Aggiornare o aggiungere un attributo a un record. 5 Per aggiornare la descrizione del prodotto di una fotocamera
o
Aggiungere informazioni sul peso di una macchina fotografica.
Elimina record. 5 Per eliminare un prodotto esistente, procedere come segue. -
Identificare il consumo di lettura e scrittura in KB.
Operazione Presupposti (se presenti) Formula Consumo in lettura (KB) Consumo scrittura (KB) Note/spiegazione Crea record. Si supponga che i record vengano creati senza eseguire alcun controllo delle condizioni (se esistenti). Record size (rounded to next KB) + 1 KB(index) * (number of indexes)0 1 KB + 1 KB (1 ) = 2 KB La dimensione del record è di 1 KB (0,8 KB per la colonna JSON e 20 byte per la colonna chiave) e vi è un indice di dimensione di 1 KB.
Un'operazione di creazione comporta un costo unitario di lettura se si eseguono i comandi put con alcune opzioni. Poiché è necessario garantire che si stia leggendo la versione più recente della riga, vengono utilizzate letture assolutamente coerenti. In questi casi si utilizza il moltiplicatore 2 nella formula unità di lettura. Ecco le diverse opzioni per determinare i costi unitari di lettura:
- Se si utilizza Option.IfAbsent o Option.IfPresent, consumo lettura = 2
- Se si utilizza setReturnRow, Consumo lettura = 2 * Dimensione record
- Se si utilizza Option.IfAbsent e setReturnRow, consumo lettura = 2 * Dimensione record
Leggere i record utilizzando la chiave primaria. Record size round up to KBDimensione record = 1 KB 0 La dimensione del record è di 1 KB Leggere i record utilizzando l'indice secondario. Si supponga che vengano restituiti 100 record. record_size * number_of_records_matched11 KB *100 = 100 KB
100 KB + 10 KB = 110 KB
0 Nessun costo per l'indice secondario. La dimensione del record è di 1 KB. Per 100 record è 100 KB.
Ulteriori conti da 10 KB per il sovraccarico variabile che può verificarsi a seconda del numero di batch restituiti e del limite di dimensione impostato per la query.
Il costo comune è il costo dell'ultima chiave di lettura in un batch. Questa è una variabile che dipende dalla dimensione maxReadKB e del record. Il costo comune è fino a (numBatches - 1) * costo di lettura chiave (1 KB).
Aggiorna i record esistenti Si supponga che la dimensione del record aggiornato sia uguale alla dimensione del record precedente (1 KB). Read consumption = record_size * 2Write consumption = original_record_size + new_record_size + 1 KB (index) * (number of writes)1 KB * 2 1 KB + 1 KB + 1 KB(1) *(2) = 4 KB Quando le righe vengono aggiornate utilizzando un'istruzione query(SQL), vengono utilizzate sia le unità di lettura che quelle di scrittura. A seconda dell'aggiornamento, potrebbe essere necessario leggere la chiave primaria, la chiave secondaria o anche il record stesso. Sono necessarie letture assolutamente coerenti per garantire che stiamo leggendo il record più recente. Le letture di coerenza assoluta sono il doppio del costo di eventuali letture di coerenza. Questo è il motivo per cui si moltiplica per 2 nella formula.
Consumo lettura: nessun addebito per l'indice e la dimensione del record è di 1 KB. Se si esegue utilizzando l'opzione setReturnRow, Consumo lettura = 2 * Dimensione record
Consumo scrittura: la dimensione originale e quella del nuovo record è di 1 KB e 1 KB per un indice.
Elimina record Read consumption = 1 KB (index) * 2Write consumption = record_size + 1KB (index) * (number_of_indexes)1 KB (1) *2 = 2 KB 1 KB + 1 KB(1) * (1) = 2 KB Un'eliminazione comporta costi unitari di lettura e scrittura. Dal momento che devi garantire che stai guardando la versione più recente della riga, vengono utilizzate letture assolutamente coerenti, questo è il motivo per utilizzare il moltiplicatore 2 nella formula dell'unità di lettura.
Se si esegue utilizzando l'opzione setReturnRow, Consumo lettura = 2 * Dimensione record. In caso contrario, consumo lettura = 1 KB per un indice
Consumo scrittura: la dimensione del record è di 1 KB e 1 KB per l'indice. Il numero di indici è 1.
Utilizzando i passi 2 e 3, determinare le unità di lettura e scrittura per il carico di lavoro dell'applicazione.
Operazioni Tasso di operazioni Letture al secondo Scritture al secondo Crea record 3 0 6 Leggere i record utilizzando la chiave primaria 300 300 0 Lettura dei record mediante l'indice secondario 10 1.100 0 Aggiorna record esistente 5 10 20 Elimina record 1 2 2 Totale unità di lettura: 1412
Totale unità di scrittura:28
Pertanto, si stima che l'applicazione di e-commerce abbia un carico di lavoro di 1412 letture al secondo e 28 scritture al secondo. Scaricare il valutatore capacità
Nota: i calcoli precedenti presuppongono richieste di lettura coerenti. Per una richiesta di lettura di coerenza assoluta, l'operazione consuma il doppio delle unità di capacità. Pertanto, le unità di capacità di lettura sarebbero 4844 unità di lettura.
Stima del costo mensile
Scopri come stimare il costo mensile della tua sottoscrizione a Oracle Cloud.
Quando sei pronto a ordinare il tuo servizio Oracle Cloud, Oracle ti offre uno stimatore dei costi per capire l'uso e i costi mensili prima di impegnarti in un modello di sottoscrizione o in un importo.
La stima dei costi calcola automaticamente il costo mensile in base all'input di unità di lettura, unità di scrittura e storage. Ma per capire come calcolare le unità di lettura e scrittura per la tua applicazione, segui questi passaggi:
-
Passo 1: passare all'argomento Stima della capacità. Stimare il carico di lavoro dell'applicazione utilizzando l'esempio e le formule descritte in questo argomento.
Scaricare e utilizzare il Capacity Estimator da Oracle Technology Network per stimare le unità di scrittura, le unità di lettura e la capacità di storage per la tua applicazione in base ai criteri per il carico di lavoro dell'applicazione e le operazioni del database.
-
Passo 2: accedi al Cost Estimator sul sito Web di Oracle Cloud. Selezionare la casella di controllo Gestione dati. Scorrere la pagina per individuare Oracle NoSQL Database Cloud e selezionare Aggiungi per aggiungere una voce per Oracle NoSQL Database Cloud in Opzioni di configurazione. Espandere NoSQL Database per trovare le diverse opzioni di utilizzo e configurazione. Input values for the Utilization and Configuration parameters to estimate the cost for Oracle NoSQL Database Cloud Service usage from your Oracle Cloud Pay-As-You-Go and Monthly Flex subscriptions.
-
Passo 3: accedere a Cost Estimator sul sito Web di Oracle Cloud. Nell'elenco a discesa selezionare Gestione dati. In Gestione dati vengono visualizzate varie opzioni. Scorri fino a individuare Oracle NoSQL Database Cloud. Fare clic su Aggiungi per aggiungere una voce per Oracle NoSQL Database Cloud in Opzioni di configurazione.
-
Passo 4: espandere Database - NoSQL per trovare le diverse opzioni di utilizzo e configurazione. Sono disponibili due opzioni in Configurazione. È possibile iniziare con un'opzione "Sempre gratis" (disponibile solo nell'area Phoenix) oppure eseguire il provisioning dell'istanza con la configurazione desiderata.
- Passo 4a: se si desidera un'opzione Sempre gratis, in Configurazione espandere Oracle NoSQL Database Cloud - Lettura, Oracle NoSQL Database Cloud Service - Storage e Oracle NoSQL Database Cloud Service - Scrittura e modificare la capacità di lettura, storage e scrittura su 0. Quindi la stima del costo totale viene visualizzata come 0 ed è possibile procedere con l'opzione Sempre gratis.
-
Passo 5: in alternativa, se si desidera eseguire il provisioning di una capacità di lettura, scrittura e storage superiore a quella disponibile in Sempre gratis, è possibile eseguire questa operazione immettendo i valori di configurazione in Database-NoSQL.
-
Passo 5a: in Utilizzo, non modificare i valori predefiniti poiché Oracle NoSQL Database Cloud Service non utilizza nessuno di questi valori.
-
Passo 5b: in Configurazione, aggiungere il numero di unità di lettura, unità di scrittura e capacità di storage stimate nel passo precedente. Il costo viene stimato in base ai valori di input e visualizzato nella pagina.
-
Nota: se si utilizza la funzione di scala automatica, una fattura verrà generata alla fine del mese per il consumo effettivo di unità di lettura e scrittura in tempo reale. Pertanto, potresti voler raccogliere i tuoi log di audit nell'applicazione per verificare la fatturazione di fine mese. Si consiglia di registrare le unità di lettura e scrittura utilizzate restituite dal servizio NoSQL Database Cloud con ogni chiamata API. Puoi utilizzare questi dati per correlare con i dati di fatturazione di fine mese dal sistema di misurazione e fatturazione Oracle Cloud.
Per una descrizione dettagliata dei diversi modelli di prezzo disponibili, consulta Prezzi di NoSQL Database Cloud Service.
Costo/fatturazione per tabelle attive globali
Il costo/fatturazione per una tabella attiva globale ha due componenti. Il primo componente è il modello di determinazione prezzi seguito per le tabelle singleton, che tiene conto delle unità di lettura al mese, delle unità di scrittura al mese e della capacità di storage in GB al mese. Il secondo componente è per le scritture replicate per ogni replica della tabella regionale per la tabella Global Active. Le scritture replicate in entrata vengono addebitate in base alle scritture utilizzate.