Domande frequenti su Amazon Timestream

I dati di serie temporali sono una sequenza di dati, come i prezzi delle azioni, la temperatura e l'uso della CPU di un'istanza Amazon EC2, registrati nel tempo. Con i dati di serie temporali, ogni punto dati è costituito da un timestamp, da uno o più attributi e dall'evento che cambia nel tempo. Questi dati vengono utilizzati per ricavare informazioni sulle prestazioni e sullo stato di un'applicazione, rilevare anomalie e identificare opportunità di ottimizzazione.

Ad esempio, gli ingegneri DevOps potrebbero voler visualizzare i dati che misurano i cambiamenti nei parametri delle prestazioni dell'infrastruttura, i produttori potrebbero voler tenere traccia dei dati dei sensori IoT che misurano i cambiamenti nella temperatura di una apparecchiatura in una struttura e gli esperti di marketing online potrebbero voler analizzare i dati clickstream che mostrano come un utente naviga in un sito Web nel tempo. Poiché i dati di serie temporali vengono generati da più origini in volumi estremamente elevati, devono essere archiviati e analizzati in modo conveniente quasi in tempo reale per ricavare informazioni aziendali chiave.

Amazon Timestream offre InfluxDB completamente gestito, uno dei database di serie temporali open source più diffusi sul mercato, e LiveAnalytics, un database di serie temporali serverless creato per la scalabilità.

Sì, puoi acquistare un Savings Plans per i database per utilizzare Amazon Timestream e ridurre i costi fino al 20% se ti impegni a un utilizzo costante per un periodo di 1 anno. Ulteriori informazioni sull'utilizzo idoneo sono disponibili nella pagina dei prezzi dei Savings Plans per i database.

Puoi iniziare a utilizzare Timestream con la Console di gestione AWS, l'interfaccia della linea di comando AWS (AWS CLI) o gli SDK AWS.   Per ulteriori informazioni, inclusi tutorial e altri contenuti introduttivi, consulta la Guida per gli sviluppatori.

Amazon Timestream per InfluxDB deve essere utilizzato per casi d'uso che richiedono interrogazioni su serie temporali quasi in tempo reale e quando sono necessarie funzionalità InfluxDB o API open source. Il motore Timestream esistente, Amazon Timestream per LiveAnalytics, dovrebbe essere utilizzato quando è necessario acquisire più di decine di gigabyte di dati di serie temporali al minuto ed eseguire query SQL su terabyte di dati di serie temporali in pochi secondi.

Sì. I due motori si completano a vicenda per l'importazione di dati di serie temporali a bassa latenza e su larga scala. Puoi inserire dati in Timestream per InfluxDB e utilizzare un plug-in Telegraf per inviare dati in Timestream per l'analisi dei dati storici tramite query SQL.

Se decidi di migrare i tuoi dati Timestream per InfluxDB in Timestream per LiveAnalytics, dovrai sostenere costi di fatturazione pubblica per l'utilizzo di tale servizio, inclusi l'importazione, l'archiviazione e l'interrogazione. L'uso di Timestream per LiveAnalytics con Timestream per InfluxDB è facoltativo.

Timestream per InfluxDB può essere utilizzato separatamente o con i carichi di lavoro Timestream per LiveAnalytics. Timestream per InfluxDB è destinato ad applicazioni quasi in tempo reale con tempi di risposta in millisecondi a una cifra. Timestream per LiveAnalytics risolve i casi d'uso che richiedono l'acquisizione di gigabyte di dati in pochi minuti e l'interrogazione di terabyte di dati in pochi secondi. Puoi combinare Timestream per InfluxDB e Timestream per LiveAnalytics all'interno delle tue applicazioni o dashboard.

No. Timestream crea dinamicamente lo schema di una tabella in base a una serie di attributi e misure dimensionali. Ciò offre una definizione dello schema flessibile e incrementale che può essere modificata in qualsiasi momento senza influire sulla disponibilità.

Una volta che i database sono stati creati e resi disponibili, puoi recuperare le informazioni sugli endpoint dalla console Timestream. In alternativa, puoi anche utilizzare l'API Describe per recuperare le informazioni sugli endpoint (DescribeDatabase quando usi Timestream per LiveAnalytics e DescribeDBInstances quando usi Timestream per InfluxDB).

Puoi visualizzare i dati di serie temporali di Timestream e creare avvisi utilizzando Grafana, uno strumento di analisi e visualizzazione interattiva multipiattaforma e open source. Per saperne di più e trovare applicazioni di esempio, consulta la documentazione.

Puoi creare funzioni AWS Lambda che interagiscono con Timestream. Per informazioni più dettagliate, consulta la documentazione.

Puoi inviare i dati di serie temporali raccolti utilizzando Telegraf open source direttamente in Timestream tramite il connettore Telegraf. Per informazioni più dettagliate, consulta la documentazione.

È possibile accedere a Timestream da Amazon Virtual Private Cloud (Amazon VPC) utilizzando gli endpoint VPC. Gli endpoint Amazon VPC sono semplici da configurare e offrono connettività affidabile alle API di Timestream senza necessità di gateway Internet o istanze NAT.

AWS CloudFormation semplifica il provisioning e la gestione, fornendo modelli che permettono di eseguire in modo rapido e affidabile il provisioning dei servizi o delle applicazioni. CloudFormation fornisce un supporto completo per Timestream fornendo modelli per creare database (sia per Timestream per LiveAnalytics che per Timestream per InfluxDB). I modelli sono aggiornati con l'ultimo annuncio di Timestream per InfluxDB e offrono flessibilità e facilità d'uso ai clienti di Timestream.

Amazon Timestream per LiveAnalytics è un database di serie temporali veloce, scalabile e senza server creato per carichi di lavoro su larga scala. Poiché è serverless, aumenta o si riduce verticalmente in maniera automatica per regolare la capacità e le prestazioni, quindi non devi gestire l'infrastruttura sottostante. La sua architettura completamente disaccoppiata consente di acquisire trilioni di punti dati ed eseguire milioni di query al giorno.

Il motore di query adattivo di Timestream per LiveAnalytics ti consente di accedere ai dati recenti e storici e di analizzarli insieme senza doverne specificare la posizione. Dispone di funzioni integrate per l'analisi di serie temporali che contribuiscono all'identificazione di tendenze e modelli nei dati quasi in tempo reale.

