Ricevere molti record e archiviarli in un database in un breve lasso di tempo

Operazioni di inserimento in blocco sono i tuoi amici.

Se si tratta solo di un inserto dritto (nuovi dati solo nei file), è sufficiente inserire in massa i dati direttamente nella tabella. La maggior parte dei database dispone di utilità per eseguire operazioni di inserimento in blocco, alcuni persino esporre tali librerie al codice se utilizzano le utilità della riga di comando ei file batch sembrano obsoleti.

Se si tratta di un tipo di inserimento / aggiornamento / eliminazione di uno scenario, l'inserimento di massa in una tabella di staging e quindi l'utilizzo della tecnologia specifica RDMS per aggiornare la tabella di destinazione.

Ad esempio, SQL Server fornisce un bel comando MERGE per unire i dati a una destinazione.

L'inserimento collettivo di 100.000 record richiederà solo un secondo. Se ci si trova nello scenario di inserimento / aggiornamento / cancellazione ci vorranno altri secondi per unire i dati dalla tabella di staging alla tabella principale.

Con questo approccio sarai in grado di soddisfare la finestra dei 5 minuti.

Se c'è davvero questa quantità di dati in arrivo ogni 5 minuti, allora avrai bisogno anche della strategia di partizionamento dei dati per aiutare a gestire i dati nel database.

60/5 = 12 * 24 = 288

288 * 100.000 = 28,800,000 ~ 29 milioni di dischi al giorno. 870 milioni di dischi al mese.

Vorrei sviluppare anche una strategia di archiviazione / eliminazione.

La mia strategia di codifica dovrebbe necessariamente considerare come / quando leggerete quei record.

Altrimenti, se non hai requisiti di lettura, non inserirò nemmeno i record in un database; invece li lascerei semplicemente nei file (o anche li buttassero via).

I tuoi requisiti di lettura combinati con i tuoi requisiti di ingestione determineranno il tipo di database da utilizzare, per uno.

La domanda è piuttosto ampia e lascia molte informazioni inespresse.

Vorrei anche prendere in considerazione lo schema di quei record, come, numero di tabelle, tipi di chiavi primarie.

Hai menzionato che i record sono nuovi piuttosto che gli aggiornamenti esistenti, quindi un database non SQL potrebbe gestirli bene, a seconda dei tuoi requisiti di lettura non dichiarati.