Sistema di archiviazione altamente concorrente

Immagina che il tuo requisito sia che tu abbia 3 enormi tabelle (dati strutturati) con circa 30 miliardi di righe ciascuna (dimensione totale di 4 TB) e che i tuoi numerosi utenti simultanei (che sono thread di sistema operativo paralleli su macchine LAN remote) dovranno leggere una parte di i dati attraverso le loro SELELCT DOVE GROUPBY esegue query e altamente simultanei, ad esempio 10.000 letture simultanee allo stesso tempo e anche gli utenti devono inserire (senza aggiornamento) i dati in queste tabelle altamente simultanei come 2000 scrittori simultanei (su tutta la rete LAN del data center) . Gli utenti vorrebbero leggere e inserire il più velocemente possibile da questa memoria in cui ogni lettura e scrittura avverranno entro l'intervallo da ms a 1 secondo.

Quali tecnologie consigliate per soddisfare tali requisiti? Esiste un archivio di dati o un archivio di valori chiave che potrebbero farlo? Il cloud NON è un'opzione.

Alcuni chiarimenti:

Gli utenti NON devono vedere subito i dati e l'eventuale coerenza è accettabile. I dati sono accessibili tramite qualsiasi driver che l'archiviazione può fornire e gli utenti sono di nuovo solo thread in esecuzione su macchine remote del data center. Le query sono per lo più come SELEZIONA DOVE GROUPBY.

I dati sono in formato tabulare e ogni riga è di circa 60 byte.

Nessuna opzione cloud in cui non posso usare DynamoDB o soluzioni simili. Devo poterlo ospitare internamente nel data center.

Tutti i dati delle tabelle possono essere letti continuamente e il modello di utilizzo è imprevedibile. Non ci sono join o query super lunghe. Nessun DR richiesto ma è richiesto un HA ragionevole ma non deve essere sofisticato. Ogni lettore sta ottenendo un batch di righe in base alla clausola where e alle righe non sono realmente correlate. Probabilmente possiamo avere una lunghezza fissa per ogni riga, ma spero che il livello di archiviazione se ne preoccupi.

Inoltre, la mia più grande preoccupazione sono tutte quelle scritture simultanee che stanno accadendo con letture simultanee.

Le tue opinioni in merito sono molto apprezzate.

E ancora, ho tre di quelle tabelle con ogni 30 miliardi di righe che contengono diversi tipi di oggetti

Se un'eventuale coerenza è accettabile e tutte le tue query sono aggregate, forse un sistema OLAP a bassa latenza potrebbe funzionare per te. Il tuo requisito suona un po 'come una piattaforma di trading algoritmica. Questo tipo di architettura viene spesso utilizzato nei sistemi di trading floor che hanno l'obbligo di eseguire calcoli di analisi statistiche aggregate su dati aggiornati.

Se è possibile partizionare i dati per data e le vecchie righe non vengono aggiornate, è possibile creare un sistema OLAP ibrido utilizzando un server OLAP convenzionale come i servizi Microsoft Analysis supportati da una normale piattaforma RDBMS. Dovrebbe essere possibile farcela con ~ 4 TB di dati e sia SQL Server che SSAS eseguiranno cluster di dischi condivisi. Sistemi OLAP simili (ad es. Oracle / Hyperion Essbase) sono disponibili presso altri fornitori.

I server OLAP funzionano conservando i dati in un archivio nativo, insieme agli aggregati. La maggior parte supporterà i dati partizionati. Inoltre, la maggior parte funzionerà anche in modalità ROLAP, dove emettono query sul database sottostante. La cosa importante da notare è che la strategia di archiviazione può essere gestita su una base per partizione e puoi passare una partizione dall'una all'altra a livello di programmazione,

In questo modello, i dati storici sono archiviati in partizioni MOLAP con persistenti aggregati di dati. Se una query può essere soddisfatta dagli aggregati, il server li utilizzerà. Gli aggregati possono essere ottimizzati per adattarsi alle query e gli aggregati corretti ridurranno drasticamente la quantità di calcolo necessaria per risolvere la query. Query aggregate molto reattive sono possibili con questo tipo di sistema.

I dati in tempo reale possono essere implementati mantenendo una piccola partizione iniziale, se necessario per il mese corrente, il giorno o anche l'ora. Il server OLAP invierà query al database; se questa partizione è abbastanza piccola, il DBMS sarà in grado di rispondere rapidamente. Un processo regolare crea nuove partizioni principali e converte periodi storici chiusi in MOLAP. Le partizioni precedenti possono essere unite, consentendo di gestire i dati storici in base a qualsiasi grano desiderato.

I client che scrivono nel database scrivono semplicemente il RDBMS sottostante. Se i dati storici rimangono statici, verranno scritti solo nella partizione principale. 4 TB è un volume pratico per l'utilizzo di SSD se si necessita di prestazioni DBMS extra. Anche i fornitori tradizionali hanno offerte basate su SSD con unità SLC più veloci come opzione.