Explore if unarchiving is not needed in storage

[juliusv]

While archiving of metrics seems like a reasonable thing (i.e. only create a fp->metric mapping in leveldb once a series is evicted from memory for the first time), it might be more convenient/efficient/easier to not unarchive a metric if it is moved back into memory (i.e. having the mapping in both, memory and leveldb).

Advantages:

• No deletion from leveldb required upon unarchiving.
• No additional write to leveldb required when re-archiving.

Disadvantages:

• Possibly more bookkeeping at some places (e.g. purging a whole series: if it is in memory, we now have to check leveldb, too, because it might be there as well).
• Double-saving of some data (but since unarchiving is relatively rare, it shouldn't matter so much; also, unarchived series are relatively likely to be re-archived soon).

Considerations:

• Perhaps track for in-memory time series, if they have been archived before so that we don't need to check leveldb for membership upon re-archiving and purging?
• Perhaps unarchiving due to a query should be treated differently form unarchiving due to new sample ingestion? The former will lead to very soon re-archiving, while the latter will keep the time series in place for at least the memory retention period.

[beorn7]

The new collision detection code tips the balance here, IMHO, as we have to query the archive more often and want to keep it as lean as possible.

Closing, but feel free to re-open if you disagree.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.