Pianificare il servizio

Prima di crearlo, è necessario pianificare il servizio Oracle NoSQL Database Cloud Service. Pensa alle domande qui delineate e decidi cosa vuoi fare, prima di iniziare.

Questo articolo contiene i seguenti argomenti:

Panoramica per gli 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 dati flessibile e una scalabilità elastica per carichi di lavoro dinamici. Come servizio completamente gestito, Oracle gestisce tutte le attività amministrative come gli aggiornamenti del software, le patch di sicurezza, gli errori hardware e l'applicazione di patch.

Segue la descrizione di developer_overview.png

Descrizione dell'immagine developer_overview.png

NoSQL SDK/driver di database: questi SDK sono concessi in licenza in base alla Universal Permissive License (UPL) e possono essere utilizzati su NoSQL Cloud Service o 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 nel cloud di altri fornitori.

OCI Console: offre la possibilità di creare rapidamente tabelle, modificare tabelle, eliminare tabelle, caricare dati, creare rapidamente indici, eliminare indici, query di base, modificare le capacità delle tabelle e visualizzare le metriche.

SDK/driver OCI: Oracle Cloud Infrastructure offre una serie di kit SDK (Software Development Kit) per facilitare lo sviluppo di soluzioni personalizzate. Questi sono in genere concessi in licenza sotto UPL. Queste offrono funzionalità simili alla console OCI tramite un'interfaccia programmatica.

Riferimenti:

Limiti di Oracle NoSQL Database Cloud Service

Per Oracle NoSQL Database Cloud Service sono previsti vari limiti predefiniti. Ogni volta che si crea una tabella di Oracle NoSQL Database Cloud Service, il sistema garantisce che le 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 dei servizi, sul relativo ambito e su come aumentare i limiti del servizio inviando una richiesta, vedere Limiti dei servizi. Di seguito sono elencati i limiti correnti applicabili a Oracle NoSQL Database Cloud Service.

Limite	L'ambito.	Descrizione	Valore in un ambiente non ospitato	Valore in un ambiente ospitato
Dimensione massima memoria 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 carattere iniziale per i nomi delle tabelle.	I nomi di tabella 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.	Uguale a 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 tavolo.	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 tavolo.	Non consentito/necessario in un ambiente ospitato
Capacità su richiesta - Numero di tabelle	Area	Numero di tabelle con capacità su richiesta.	3	Non consentito/necessario in un ambiente ospitato
Modifica 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	Questa operazione può essere personalizzata mediante l'aggiornamento dei limiti del servizio di richiesta
Numero massimo di colonne.	Tabella	Il numero massimo di colonne.	50	Questa operazione può essere personalizzata mediante l'aggiornamento dei limiti del servizio di richiesta
Numero massimo di aggiornamenti dello schema tabella	Tabella	Numero massimo di aggiornamenti dello schema tabella.	100	Questa operazione può essere personalizzata mediante l'aggiornamento dei limiti del servizio di richiesta
Numero massimo di indici	Tabella	Il numero massimo di indici.	5	Questa operazione può essere personalizzata mediante l'aggiornamento dei limiti del servizio di richiesta
Numero massimo di modifiche per i limiti di throughput e storage	Tabella	Il numero massimo di modifiche per i limiti di throughput e storage.	Oracle consente: Aumento del numero illimitato di throughput e storage al giorno Fino a quattro riduzioni del throughput o dello storage per un periodo di 24 ore.	Questa operazione può essere personalizzata mediante l'aggiornamento dei limiti del servizio di richiesta
Nomi indici	Indice	Il numero massimo di caratteri, i caratteri consentiti e il carattere iniziale.	I nomi 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.	Questa operazione può essere personalizzata mediante l'aggiornamento dei limiti del servizio di richiesta
Numero massimo di singole operazioni per ogni richiesta `WriteMultiple`	Richiesta	Il numero massimo di singole operazioni per ogni richiesta `WriteMultiple`.	50	Uguale a un ambiente non ospitato. Questo valore può essere aumentato anche utilizzando l'aggiornamento dei limiti del servizio di richiesta
Dimensione massima dati per la richiesta `WriteMultiple`.	Richiesta	La dimensione massima dei dati per la richiesta `WriteMultiple`.	25 MB	Uguale a un ambiente non ospitato. Questo valore può essere aumentato anche utilizzando l'aggiornamento dei limiti del servizio di richiesta
Nome colonne	A colonne	Il numero massimo di caratteri, i caratteri consentiti e il 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.	Uguale a un ambiente non ospitato.
Dimensione massima della chiave di indice secondaria	Indice	Dimensione massima della chiave di indice.	64 byte	Questa operazione può essere personalizzata mediante l'aggiornamento dei limiti del servizio di richiesta
Dimensione massima della chiave di indice primaria	Indice	Dimensione massima della chiave primaria.	64 byte	Questa operazione può essere personalizzata mediante l'aggiornamento dei limiti del servizio di richiesta
Dimensione massima riga	Riga	Dimensione massima riga.	512 KB	Questa operazione può essere personalizzata mediante l'aggiornamento dei limiti del servizio di richiesta
Lunghezza massima della stringa di query.	Query	Lunghezza massima della stringa di query.	10 KB	Questa operazione può essere personalizzata mediante l'aggiornamento dei limiti del servizio di richiesta
Frequenza massima supportata delle operazioni DDL.	Area	Frequenza massima supportata delle operazioni DDL.	4 al minuto	Questa operazione può essere personalizzata mediante l'aggiornamento dei limiti del servizio di 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 area, Oracle consente: Un massimo di 100.000 unità di lettura Un massimo di 40.000 unità di scrittura Oracle consente una dimensione di storage massima di 5 TB per tenant. L'area può avere una singola tabella con una dimensione 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 contenuti in tutte queste tabelle rientrino nella dimensione di storage massima di 5 TB.	420.000 unità di scrittura, 280.000 unità di lettura, 17,5 TB di storage