Timestream for LiveAnalytics è progettato per raccogliere, archiviare ed elaborare dati di serie temporali. La sua architettura serverless supporta sistemi di importazione dei dati, archiviazione ed elaborazione delle query completamente disaccoppiati che possono scalare in modo indipendente, consentendo una scalabilità virtualmente infinita per le esigenze dell'applicazione. Anziché predefinire lo schema al momento della creazione della tabella, lo schema di una tabella Timestream viene creato dinamicamente in base agli attributi dei dati delle serie temporali in arrivo, consentendo una definizione dello schema flessibile e incrementale.

Per l'archiviazione dei dati, Timestream for LiveAnalytics partiziona i dati in base al tempo e agli attributi, accelerando l'accesso ai dati utilizzando un indice appositamente creato. Gli attributi dei dati, come il nome della misura o la chiave di partizionamento scelta, svolgono un ruolo fondamentale nel partizionamento efficace e nel recupero efficiente dei dati. Inoltre, Timestream per LiveAnalytics automatizza la gestione del ciclo di vita dei dati offrendo un archivio in memoria per i dati recenti e uno magnetico per i dati storici e supportando regole configurabili per spostare automaticamente i dati da un archivio all'altro quando raggiungono una certa età.

Timestream for LiveAnalytics semplifica inoltre l'accesso ai dati tramite il suo motore di query adattivo appositamente progettato, in grado di accedere e combinare facilmente i dati su più livelli di archiviazione senza dover specificare la loro posizione, in modo da poter ricavare informazioni in modo rapido e semplice utilizzando SQL. Infine, Timestream funziona perfettamente con i tuoi servizi preferiti di raccolta, visualizzazione, analisi dei dati, oltre che di machine learning (ML), semplificando l'inclusione di Timestream nelle tue soluzioni di serie temporali.

Timestream per LiveAnalytics offre una disponibilità fino al 99,99%. Per ulteriori informazioni, consulta l'Accordo sul livello di servizio (SLA).

Con Timestream per LiveAnalytics, paghi solo per quello che usi. Le scritture, i dati archiviati e i dati scansionati dalle query ti vengono fatturati separatamente. Timestream dimensiona automaticamente le scritture, lo storage e la capacità di query in base all’uso. Puoi impostare la policy di conservazione dei dati per ciascuna tabella e scegliere di archiviare i dati in un archivio in memoria o uno magnetico. Per informazioni dettagliate sui prezzi, consulta la pagina dei prezzi.

Sì, Timestream per LiveAnalytics offre una prova gratuita di un mese per tutti i nuovi account. L'utilizzo della versione di prova gratuita è limitato a 50 GB di acquisizione, 100 GB di memoria magnetica, 750 GB di memoria per ora e 750 GB di dati scansionati.

Ti verrà addebitato il prezzo standard di Timestream per LiveAnalytics per l'utilizzo oltre a quello previsto dalla prova gratuita. Ulteriori dettagli sono disponibili nella pagina dei prezzi.

Per la disponibilità della regione corrente, consulta la pagina dei prezzi.

Timestream per LiveAnalytics offre latenze quasi in tempo reale per l'importazione dei dati. L'archivio di memoria integrato di Timestream per LiveAnalytics è ottimizzato per le query point-in-time rapide, mentre l'archivio magnetico è ottimizzato per supportare query analitiche veloci. Con Timestream per LiveAnalytics, puoi eseguire query che analizzano decine di gigabyte di dati di serie temporali dall'archivio di memoria in pochi millisecondi e query analitiche che analizzano terabyte di dati di serie temporali dall'archivio magnetico in pochi secondi. Le query pianificate migliorano ulteriormente le prestazioni delle query grazie al calcolo e all'archiviazione di aggregati, al rollup e ad altre analisi in tempo reale utilizzate per alimentare pannelli di controllo operativi, report aziendali, applicazioni e sistemi di monitoraggio dei dispositivi a cui si accede di frequente.

È possibile archiviare exabyte di dati in un'unica tabella. Man mano che i dati crescono nel tempo, Timestream per LiveAnalytics utilizza la sua architettura distribuita ed enormi quantità di parallelismo per elaborare volumi di dati più grandi mantenendo pressoché invariate le latenze delle query.

L'architettura serverless di Timestream supporta sistemi di importazione di dati, archiviazione ed elaborazione delle query completamente disaccoppiati che possono scalare in modo indipendente. Timestream per LiveAnalytics monitora continuamente i requisiti delle applicazioni in termini di inserimento, archiviazione e frequenza di interrogazione per scalare istantaneamente senza tempi di inattività dell'applicazione.

Per i limiti e le quote correnti, consulta la documentazione.

Puoi raccogliere dati di serie temporali da dispositivi connessi, sistemi IT e apparecchiature industriali e scriverli in Timestream per LiveAnalytics. Puoi inviare dati a Timestream per LiveAnalytics direttamente dalla tua applicazione utilizzando gli SDK AWS o da servizi di raccolta dati come AWS IoT Core, Servizio gestito da Amazon per Apache Flink o Telegraf. Per ulteriori informazioni, consulta la relativa documentazione.

I dati di arrivo tardivo sono dati che hanno un timestamp nel passato e non rientrano nel limite di conservazione dell'archivio di memoria. I dati futuri sono invece dati con un timestamp nel futuro. Timestream consente di archiviare e accedere a entrambi i tipi di dati.

Per archiviare i dati in ritardo, è sufficiente scriverli in Amazon Timestream per LiveAnalytics e il servizio determinerà automaticamente se verranno scritti nell'archivio di memoria o in quello magnetico, in base al timestamp e alla conservazione dei dati configurata per la memoria e gli archivi magnetici. Per archiviare dati con un ritardo di oltre 15 minuti, modella i dati come un record con più misure e rappresenta il timestamp futuro come una misura all'interno del record.

Utilizzando il caricamento in batch, puoi importare i file CSV archiviati in Amazon Simple Storage Service (Amazon S3) in Timestream per LiveAnalytics. È possibile utilizzare il caricamento in batch per il backfill dei dati che non sono immediatamente necessari per l'analisi. Puoi creare attività di caricamento in batch utilizzando la Console di gestione AWS, AWS CLI e gli SDK AWS. Per ulteriori informazioni, consulta la relativa documentazione.

Puoi raccogliere dati dai tuoi dispositivi IoT e archiviarli in Timestream per LiveAnalytics utilizzando le azioni delle regole di AWS IoT Core. Per informazioni più dettagliate, consulta la documentazione.

