Sto cercando di creare una libreria di accodamento messaggi in Go, che verrà utilizzata come parte di un'applicazione più grande. Una lista doppiamente collegata sembra un approccio ragionevole per una struttura di dati in memoria, ma diciamo che questo elenco cresce di 4 milioni di elementi e ogni elemento è 10k, le cose non sono più garantite per la memoria, più ne ho bisogno essere persistente durante i riavvii.
La maggior parte dell'attività in coda sarà scritta fino alla fine e verrà letta e cancellata dall'inizio, tuttavia ci sono casi in cui il consumo di un messaggio potrebbe fallire per ragioni non correlate alla coda e l'elemento deve essere spostato nel fine della coda.
Ho familiarità con alcune strutture dati che funzionano bene su disco per altri casi specifici. Un albero di unione strutturato log sembra essere ottimo per i dati di accesso casuale, ma non quando le letture e le scritture sono localizzate alla fine e all'inizio dell'albero (in base alla mia comprensione). Anche B Trees e B + Trees sembrano destinati ad accessi e attraversamenti casuali.
Curioso quali algoritmi o approcci esistano già personalizzati per questo problema.
NOTA: Per quanto riguarda SQLite, una delle mie preoccupazioni è il tempo di compattazione. È probabile che i contenuti della coda abbiano un turnover molto elevato ed è importante che qualsiasi tipo di compattazione che deve essere eseguita possa avvenire su un set di dati abbastanza grande senza un impatto sulle prestazioni molto ampio. Cioè se ci sono 4G di messaggi in coda, non voglio uno scenario in cui le cose si bloccano per 2 minuti mentre compattano, il che è ciò che sospetto succederà con SQLite.