Add Ephemeral Keys to Key-Value store

[ecton]

trafficstars

Many people utilize key-value stores to cache ephemeral data -- data that can be recomputed by going back to the source. Sometimes it's desirable to have that cache be persisted to disk, as it means less load on the upstream data source when the cache restarts. Other times, people may want the cache to consider itself invalid on a restart.

The idea for this feature is to add another layer to the Key-Value store for keys that will never be persisted to disk. Ephemeral keys should support all functionality, including expiration, that normal keys support, but they will be forgotten when the server restarts.

A new permissible action should be added for this, as this feature offers clients a way to directly affect memory consumption of the server.

[rrichardson]

Would it make sense for this to be expanded to a no-disk mode for the DB?

Uses for such a feature would be:

• Unit/integration tests of data centric applications
• Event aggregation systems

[ecton]

Would it make sense for this to be expanded to a no-disk mode for the DB?

This is already supported., although it uses the same append-only storage format so I wouldn't use it for event sourcing. High traffic event sourcing should be possible without ephemeral keys, just tweaking the persistence thresholds.

I think a separate request for a higher-performance in-memory version of Collections would be reasonable, although I would like to understand the use case more before I tackled it. What I'm thinking of may still not be adequate enough for some event aggregation system designs.