Argomenti correlati

Capacità stimata

Scopri come stimare la capacità di throughput e storage per Oracle NoSQL Database Cloud Service.

Nozioni 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.

Unità di scrittura (WU): un'unità di scrittura viene definita come throughput per un massimo di 1 kilobyte (KB) di dati al secondo. Per operazione di scrittura si intende qualsiasi chiamata API Oracle NoSQL Database Cloud Service che comporta 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 al secondo. Gli aggiornamenti dell'indice consumano anche unità di scrittura.

Ad esempio, una dimensione 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.
Unità di lettura (RU): una unità di lettura è definita come throughput per un massimo di 1 KB di dati al secondo per un'operazione di lettura probabilmente coerente. La tabella NoSQL contiene 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 un'RU per un'operazione di lettura probabilmente coerente. Una dimensione record di 1,5 KB richiede due RU per un'operazione di lettura alla fine coerente e quattro RU per un'operazione di lettura assolutamente coerente.
Capacità di storage: una unità di storage è un singolo gigabyte (GB) di storage dei dati.
Coerenza assoluta: 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à su richiesta. 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 Unità di scrittura. Il costo throughput di cui è stato eseguito il provisioning totale per un'operazione di scrittura è la somma delle unità di scrittura utilizzate scrivendo nella tabella e aggiornando gli indici secondari locali.
Scelta di modellazione dei dati: con JSON senza schema, ogni documento è auto-descrivibile e aggiunge il sovraccarico dei metadati alla dimensione complessiva del record. Con le tabelle di schema fisso, il sovraccarico per ogni record è esattamente di 1 byte.
Pattern 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 degli indici. Le query meno costose specificano una chiave di partizione o una chiave di indice (con un indice associato) per consentire al sistema di sfruttare gli indici primario e secondario. Un'applicazione può provare query diverse ed esaminare il throughput utilizzato per ottimizzare le operazioni.

Esempio di mondo reale: come stimare il carico di lavoro dell'applicazione

Considera un esempio di applicazione di E-commerce per imparare a 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.

Identificare 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 dati JSON e che lo sviluppatore abbia creato una tabella semplice con due colonne. Identificativo di record (chiave primaria) e documento JSON per le caratteristiche 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 disponga di 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 leggono 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 di 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 con quale frequenza (al secondo) sono previste.

Operazione	Numero di operazioni (al secondo)	Esempio
Crea record.	3	Creare un prodotto.
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 con 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	Consente di eliminare un prodotto esistente.

Identificare il consumo in lettura e scrittura in KB.

