Needs review
Project:
MongoDB
Version:
7.x-1.x-dev
Component:
Cache
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
3 Oct 2012 at 13:39 UTC
Updated:
26 Apr 2020 at 14:57 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
fgmCome to think of it, some might even be interested in them for the watchdog: they are an alternative to capped collections in some scenarii.
Comment #2
fgmThe 2.1/2.2 implementation allowed only a single duration for a given index. Since 2.3/2.4 it is possible to specify expireAfterSeconds as 0, and insert the expiration timestamp in the documents themselves so the deletion thread will delete documents at their requested expiration, which seems just ideal.
http://docs.mongodb.org/v2.4/tutorial/expire-data/#expire-documents-at-a...
Comment #3
fgmAfter experimenting with it, using the latter option seems especially interesting, as it removes the need for an explicit flushing operation, which is performed by the MongoDB server in the background.
Some remarks before committing to this, though:
--setParameter ttlMonitorEnabled=falseor by a commanddb.adminCommand({setParameter:1, ttlMonitorEnabled:false}), so its availability should be checked in the requirementsThis does not seem to be an actual problem, though.
Comment #4
Anonymous (not verified) commentedI'm actually doing this for sessions in a hacked version of the MongoDB Sessions module & it works great:
It would be great to have this in the module. With this, I have
ini_set('session.gc_probability', 0);in settings.php, i.e., no PHP garbage collection needed. +1See also: https://api.drupal.org/api/drupal/core!vendor!symfony!http-foundation!Se...
Comment #5
fgm@rhclayto interested in rolling a patch for it ?
Comment #6
amonteroRecently, I've successfully moved my cache_form bin from MySQL to MongoDB.
As of now, I'm periodically calling
cache_clear_all(NULL,'cache_form',FALSE)to trim expired items from the cache_form collection, but I had first to create an index for the 'expire' field, since the process imposed a heavy load on my server (hint: IMHO, it should be created always on install/first access).So, I've also become interested in TTL-expiring collections, but for cache bins. The above mentioned index was created with TTL, but it's not working. Reading the code above, I've figured that a NumberLong timestamp 'expire' field is not a valid field type for TTL indexes to work.
Since indexing the 'expire' field would be beneficial alone, I would like to take a stab on it and also benefit from TTL expiration. This way, MongoDB would behave more similar to other cache backends such as Redis, where expiration is a built-in feature.
AFAICT, there are two paths:
- Change the 'expire' (and 'created') fields' type to date. I can't see the implications of doing it, if it can break compatibility or would need field type conversion. However, the most orthodox way, IMO.
- Leave current 'expire' field as is and add an 'expire_at' field as @rhclayto says in the comment above. Seems easier but duplicating fields sounds suboptimal.
Advice on how to proceed would be appreciated.
Comment #7
amonteroFirst stab at using TTL fields for both 'expire' and 'created' cache item fields. Field conversion is not necessary, since code provides a underlying field type check, to convert from MongoDate (milliseconds since epoch) to timestamp (seconds since epoch).
Tested with mixed NumberLong/MongoDate cache items in the same bin and worked. All tests pass, also.
Attaching patch for review and getting feedback.
Comment #8
fgmFor review on https://www.drupal.org/project/mongodb/issues/1802114