Puoi utilizzare Apache Flink per trasferire i dati di serie temporali da Amazon Kinesis direttamente a Timestream per LiveAnalytics. Per informazioni più dettagliate, consulta la documentazione.

Puoi utilizzare Apache Flink per inviare i dati delle serie temporali da Streaming gestito da Amazon per Apache Kafka (Amazon MSK) direttamente a Timestream per LiveAnalytics. Per informazioni più dettagliate, consulta la documentazione.

Timestream organizza e archivia i dati di serie temporali in partizioni. Il partizionamento dei dati è determinato dal servizio in base agli attributi dei dati. Attributi come timestamp e measure name o chiavi di partizione definite dal cliente svolgono un ruolo chiave nella decisione delle partizioni. Per ulteriori dettagli, consulta il blog di Werner Vogel. Se desideri ottimizzare le prestazioni delle query per soddisfare meglio le tue esigenze specifiche, ti consigliamo di utilizzare chiavi di partizione definite dal cliente. Utilizzando Timestream, puoi automatizzare la gestione del ciclo di vita dei dati semplicemente configurando le policy di conservazione dei dati per spostare automaticamente i dati dall'archivio di memoria a quello magnetico quando raggiungono l'età configurata.

L'archivio di memoria di Timestream per LiveAnalytics è un archivio ottimizzato per la scrittura che accetta e deduplica i dati di serie temporali in entrata, Inoltre, l'archivio di memoria è ottimizzato per le query point-in-time sensibili alla latenza.

L'archivio magnetico di Timestream per LiveAnalytics è un archivio ottimizzato per la lettura creato per eseguire query di analisi veloci in grado di scansionare centinaia di terabyte di dati. L'archivio magnetico è inoltre ottimizzato per query analitiche veloci che scansionano centinaia di terabyte di dati.

È possibile impostare il periodo di conservazione sia per l'archivio di memoria che per l'archivio magnetico. I valori predefiniti sono rispettivamente 12 ore e 10 anni. Poiché l'età dei dati, determinata dal timestamp nel record, supera il periodo di conservazione configurato dell'archivio di memoria, Timestream per LiveAnalytics suddivide automaticamente i dati nell'archivio magnetico. Allo stesso modo, se l'età dei dati supera il periodo di conservazione dell'archivio magnetico configurato, il servizio elimina automaticamente i dati.

Timestream per LiveAnalytics garantisce la durabilità dei dati replicando automaticamente i dati della memoria e dell'archivio magnetico in diverse zone di disponibilità all'interno di una singola regione. Tutti i dati vengono scritti su disco prima di confermare la richiesta di scrittura come completa.

Puoi utilizzare SQL per interrogare i dati di serie temporali archiviati in Timestream. È inoltre possibile eseguire funzioni di analisi delle serie temporali per l'interpolazione, la regressione e il livellamento tramite SQL. Per ulteriori informazioni, consulta la relativa documentazione. Il motore di query adattivo di Timestream consente di accedere ai dati su più livelli di archiviazione utilizzando una singola istruzione SQL. Accede e combina in modo trasparente i dati tra i livelli di archiviazione senza richiedere di specificare la posizione dei dati. 

Le query pianificate di Timestream per LiveAnalytics offrono una soluzione completamente gestita, serverless e dimensionabile per il calcolo e l'archiviazione di aggregati, rollup e altre analisi in tempo reale utilizzati per potenziare dashboard operative, report aziendali, applicazioni e sistemi di monitoraggio dei dispositivi a cui si accede di frequente.

Con le query pianificate, è sufficiente definire le query di analisi in tempo reale che calcolano aggregati, rollup e altre analisi in tempo reale sui dati in entrata e Timestream esegue periodicamente e automaticamente queste query, scrivendo in modo affidabile i risultati in una tabella separata. Quindi, puoi indirizzare i pannelli di controllo, i report, le applicazioni e i sistemi di monitoraggio in modo che eseguano semplicemente query sulle tabelle di destinazione anziché su quelle di origine notevolmente più grandi contenenti i dati di serie temporali in entrata. Ciò porta a riduzioni delle prestazioni e dei costi di un ordine di grandezza perché le tabelle di destinazione contengono molti meno dati rispetto alle tabelle di origine, offrendo così un accesso e un'archiviazione dei dati più rapidi ed economici.

Puoi utilizzare i driver JDBC e ODBC per connettere Timestream for LiveAnalytics ai tuoi strumenti di business intelligence e ad altre applicazioni preferiti. Consulta la documentazione relativa a JDBC e ODBC per ulteriori dettagli.

Puoi visualizzare e analizzare i dati di serie temporali in Timestream per LiveAnalytics utilizzando Amazon QuickSight e Grafana. Puoi anche usare QuickSight per le tue esigenze di ML.

È possibile creare dashboard ricche e interattive per i dati di serie temporali utilizzando QuickSight. Per ulteriori informazioni, consulta la relativa documentazione.

Puoi utilizzare i notebook Amazon SageMaker per integrare i tuoi modelli ML con Timestream for LiveAnalytics. Per ulteriori informazioni, consulta la relativa documentazione.

I dati sono sempre crittografati sia a riposo che in transito. Timestream per LiveAnalytics consente di specificare una chiave gestita dal cliente del Servizio AWS di gestione delle chiavi (AWS KMS) per crittografare i dati nell'archivio magnetico.

Timestream per LiveAnalytics è conforme a ISO (9001, 27001, 27017 e 27018), PCI DSS, FedRAMP (Moderate) e Health Information Trust (HITRUST) Alliance Common Security Framework (CSF). È inoltre idoneo all'HIPAA e rientra nell'ambito dei report AWS SOC 1, SOC 2 e SOC 3.

Sono disponibili due opzioni di backup per le risorse Timestream: on demand e pianificati. I backup on demand sono backup una tantum che possono essere avviati dalla console Timestream o utilizzando AWS Backup. Sono utili quando si desidera creare un backup prima di apportare una modifica della tabella che potrebbe richiedere l'annullamento delle modifiche. I backup pianificati sono backup ricorrenti che puoi configurare, utilizzando le policy di AWS Backup, alla frequenza desiderata (ad esempio 12 ore, 1 giorno, 1 settimana e così via). Sono utili quando si desidera creare backup continui per raggiungere gli obiettivi di protezione dei dati.