Operazione	Presupposti (se presenti)	Formula	Consumo in lettura (KB)	Consumo in scrittura (KB)	Note/spiegazione
Crea record.	Si supponga che i record vengano creati senza eseguire controlli 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 c'è un indice della 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 la lettura della versione più recente della riga, vengono utilizzate letture coerenti assolute. In questi casi si utilizza il moltiplicatore 2 nella formula dell'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 vengono utilizzati Option.IfAbsent e setReturnRow, Consumo lettura = 2 * Dimensione record
Leggere i record utilizzando la chiave primaria.		`Record size round up to KB`	Dimensione record = 1 KB	0	La dimensione del record è 1 KB
Leggere i record utilizzando l'indice secondario.	Si supponga che vengano restituiti 100 record.	`record_size * number_of_records_matched`	11KB *100 = 100KB 100 KB + 10 KB = 110 KB	0	Nessun addebito per l'indice secondario. La dimensione del record è 1 KB. Per 100 record è di 100 KB. Account aggiuntivi di 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 indiretto è il costo di lettura dell'ultima chiave in un batch. Si tratta di una variabile che dipende dal valore maxReadKB e dalla dimensione del record. Il sovraccarico è fino a (numBatches - 1) * costo di lettura chiave (1 KB).
Aggiorna record esistenti	Si supponga che la dimensione del record aggiornato sia uguale alla dimensione del record precedente (1 KB).	`Read consumption = record_size * 2` `Write 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 moltiplicare per 2 nella formula. Consumo in lettura: nessun addebito per l'indice e la dimensione del record è di 1 KB. Se si esegue l'esecuzione utilizzando l'opzione setReturnRow, Consumo lettura = 2 * Dimensione record Consumo in scrittura: le dimensioni del record originale e nuovo sono 1 KB e 1 KB per un indice.
Elimina record		`Read consumption = 1 KB (index) * 2` `Write 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 coerenti assolute, che è il motivo per utilizzare il moltiplicatore 2 nella formula dell'unità di lettura. Se si esegue l'esecuzione utilizzando l'opzione setReturnRow, Consumo lettura = 2 * Dimensione record. In caso contrario, consumo lettura= 1 KB per un indice Consumo in scrittura: la dimensione del record è di 1 KB e 1 KB per l'indice. Il numero di indice è 1.

Utilizzando i passi 2 e 3, determinare le unità di lettura e scrittura per il carico di lavoro dell'applicazione.

Operazioni	Frequenza operazioni	Letture al secondo	Scritture al secondo
Crea record	3	0	6
Leggere i record mediante la chiave primaria	300	300	0
Leggere i record utilizzando l'indice secondario	10	1.100	0
Aggiorna record esistente	5	10	20
Elimina record	1	2	2

Unità di lettura totali: 1412

Unità di scrittura totali: 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. Scarica lo strumento Capacity Estimator disponibile su Oracle Technology Network per inserire questi valori ed effettuare una stima del throughput e dello storage della tua applicazione.

Nota

I calcoli precedenti presuppongono infine 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 sottoscrizione a Oracle Cloud.

Quando sei pronto per ordinare il tuo servizio Oracle Cloud, Oracle ti fornisce una stima dei costi per determinare l'uso e i costi mensili prima di eseguire il commit su un modello di sottoscrizione o su un importo.

Il cost stimator 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à. Stima il carico di lavoro dell'applicazione utilizzando l'esempio e le formule descritte in questo argomento.

Passo 2: scaricare e utilizzare Capacity Estimator da Oracle Technology Network per stimare le unità di scrittura, di lettura e la capacità di storage per la propria applicazione in base al carico di lavoro dell'applicazione e ai criteri delle operazioni del database.
Passo 2: accedere al Cost Estimator sul sito Web di Oracle Cloud. Selezionare la casella di controllo Gestione dati. Scorrere fino a individuare Oracle NoSQL Database Cloud e fare clic su Aggiungi per aggiungere una voce per Oracle NoSQL Database Cloud in Opzioni di configurazione. Espandere Database NoSQL per trovare le diverse opzioni di utilizzo e configurazione. Valori di input per i parametri di utilizzo e configurazione per stimare il costo per l'uso di Oracle NoSQL Database Cloud Service dalle sottoscrizioni Oracle Cloud Pay-As-You-Go e Monthly Flex.
Passo 3: accedere al Cost Estimator sul sito Web di Oracle Cloud. Nell'elenco a discesa selezionare Gestione dati. In Gestione dati vengono visualizzate varie opzioni. Scorrere per 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 il database - NoSQL per trovare le diverse opzioni di utilizzo e configurazione. Sono disponibili due opzioni in Configurazione. È possibile iniziare con un'opzione "Sempre gratis" 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 come 0. La stima dei costi totali 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 farlo 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 5 b: in Configurazione, aggiungere il numero di unità di lettura, di scrittura e di capacità di storage stimato 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, verrà generata una fattura di fine 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 consumate restituite dal servizio NoSQL Database Cloud con ogni chiamata API. Puoi utilizzare questi dati per correlare con i dati di fatturazione di fine mese del sistema di misurazione e fatturazione di Oracle Cloud.

Per una comprensione dettagliata dei diversi modelli di determinazione prezzi disponibili, vedere Prezzi di NoSQL Database Cloud Service.

Costo/fatturazione per tabelle attive globali

Il costo/fatturazione per una tabella attiva globale include due componenti. Il primo componente è il modello di definizione dei prezzi seguito per le tabelle SINGLETON, che tiene conto delle unità di lettura al mese, di scrittura al mese e della capacità di storage in GB al mese. Il secondo componente riguarda 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.

Titolo e informazioni sul copyright

Pianificare il servizio

Oracle e/o relative consociate.