Il primo backup, on demand o pianificato, della tabella è un backup completo, mentre ogni backup successivo della stessa tabella è incrementale e copia solo i dati che sono cambiati dall'ultimo backup. 

I costi di backup e ripristino vengono addebitati in base alla dimensione dell'archiviazione di backup della tabella selezionata, misurata in GB al mese. I costi saranno indicati nella sezione "Backup" della fattura AWS e includono i costi per l'archiviazione di backup, i trasferimenti di dati, i ripristini e le eliminazioni anticipate. Poiché i backup sono di natura incrementale, la dimensione dell'archiviazione del backup successivo della tabella corrisponde alla dimensione della quantità di dati modificata dall'ultimo backup. Per ulteriori dettagli, consulta i prezzi di AWS Backup.

Per prima cosa, devi abilitare AWS Backup per proteggere le risorse Timestream per LiveAnalytics (si tratta di un'azione una tantum). Una volta abilitato, accedi alla Console di gestione AWS o usa la CLI o l'SDK di AWS Backup per creare backup su richiesta o pianificati dei tuoi dati e copiarli tra account e regioni. È possibile configurare la gestione del ciclo di vita del backup in base alle esigenze di protezione dei dati. Per ulteriori informazioni, consulta la nostra documentazione relativa alla creazione di un backup. 

Puoi ripristinare le tabelle di Timestream per LiveAnalytics tramite la Console di gestione AWS o utilizzando l'interfaccia a riga di comando o l'SDK di AWS Backup. Seleziona l'ID del punto di ripristino per la risorsa che desideri ripristinare e fornisci gli input richiesti, come il nome del database di destinazione, il nuovo nome della tabella e le proprietà di conservazione, per avviare il processo di ripristino. In caso di ripristino riuscito, puoi accedere ai dati. Quando provi a ripristinare l'ultimo backup incrementale della tabella, vengono ripristinati tutti i dati della tabella. Per ulteriori informazioni, consulta la documentazione.

Amazon Timestream per InfluxDB è un nuovo motore di database di serie temporali che consente agli sviluppatori di applicazioni e ai team DevOps di eseguire facilmente database InfluxDB su AWS per applicazioni di serie temporali in tempo reale utilizzando API open source. Con Timestream per InfluxDB, è facile configurare, utilizzare e scalare carichi di lavoro di serie temporali in grado di rispondere alle domande con risposte a query in millisecondi a una cifra.

Timestream per InfluxDB supporta la versione open source 2.7 di InfluxDB. 

Dovresti usare Timestream per InfluxDB se gestisci autonomamente InfluxDB, desideri utilizzare API di serie temporali open source o stai creando applicazioni per serie temporali in tempo reale che richiedono risposte a query in millisecondi a una cifra. Con Timestream per InfluxDB, ottieni il vantaggio delle API open source e di un'ampia gamma di agenti Telegraf open source per raccogliere dati di serie temporali. Non è necessario gestire attività complesse e dispendiose in termini di tempo, come l'installazione di InfluxDB, gli aggiornamenti, l'archiviazione, la replica per l'alta disponibilità e i backup.

Timestream per InfluxDB fornisce uno SLA del 99,9% di disponibilità se implementato con una configurazione multi-AZ e una disponibilità del 99,5% per una configurazione single-AZ.

Timestream per InfluxDB è progettato per casi d'uso di serie temporali quasi in tempo reale. A seconda delle configurazioni delle istanze e delle caratteristiche dei carichi di lavoro, puoi aspettarti una latenza da scrittura a lettura di circa 1 secondo con una latenza delle query di millisecondi a una cifra.

Per migrare a Timestream per InfluxDB da un'istanza InfluxDB autogestita, puoi semplicemente ripristinare un backup da un database InfluxDB esistente in un'istanza Timestream per InfluxDB con alcuni minuti di inattività. Puoi riconfigurare i tuoi agenti di raccolta dati, come gli agenti Telegraf open source, per indirizzare l'endpoint InfluxDB gestito da Timestream per InfluxDB. Le tecnologie di dashboard, come l'interfaccia utente InfluxDB, Grafana self-hosted o Grafana gestito da Amazon, continueranno a funzionare configurandole per utilizzare l'endpoint Timestream per InfluxDB senza altre modifiche al codice.

Per migrare da Timestream per LiveAnalytics a Timestream per InfluxDB, puoi esportare i tuoi dati da Timestream per LiveAnalytics ad Amazon S3, apportare le modifiche necessarie ai file CSV esportati e caricarli in Timestream per InfluxDB.

Un'istanza database può essere considerata come un ambiente di database nel cloud con le risorse di calcolo e di archiviazione specificate dall'utente. Puoi creare ed eliminare istanze DB, definire e perfezionare gli attributi dell'infrastruttura delle tue istanze DB e controllare l'accesso e la sicurezza tramite la Console di gestione AWS, le API di Timestream for InfluxDB e AWS CLI. È possibile eseguire una o più istanze DB e ciascuna istanza DB può supportare uno o più database (bucket) o organizzazioni, a seconda delle caratteristiche del carico di lavoro e della configurazione dell'istanza.

Le istanze DB sono semplici da creare utilizzando la Console di gestione AWS, le API Timestream per InfluxDB o l'interfaccia a riga di comando AWS. Per avviare un'istanza DB utilizzando la Console di gestione AWS, scegli Database InfluxDB e quindi seleziona il pulsante Crea database InfluxDB nella dashboard. Da lì, puoi specificare i parametri per la tua istanza DB, tra cui il tipo di istanza, il tipo e la quantità di archiviazione, le credenziali dell'utente principale e altro ancora.

In alternativa, puoi creare la tua istanza database utilizzando l'API CreateDBInstance o il comando create-db-instance.

Una volta che l'istanza DB è disponibile, puoi recuperarne l'endpoint tramite la descrizione dell'istanza DB nella Console di gestione AWS, nell'API GetDBInstance o con il comando get-db-instance. Utilizzando questo endpoint più il token di accesso, puoi utilizzare le API InfluxDB per inviare richieste di scrittura e lettura e gestire il motore utilizzando il tuo strumento di database o linguaggio di programmazione preferito. Puoi anche accedere all'interfaccia utente di InfluxDB dal tuo browser utilizzando lo stesso endpoint. Per consentire richieste di rete all'istanza DB in esecuzione, dovrai autorizzare l'accesso o abilitare l'accesso IP pubblico.

Per impostazione predefinita, puoi avere fino a un totale di 40 istanze Timestream per InfluxDB.

Paghi solo quello che utilizzi e non ci sono tariffe minime né commissioni di installazione. Il tuo utilizzo viene fatturato in base a quanto segue:

• Ore istanza DB: in base alla classe (ad esempio, db.influx.large e db.influx.4xlarge) dell'istanza DB utilizzata. Le ore di utilizzo parziale dell'istanza DB sono fatturate in incrementi di un secondo con una tariffa minima di 10 minuti derivante da un'operazione di modifica dello stato fatturabile, come la creazione, l'avvio o la modifica della classe di istanza DB.
• Archiviazione (per GB al mese): capacità di archiviazione assegnata all'istanza DB. Scalando la capacità di archiviazione assegnata nel corso del mese, l'addebito sarà ripartito proporzionalmente.
• Trasferimento dati: trasferimento dati via Internet in entrata e in uscita dall'istanza DB.

Per informazioni sui prezzi di Timestream per InfluxDB, visita la pagina dei prezzi.

La fatturazione di un'istanza DB inizia appena l'istanza è disponibile. La fatturazione continua finché l'istanza DB non viene arrestata, a seguito della sua eliminazione o in caso di malfunzionamento dell'istanza.

Le ore istanza database vengono fatturate per ogni ora in cui l'istanza database è in esecuzione in stato disponibile. Se non desideri più ricevere addebiti per la tua istanza DB, dovrai interromperla o eliminarla per evitare che vengano fatturate altre ore associate all'istanza. Le ore di utilizzo parziale dell'istanza DB sono fatturate in incrementi di un secondo con una tariffa minima di 10 minuti derivante da un'operazione di modifica dello stato fatturabile, come la creazione, l'avvio o la modifica della classe di istanza DB.

Mentre l'istanza del database è arrestata, ti verrà addebitato l'archiviazione fornita ma non le ore di utilizzo dell'istanza del database.

Se specifichi che la tua istanza database dev'essere un'implementazione multi-AZ, la fatturazione avverrà in base ai prezzi delle implementazioni multi-AZ, pubblicati nella pagina dei prezzi Timestream per InfluxDB. La fatturazione multi-AZ si basa su quanto segue:

• Ore istanza DB multi-AZ: in base alla classe (ad esempio, db.influx.large e db.influx.4xlarge) dell'istanza DB utilizzata. Come per le implementazioni standard in un’unica zona di disponibilità, le ore di utilizzo parziale dell'istanza database sono fatturate in incrementi di un secondo con una tariffa minima di 10 minuti derivante da un'operazione di modifica dello stato fatturabile quali la creazione, l'avvio o la modifica della classe di istanza database. Se converti l'implementazione dell'istanza database tra standard e multi-AZ in una determinata ora, ti verranno addebitate entrambe le tariffe in vigore per quell'ora.
• Spazio di archiviazione assegnato (per istanza database multi-AZ): se converti l'implementazione dell'istanza tra standard e multi-AZ in una determinata ora, ti verrà addebitata la più alta delle tariffe di archiviazione in vigore per quell'ora.
• Trasferimento dei dati: il trasferimento di dati che avviene nel replicare i dati tra l'istanza principale e quella di standby non sarà fatturato. Il trasferimento dei dati via Internet, in entrata e in uscita dalla tua istanza database, viene fatturato allo stesso modo di un'implementazione standard.

Salvo diversamente specificato, i prezzi sono al netto di eventuali tasse e imposte doganali, inclusa l'IVA ed eventuali imposte sulle vendite. Per i clienti con indirizzo di fatturazione in Giappone, l'utilizzo dei servizi AWS è soggetto all'imposta sul consumo giapponese. 

• La fattura del cluster della replica di lettura di Timestream per InfluxDB viene calcolata per istanza all'interno del cluster, in base ai prezzi elencati nella pagina dei prezzi di Timestream per InfluxDB. La struttura di fatturazione è composta da quattro componenti principali:
  Le ore dei nodi del cluster vengono addebitate in base alla classe di istanza selezionata (ad esempio db.influx.large o db.influx.4xlarge). Fatturiamo in incrementi di 1 secondo con un addebito minimo di 10 minuti a seguito di qualsiasi modifica dello stato fatturabile, comprese le modifiche alla creazione, all'avvio o alla classe di istanza. Se effettui la conversione tra tipi di cluster entro un'ora, ti verranno addebitate entrambe le tariffe applicabili durante quel periodo.
• Per l'archiviazione, la fatturazione avverrà in base alla capacità assegnata. Quando effettuiamo la conversione tra tipi di distribuzione (cluster, standard o DB multi-AZ) entro un'ora, applichiamo la più alta tra le tariffe di archiviazione applicabili per quell'ora.
• Per quanto riguarda il trasferimento dei dati, non verranno addebitati costi per la replica dei dati tra le istanze primarie e di replica. Tuttavia, il trasferimento di dati via Internet in entrata e in uscita dal cluster DB segue lo stesso prezzo delle implementazioni standard.
• La funzionalità di replica di lettura viene fornita tramite un componente aggiuntivo con licenza creato e venduto da InfluxData e che verrà attivato tramite AWS Marketplace. Questa licenza funziona su un modello con pagamento in base al consumo, con costi basati sulle ore dell'istanza in base al numero di vCPU nella classe di istanza configurata.
  

Per selezionare la classe dell'istanza database e la capacità di archiviazione iniziali, è opportuno valutare le esigenze di calcolo, memoria e archiviazione della tua applicazione. Per informazioni sulle classi di istanze DB disponibili, consulta la Guida per l'utente di Timestream per InfluxDB.

L'archiviazione inclusa IOPS di Timestream per InfluxDB è un'opzione di archiviazione con volumi SSD creata per offrire prestazioni I/O elevate, prevedibili e costanti. Con l’archiviazione inclusa IOPS di Timestream per InfluxDB, hai tre livelli tra cui scegliere, che vanno dai piccoli carichi di lavoro a quelli su larga scala e ottimizzati ad alte prestazioni. Specifichi solo la dimensione del volume allocato per il livello che meglio si adatta alle tue esigenze. L’archiviazione inclusa IOPS di Timestream per InfluxDB è ottimizzato per carichi di lavoro di database transazionali (OLTP) ad alta intensità di I/O. Per maggiori dettagli, consulta la Guida per l'utente di Timestream for InfluxDB.

Consigliamo di scegliere il tipo di archiviazione più adatto al tuo carico di lavoro.

• Carichi di lavoro OLTP ad alte prestazioni: Timestream per InfluxDB IOPS include l'archiviazione.

Per impostazione predefinita, Timestream for InfluxDB seleziona i parametri di configurazione ottimali per l'istanza DB in base alla classe di istanze e alla capacità di archiviazione. Tuttavia, se desideri modificarli, puoi farlo utilizzando la Console di gestione AWS, le API Timestream per InfluxDB o l'interfaccia a riga di comando AWS. Si noti che la modifica dei parametri di configurazione rispetto ai valori raccomandati può provocare effetti inattesi che possono andare da un calo delle prestazioni a crash di sistema, e dovrebbe essere effettuata solo da utenti esperti che conoscono i rischi che ne derivano.

Al momento del lancio, forniremo un set limitato di parametri che potranno essere modificati dall'utente, tra cui: flux-log-enabled, log-level, metrics-disable, no-tasks, query-concurrency, query-queue-size e tracing-type. Questo elenco potrebbe crescere nel tempo in base alle esigenze dei clienti.

Un gruppo di parametri si comporta come un container per i valori di configurazione dei motori che sono applicati a una o più istanze DB. Se decidi di creare un'istanza DB senza specificare un gruppo di parametri di database, ne viene utilizzato uno predefinito. Questo gruppo predefinito contiene le impostazioni predefinite del motore e le impostazioni predefinite del sistema Timestream per InfluxDB ottimizzate per l'istanza DB in esecuzione.

Se tuttavia desideri eseguire l'istanza con i valori di configurazione del motore personalizzati, puoi creare un nuovo gruppo di parametri di database, apportare le modifiche desiderate ai parametri e impostare l'istanza DB in modo che applichi il nuovo gruppo di parametri di database. 

Quando crei o modifichi un'istanza DB per eseguirla come implementazione multi-AZ, Timestream per InfluxDB effettua automaticamente il provisioning di una replica sincrona in standby, conservandola in una zona di disponibilità differente. Gli aggiornamenti all'istanza DB vengono replicati in modo sincrono sulla copia in standby tra le varie zone di disponibilità, per mantenere entrambe le istanze sincronizzate e proteggere gli aggiornamenti più recenti del database da eventuali errori dell'istanza DB. 

Durante determinati tipi di finestra di manutenzione, oppure nell'eventualità di un errore dell'istanza DB o della zona di disponibilità, Timestream per InfluxDB esegue automaticamente il failover sulla copia di standby per consentire di ripristinare le operazioni di lettura e scrittura del database non appena la copia di standby viene attivata. Poiché il registro di nome dell'istanza database rimane invariato, l'applicazione potrà ripristinare l'operatività sul database senza la necessità di interventi manuali a livello amministrativo.

Con le implementazioni multi-AZ le repliche sono trasparenti. Non è necessario interagire direttamente con la copia di standby, né questa può essere utilizzata per il traffico in lettura.

Le zone di disponibilità sono percorsi separati all'interno di una regione, isolati dai potenziali errori di altre zone di disponibilità. Ciascuna zona di disponibilità gestisce un'infrastruttura fisica propria, distinta e indipendente ed è progettata in modo da essere altamente affidabile. Macchinari e attrezzature facilmente soggetti a guasto, come generatori e apparecchiature di raffreddamento, non sono condivisi tra le zone di disponibilità. Inoltre, sono fisicamente separate, in modo tale che anche eventi estremi molto rari, come incendi, trombe d'aria o inondazioni, colpirebbero una sola zona di disponibilità. Le zone di disponibilità all'interno della stessa Regione dispongono di connettività a latenza molto ridotta.

Quando esegui un'istanza database come implementazione multi-AZ, l'istanza "primaria" gestisce le attività in lettura e scrittura del database. Inoltre, Timestream per InfluxDB crea e conserva una replica di standby, che è una replica aggiornata di quella primaria. In caso di failover, la replica di standby viene "promossa". Dopo il failover, l'istanza di standby diventa infatti l'istanza principale e accetta le operazioni del database. Prima di questa promozione, non avrai alcuna interazione con la copia di standby (ad esempio, per le operazioni in lettura).

Il principale vantaggio dell'esecuzione di un'istanza DB come implementazione multi-AZ è il miglioramento di durabilità e disponibilità del database. La disponibilità e la tolleranza ai guasti offerte dalle implementazioni Multi-AZ ne fanno una soluzione ideale per gli ambienti di produzione.

L'esecuzione di un'istanza DB come implementazione multi-AZ consente di proteggere i dati nell'eventualità di un errore di un componente o di un calo della disponibilità in una zona di disponibilità.

Se ad esempio si verifica un errore in un volume di storage sull'istanza primaria, Timestream per InfluxDB avvia automaticamente un failover sull'istanza di standby, dove gli aggiornamenti del database sono ancora intatti. In questo modo è possibile migliorare la durabilità dei dati delle distribuzioni standard in una singola zona di disponibilità, per le quali le operazioni di ripristino devono essere avviate manualmente e gli aggiornamenti applicati dopo l'ultimo punto di ripristino (in genere per un intervallo di tempo di cinque minuti) non sono disponibili.

Quando un'istanza DB viene eseguita come implementazione multi-AZ, risulta migliorata anche la disponibilità del database. Se si verifica un errore nella zona di disponibilità o nell'istanza DB, le conseguenze sulla disponibilità si restringono all'intervallo di tempo necessario per il completamento del failover automatico. I vantaggi della disponibilità del multi-AZ estendono anche gli interventi di manutenzione programmati. Un altro vantaggio implicito dell'esecuzione di un'istanza DB come implementazione multi-AZ è che il failover è automatico e non richiede alcun intervento a livello amministrativo. 

In una implementazione standard dell'istanza database in una zona di disponibilità singola, è possibile che venga rilevato un aumento della latenza causata dalla replica sincrona dei dati.

No, la replica di standby multi-AZ non può essere utilizzata per le richieste in lettura. Le implementazioni Multi-AZ sono state progettate per fornire maggiori disponibilità e durabilità, più che per migliorare il dimensionamento in lettura. Per questo motivo impiegano la replica sincrona tra l'istanza principale e quella di standby. Nelle nostre implementazioni la copia principale e quella di stand-by sono costantemente sincronizzate, ma l'istanza di stand-by non può essere utilizzata per eseguire operazioni di lettura o scrittura.

Per creare un'implementazione multi-AZ di un'istanza database, è sufficiente scegliere l’opzione Crea un'istanza standby per l’implementazione multi-AZ all'avvio di un'istanza database con la Console di gestione AWS. In alternativa, se desideri usare le API di Timestream per InfluxDB, puoi richiamare l'API CreateDBInstance e impostare il parametro Multi-AZ sul valore "true".
Puoi anche modificare una delle tue istanze esistenti e impostare il tipo di implementazione su multi-AZ.

Timestream per InfluxDB riconosce gli scenari di errore più comuni delle implementazioni multi-AZ e avvia automaticamente il ripristino, consentendoti di riprendere l'operatività del database con la massima rapidità senza alcun intervento manuale a livello amministrativo. Timestream per InfluxDB esegue automaticamente un failover in caso di una delle seguenti situazioni:

• Calo di disponibilità nella zona di disponibilità principale
• Perdita di connettività di rete nell'istanza principale
• Errore dell'unità di elaborazione nell'istanza principale
• Errore di archiviazione nell'istanza principale

Nota: le implementazioni multi-AZ di Timestream per InfluxDB non effettuano automaticamente il failover in caso di operazioni del database quali query che richiedono tempi di elaborazione particolarmente lunghi, blocchi critici o errori di danneggiamento del database.

Il failover viene gestito automaticamente da Timestream per InfluxDB, consentendoti di riprendere l'operatività del database con la massima rapidità senza alcun intervento manuale a livello amministrativo. Durante l'esecuzione di un failover, Timestream per InfluxDB cambia il record di nome (CNAME) dell'istanza DB in modo che punti alla copia di standby, che diventa quindi la nuova primaria. Ti consigliamo di seguire le opportune best practice e di implementare tentativi multipli di connessione al database a livello di applicazione.

Un failover si definisce come l'intervallo di tempo compreso tra il rilevamento di un errore sull'istanza primaria e la ripresa delle transazioni sull'istanza di standby, e in genere viene completato in un paio di minuti. Il tempo di failover può anche essere influenzato dalla necessità di ripristinare transazioni di grandi dimensioni e non impegnate, dalla dimensione dell'indice e da altri fattori. L'uso di tipi di istanze sufficientemente grandi è consigliato con multi-AZ per ottenere i migliori risultati. AWS consiglia inoltre l'uso dell’archiviazione inclusa IOPS di Timestream per InfluxDB con istanze multi-AZ per prestazioni di throughput veloci, prevedibili e coerenti.

Timestream for InfluxDB effettua automaticamente il failover senza alcun intervento manuale nel caso si verifichino determinate condizioni di errore. Al momento, non puoi avviare manualmente un failover forzato dell'istanza DB di Timestream per InfluxDB.

Con le implementazioni multi-AZ, è sufficiente impostare il parametro "multi-AZ" su "true". La creazione della copia di standby, la replica sincrona e il failover vengono gestiti automaticamente. Questo significa che non è possibile selezionare la zona di disponibilità in cui distribuire l'istanza di standby, né modificare il numero di copie di standby disponibili (Timestream per InfluxDB fornisce una copia di standby dedicata per ogni istanza DB principale). L'istanza di standby, inoltre, non può essere configurata in modo da accettare attività in lettura.

Sì, l'istanza di standby viene automaticamente assegnata in una zona di disponibilità differente della stessa Regione dell’istanza database principale.

Sì. Per conoscere il percorso dell'istanza principale, usa la Console di gestione AWS o l'API GetDBInstance.

Le zone di disponibilità sono state progettate in modo da connettersi tra loro in rete con una latenza minima, quando si trovano in una stessa regione. Potrebbe essere opportuno progettare la propria applicazione e organizzare le altre risorse AWS in modo che offrano ridondanza su più zone di disponibilità, consentendo una maggiore resistenza all'applicazione in caso di errore in una zona. A questo scopo è possibile utilizzare le implementazioni multi-AZ, che soddisfano questa esigenza a livello di database senza alcun intervento manuale a livello amministrativo.

Un cluster della replica di lettura di Timestream per InfluxDB offre una maggiore disponibilità e scalabilità di lettura per il database. Quando si crea un cluster, Timestream per InfluxDB esegue automaticamente il provisioning e mantiene almeno una replica leggibile asincrona in una zona di disponibilità diversa. Gli aggiornamenti del nodo primario vengono replicati in modo asincrono su queste repliche di lettura, consentendoti di distribuire il carico di lavoro delle query su più nodi.

Il cluster supporta il failover automatico durante la manutenzione pianificata o nell'improbabile caso di errore di un nodo o di una zona di disponibilità. Quando si verifica il failover, le applicazioni possono continuare a funzionare senza intervento manuale poiché gli endpoint di scrittura e lettura conservano i record con lo stesso nome. Tuttavia, è importante notare che durante il periodo di ripristino, mentre ripristiniamo il nodo guasto e lo ripristiniamo come replica di lettura, le applicazioni che utilizzano gli endpoint del nodo di replica per la lettura non saranno temporaneamente disponibili.

In un cluster della replica di lettura, il nodo primario gestisce tutte le scritture, le letture e gestisce le configurazioni e le funzioni amministrative specifiche del motore. Inoltre, Timestream per InfluxDB fornisce e mantiene automaticamente una replica di lettura che rimane aggiornata con il nodo primario. La replica di lettura ha due scopi principali: estende la capacità di lettura accettando richieste di lettura aggiuntive e può essere promossa a primaria durante gli scenari di failover. Durante un evento di failover, quando la replica di lettura viene promossa a primaria, assume il controllo di tutte le operazioni del database. Una volta che il nodo precedentemente guasto torna operativo, si ricongiunge al cluster come replica di lettura, mantenendo la resilienza del cluster.

I cluster della replica di lettura offrono tre principali vantaggi: maggiore scalabilità, maggiore disponibilità e ottimizzazione del carico di lavoro. La maggiore scalabilità deriva dalla capacità di distribuire i carichi di lavoro di lettura su più nodi del cluster, rendendola particolarmente utile per le applicazioni in cui i requisiti di lettura superano significativamente le operazioni di scrittura.

Se configurati con il failover abilitato, i cluster della replica di lettura offrono una maggiore disponibilità grazie a funzionalità di failover più rapide. Poiché tutti i nodi del cluster rimangono attivi, è possibile promuovere una replica a primaria senza attendere l'avvio del nodo, riducendo al minimo i tempi di inattività durante gli scenari di failover.

Inoltre, i cluster della replica di lettura consentono una gestione efficiente dei carichi di lavoro. Puoi dedicare il tuo nodo principale alla gestione di query semplici e veloci in genere utilizzate per dashboard, allarmi e notifiche in tempo reale, indirizzando al contempo le query analitiche più complesse alle tue repliche di lettura. Questa separazione garantisce prestazioni ottimali per diversi tipi di carichi di lavoro.

Il processo di replica ha dimostrato un impatto trascurabile sulle prestazioni, con un effetto minimo sul consumo di CPU o memoria. Tuttavia, è importante notare che il ritardo di replica, il tempo che intercorre tra il momento in cui un record viene accettato nella replica primaria e il momento in cui diventa disponibile nelle repliche di lettura, può variare a seconda del livello di carico dei nodi di replica.

Timestream per InfluxDB pubblica una metrica CloudWatch chiamata "ReplicaLag" che ti aiuta a monitorare lo stato di sincronizzazione delle tue repliche di lettura. Questa metrica, misurata in millisecondi, tiene traccia della distanza delle repliche dal nodo primario. La latenza delle repliche può essere influenzata dai livelli di carico del database, pertanto consigliamo ai clienti di monitorare attivamente questa metrica per garantire che le repliche di lettura mantengano livelli di sincronizzazione accettabili per il loro caso d'uso.

Per configurare un cluster della replica di lettura in Timestream per InfluxDB, inizia accedendo alla Console di gestione AWS e passa alla console Amazon Timestream. Scegli "Crea database InfluxDB" dalla sezione Database InfluxDB. Quando si configurano le impostazioni di implementazione, seleziona "Cluster DB con repliche di lettura". Dovrai attivare un abbonamento tramite AWS Marketplace, che richiede le autorizzazioni AWSMarketplaceManageSubscriptions o AWSMarketplaceFullAccess. Dopo aver confermato l'abbonamento, fornisci i dettagli di configurazione di base e seleziona i nodi e le classi di archiviazione appropriati che verranno applicati a tutti i nodi del cluster.

No, in un cluster della replica di lettura, può esserci un solo nodo primario che gestisce le operazioni di scrittura in un dato momento. Il nodo primario gestisce tutte le richieste di scrittura insieme alle letture del database, le configurazioni specifiche del motore e le funzioni amministrative. Le repliche di lettura vengono mantenute aggiornate con questo nodo primario e possono accettare solo richieste di lettura. Sebbene sia possibile promuovere una replica di lettura affinché diventi la principale durante gli scenari di failover, l'architettura del cluster mantiene un modello a scrittore singolo per garantire la coerenza dei dati.

Per i cluster della replica di lettura, è possibile abilitare o disabilitare la funzionalità di failover durante la creazione o la modifica del cluster. Se abilitata, la gestione delle repliche, il processo di replica e i processi di failover sono gestiti automaticamente da Timestream per InfluxDB. Non puoi selezionare zone di disponibilità specifiche per le tue repliche e Timestream per InfluxDB mantiene almeno una replica di lettura per cluster. Le repliche di lettura accettano attivamente le richieste di lettura per aiutarti a distribuire il carico di lavoro.

Timestream per InfluxDB rileva e ripristina automaticamente gli scenari di errore comuni nelle implementazioni del cluster della replica di lettura, consentendo di riprendere rapidamente le operazioni del database senza interventi amministrativi. Il sistema esegue automaticamente un failover su una replica di lettura in caso di una delle seguenti situazioni:

• Perdita di disponibilità nella zona di disponibilità del nodo primario
• Perdita della connettività di rete verso il nodo primario
• Guasto dell'unità di calcolo sul nodo primario
• Errore di archiviazione sul nodo primario

Nota: i cluster della replica di lettura Timestream per InfluxDB non vengono eseguiti automaticamente il failover in risposta alle operazioni del database, come query di lunga durata, deadlock o errori di danneggiamento del database. Ricorda che il failover automatico si verificherà solo se hai abilitato specificamente questa funzionalità per il tuo cluster della replica di lettura durante la configurazione o tramite la modifica del cluster.

Il failover in un cluster della replica di lettura viene gestito automaticamente da Timestream per InfluxDB quando la funzionalità è abilitata, consentendo la ripresa rapida delle operazioni del database senza interventi amministrativi. Durante il failover, Timestream per InfluxDB aggiorna il record del nome canonico (CNAME) del database in modo che punti alla replica di lettura, che viene quindi promossa a diventare la nuova replica primaria. Si consiglia di implementare la logica di ripetizione della connessione al database nel livello dell'applicazione come best practice.

Poiché i nodi di un cluster della replica di lettura sono attivi, il tempo di failover sarà stabile indipendentemente dalle caratteristiche del carico di lavoro. In genere, i failover vengono completati in pochi minuti, misurati dal rilevamento dell'errore principale alla ripresa delle transazioni sulla replica promossa. Per prestazioni ottimali, consigliamo di utilizzare tipi di nodi e archiviazione inclusa IOPS di Timestream per InfluxDB.

Quando il failover è abilitato, Timestream per InfluxDB gestirà automaticamente il failover in varie condizioni di errore. Attualmente, l'avvio manuale del failover forzato non è supportato per i cluster della replica di lettura di Timestream per InfluxDB.

Sì, la replica di lettura viene automaticamente assegnata in una zona di disponibilità differente della stessa regione del nodo primario.

Sì, puoi visualizzare la posizione del nodo primario e del nodo della replica di lettura tramite la Console di gestione AWS o utilizzando l'API GetDBInstance.

Le zone di disponibilità sono state progettate in modo da connettersi tra loro in rete con una latenza minima, quando si trovano in una stessa regione, pertanto l'impatto della latenza dovrebbe essere minimo. Tuttavia, consigliamo di progettare l'applicazione e le altre risorse AWS con ridondanza su più zone di disponibilità per la massima resilienza. I cluster di replica di lettura supportano questa architettura in modo naturale, poiché è possibile distribuire i carichi di lavoro di lettura tra nodi in diverse zone di disponibilità e, quando il failover è abilitato, l'applicazione può continuare a funzionare anche se una zona di disponibilità non è disponibile.