From 9fcb7f062c1438b62c68b9b6414431f283c0a670 Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Thu, 2 Aug 2012 11:51:37 -0400 Subject: [PATCH 01/17] initial outline for Patterns-TTL document --- draft/tutorial/patterns-ttl-collections.txt | 104 ++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 draft/tutorial/patterns-ttl-collections.txt diff --git a/draft/tutorial/patterns-ttl-collections.txt b/draft/tutorial/patterns-ttl-collections.txt new file mode 100644 index 00000000000..294d0af708f --- /dev/null +++ b/draft/tutorial/patterns-ttl-collections.txt @@ -0,0 +1,104 @@ +================================= +Expire Old Data from a Collection +================================= + +Pattern +------- + +any large amount transient data where more recent data has greater value than older data, and the older the data, the more disposable it becomes. Examples: system log files, weather information, traffic information +any data that is required to be deleted after certain period (SOX, HIPPA, UK Data Protection Act) + +Solution +-------- + +Use collection that has TTL enabled on date field! + +Describe TTL collections and what they do: a special collection that +mongod checks the date field in every document every minute. + +(links to other resources) + +Implementation +-------------- + +Setting up collection (i.e. ensure date field is a BSON date type) + +Setting up index with ``expireAfterSeconds`` field + +.. code-block:: javascript + + db.ttllog.ensureIndex( { "status" : 1 }, { expireAfterSeconds: 3600 } ) + +To expire after no updates after a certain time (i.e. LRU style) --> mostly logs. + +Set ``expireAfterSeconds`` to be the period to delete + +Insert data with current date + +Outcome: anything older than x-days of insert will be deleted + +================================================= +Expire Least Recently Used Data from a Collection +================================================= + +Pattern +------- + +Only keep data that has been recently used, everything else, delete. data caching + + +- client & server states (browser cookies, state information, etc.) +- temporary data cache (Emails, SMS, ) + +Solution +-------- + +Use TTL collections with new dates to items that have been recently used/accessed/etc. + +Implementation +-------------- + +Setting up collection (i.e. ensure date field is a BSON date type) + +Setting up index with ``expireAfterSeconds`` field + +.. code-block:: javascript + + db.ttllog.ensureIndex( { "status" : 1 }, { expireAfterSeconds: 3600 } ) + +With any new uses of the data, update the date field with current date (with update query) + +expected outcome: items deleted: anything that do not have updated dates + + +================================== +Expire Data After a Certain Period +================================== + +Pattern +------- + +Any data that is useless after a certain period + +Examples: +- promotional campaigns +- security codes +- temporary login + +Solution +-------- + +Use TTL collection where the date is set for the future + +Implementation +-------------- + +Set up collection properly (i.e. ensure date field is a BSON date type) + +Set up index with ``expireAfterSeconds`` field + +.. code-block:: javascript + + db.campaign.ensureIndex( { "status" : 1 }, { expireAfterSeconds: 3600 } ) + +Set the date field to be a point in future which data should be deleted. From c3437964b776e6ad1d58ce457956802eddd33f0e Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Thu, 2 Aug 2012 14:40:15 -0400 Subject: [PATCH 02/17] initial draft. DOCS-251 --- draft/tutorial/patterns-ttl-collections.txt | 127 ++++++++++---------- 1 file changed, 62 insertions(+), 65 deletions(-) diff --git a/draft/tutorial/patterns-ttl-collections.txt b/draft/tutorial/patterns-ttl-collections.txt index 294d0af708f..fcccc5fc287 100644 --- a/draft/tutorial/patterns-ttl-collections.txt +++ b/draft/tutorial/patterns-ttl-collections.txt @@ -1,104 +1,101 @@ -================================= -Expire Old Data from a Collection -================================= +================================================= +Expire Least Recently Used Data from a Collection +================================================= -Pattern -------- +.. default-domain:: mongodb -any large amount transient data where more recent data has greater value than older data, and the older the data, the more disposable it becomes. Examples: system log files, weather information, traffic information -any data that is required to be deleted after certain period (SOX, HIPPA, UK Data Protection Act) +.. versionadded:: 2.2 -Solution +Use Case -------- -Use collection that has TTL enabled on date field! +There are some cases to keep :term:`documents ` in a +collection that has been recently updated or accessed, while all other +older documents in the collection should be deleted, such as: -Describe TTL collections and what they do: a special collection that -mongod checks the date field in every document every minute. +- client & server states (i.e. web sessions, client state information) +- document caches (i.e. Emails, SMS) +- particular server logs (i.e. active servers) -(links to other resources) +Solution +-------- -Implementation --------------- +Create a special index on the collection using the +``expireAfterSeconds`` property with the desired duration. Any updates +to documents should update the date field of the collection to keep +the document in the collection. -Setting up collection (i.e. ensure date field is a BSON date type) +Create Index +~~~~~~~~~~~~ -Setting up index with ``expireAfterSeconds`` field +To create an index on the date field of the collection with the +``expireAfterSeconds`` property. The prototype form is: .. code-block:: javascript - db.ttllog.ensureIndex( { "status" : 1 }, { expireAfterSeconds: 3600 } ) + db.collection.ensureIndex( { : 1 }, { expireAfterSeconds: } ) -To expire after no updates after a certain time (i.e. LRU style) --> mostly logs. +.. note:: -Set ``expireAfterSeconds`` to be the period to delete + The date field indexed must be a :term:`BSON date type `. -Insert data with current date - -Outcome: anything older than x-days of insert will be deleted - -================================================= -Expire Least Recently Used Data from a Collection -================================================= - -Pattern -------- +Any documents in the collection that have a date field older than the +duration will be removed from the collection. -Only keep data that has been recently used, everything else, delete. data caching +Update Entry +~~~~~~~~~~~~ +To update the date field with the current date and time, use the +:func:`find() ` method with the +:operator:`$set` operator. The prototype form is: -- client & server states (browser cookies, state information, etc.) -- temporary data cache (Emails, SMS, ) +.. code-block:: javascript -Solution --------- + db.collection.update( { : }, { $set: { : new ISODate() } } ) -Use TTL collections with new dates to items that have been recently used/accessed/etc. +All items that have a date field within the duration will remain in +the collection while all other documents will be removed. -Implementation --------------- +Pattern +------- -Setting up collection (i.e. ensure date field is a BSON date type) +The access time for a ``token`` is recorded in the ``tokenLog`` +collection under the ``accessTime`` field. Any tokens that have not +been accessed over 30 minutes should be removed from the collection. -Setting up index with ``expireAfterSeconds`` field +The ``tokenLog`` collection can be created using the following commands: .. code-block:: javascript - db.ttllog.ensureIndex( { "status" : 1 }, { expireAfterSeconds: 3600 } ) - -With any new uses of the data, update the date field with current date (with update query) - -expected outcome: items deleted: anything that do not have updated dates - + > db.tokenLog.insert( { token: 100, accessTime: new ISODate() }) + > db.tokenLog.insert( { token: 101, accessTime: new ISODate() }) + > db.tokenLog.insert( { token: 102, accessTime: new ISODate() }) -================================== -Expire Data After a Certain Period -================================== +and the collection would be: -Pattern -------- +.. code-block:: javascript -Any data that is useless after a certain period + { "_id" : ObjectId("..."), "token" : 100, "accessTime" : ISODate("2012-08-02T17:47:15.275Z") } + { "_id" : ObjectId("..."), "token" : 101, "accessTime" : ISODate("2012-08-02T17:47:27.764Z") } + { "_id" : ObjectId("..."), "token" : 102, "accessTime" : ISODate("2012-08-02T17:47:34.788Z") } -Examples: -- promotional campaigns -- security codes -- temporary login +To keep the most recently accessed ``token`` in the last 30 minutes, +create an index on this collection by using command: -Solution --------- - -Use TTL collection where the date is set for the future +.. code-block:: javascript -Implementation --------------- + db.tokenLog.ensureIndex( { accessTime: 1 }, { expireAfterSeconds: 30*60 } ) -Set up collection properly (i.e. ensure date field is a BSON date type) +Any ``token`` documents that are older than 30 minutes will be removed from the collection. -Set up index with ``expireAfterSeconds`` field +For each ``token`` document that is accessed again, update only the +``accessTime`` field with the new date. For example, if +``token:101`` is accessed again, update the ``accessTime`` field of ``token:101`` by +using the following command: .. code-block:: javascript - db.campaign.ensureIndex( { "status" : 1 }, { expireAfterSeconds: 3600 } ) + db.tokenLog.update( { "token": 101 }, { $set: { accessTime: new ISODate() } } ) -Set the date field to be a point in future which data should be deleted. +All other entries that have not been updated with a newer +``accessTime`` will automatically be removed from the collection. From fcfb970acc581ae71d7d1bcfd885bb308ae0889d Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Thu, 2 Aug 2012 14:42:16 -0400 Subject: [PATCH 03/17] renaming file --- ...ns-ttl-collections.txt => expire-least-recently-used-data.txt} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename draft/tutorial/{patterns-ttl-collections.txt => expire-least-recently-used-data.txt} (100%) diff --git a/draft/tutorial/patterns-ttl-collections.txt b/draft/tutorial/expire-least-recently-used-data.txt similarity index 100% rename from draft/tutorial/patterns-ttl-collections.txt rename to draft/tutorial/expire-least-recently-used-data.txt From 845fb0823ef2c1d9f14be2643b27f4bb582fa2b5 Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Thu, 2 Aug 2012 17:13:38 -0400 Subject: [PATCH 04/17] first draft - DOCS-151 --- .../expire-least-recently-used-data.txt | 80 +++++++++++-------- 1 file changed, 47 insertions(+), 33 deletions(-) diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index fcccc5fc287..ea100d3fc8e 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -9,61 +9,73 @@ Expire Least Recently Used Data from a Collection Use Case -------- -There are some cases to keep :term:`documents ` in a -collection that has been recently updated or accessed, while all other -older documents in the collection should be deleted, such as: +There are some cases to keep recently accessed :term:`documents +` in a collection but to delete older unused documents. Some +possible cases are: - client & server states (i.e. web sessions, client state information) -- document caches (i.e. Emails, SMS) -- particular server logs (i.e. active servers) +- file caches (i.e. keep recently used files online, move unused files to archives) +- particular server logs (i.e. keep active server logs, remove inactive server logs) + +In these cases, the most recently accessed documents are important +while older unused documents should be removed from the collection. Solution -------- -Create a special index on the collection using the -``expireAfterSeconds`` property with the desired duration. Any updates -to documents should update the date field of the collection to keep -the document in the collection. +To maintain only the most recently accessed documents in your +collection, create a special Time To Live (TTL) index. This is an +expiring collection, which any document that is greater than the TTL +value will be deleted from the collection. -Create Index -~~~~~~~~~~~~ +To keep documents in the TTL collection, set the document's date field +with a value less than the TTL value. Any documents that is less than +the TTL value will remain in the collection. + +.. TODO are TTL values greater than and less than well understood?? + +Create TTL Index +~~~~~~~~~~~~~~~~ -To create an index on the date field of the collection with the -``expireAfterSeconds`` property. The prototype form is: +To create an expiring collection, create an index on the date field of +the collection with the ``expireAfterSeconds`` property. The prototype +form is: .. code-block:: javascript - db.collection.ensureIndex( { : 1 }, { expireAfterSeconds: } ) + db.collection.ensureIndex( { : 1 }, { expireAfterSeconds: } ) .. note:: The date field indexed must be a :term:`BSON date type `. -Any documents in the collection that have a date field older than the -duration will be removed from the collection. +Any documents in the collection that have a date value greater than the +TTL value will be removed from the collection. Update Entry ~~~~~~~~~~~~ -To update the date field with the current date and time, use the -:func:`find() ` method with the -:operator:`$set` operator. The prototype form is: +Update any documents that should remain in the collection by setting +the date field with the current date and time. Use the :func:`update() +` method with the :operator:`$set` +operator. The prototype form is: .. code-block:: javascript db.collection.update( { : }, { $set: { : new ISODate() } } ) -All items that have a date field within the duration will remain in -the collection while all other documents will be removed. +All items that have a date value less than the TTL value will remain +in the collection. Pattern ------- The access time for a ``token`` is recorded in the ``tokenLog`` -collection under the ``accessTime`` field. Any tokens that have not -been accessed over 30 minutes should be removed from the collection. +collection in the ``accessTime`` field. Tokens that are accessed will +be updated. Any tokens that have not been accessed over 30 minutes +should be removed from the collection. -The ``tokenLog`` collection can be created using the following commands: +A ``tokenLog`` collection can be created using the following commands: .. code-block:: javascript @@ -79,23 +91,25 @@ and the collection would be: { "_id" : ObjectId("..."), "token" : 101, "accessTime" : ISODate("2012-08-02T17:47:27.764Z") } { "_id" : ObjectId("..."), "token" : 102, "accessTime" : ISODate("2012-08-02T17:47:34.788Z") } -To keep the most recently accessed ``token`` in the last 30 minutes, -create an index on this collection by using command: +To keep only the most recently accessed ``token`` in the last 30 +minutes, create a 30 minute TTL index on this collection by using command: .. code-block:: javascript db.tokenLog.ensureIndex( { accessTime: 1 }, { expireAfterSeconds: 30*60 } ) -Any ``token`` documents that are older than 30 minutes will be removed from the collection. +Any ``token`` documents that are older than 30 minutes will be +automatically removed from the collection. -For each ``token`` document that is accessed again, update only the -``accessTime`` field with the new date. For example, if -``token:101`` is accessed again, update the ``accessTime`` field of ``token:101`` by -using the following command: +When a ``token`` is accessed, update only its ``accessTime`` field +with the current time and date. For example, if ``token:101`` is +accessed again, update the ``accessTime`` field of ``token:101`` by +using the command: .. code-block:: javascript db.tokenLog.update( { "token": 101 }, { $set: { accessTime: new ISODate() } } ) -All other entries that have not been updated with a newer -``accessTime`` will automatically be removed from the collection. +As time moves forward, any document that has accessed will remain +while unused documents will be automatically deleted from the +collection. From 7ddc5500c29a185497b6e19dc4dd625b57cab59a Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Thu, 2 Aug 2012 17:19:51 -0400 Subject: [PATCH 05/17] fixing up older/greater than mix up --- draft/tutorial/expire-least-recently-used-data.txt | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index ea100d3fc8e..3df9d2cea3d 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -25,15 +25,13 @@ Solution To maintain only the most recently accessed documents in your collection, create a special Time To Live (TTL) index. This is an -expiring collection, which any document that is greater than the TTL +expiring collection, which any document that is older than the TTL value will be deleted from the collection. To keep documents in the TTL collection, set the document's date field with a value less than the TTL value. Any documents that is less than the TTL value will remain in the collection. -.. TODO are TTL values greater than and less than well understood?? - Create TTL Index ~~~~~~~~~~~~~~~~ @@ -49,8 +47,8 @@ form is: The date field indexed must be a :term:`BSON date type `. -Any documents in the collection that have a date value greater than the -TTL value will be removed from the collection. +Any documents in the collection that are older than the TTL value will +be removed from the collection. Update Entry ~~~~~~~~~~~~ From 85a7aee89c1106f4ac4b4656469044e824afdf26 Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Fri, 3 Aug 2012 17:49:21 -0400 Subject: [PATCH 06/17] review mangling. --- .../expire-least-recently-used-data.txt | 156 +++++++++++------- 1 file changed, 97 insertions(+), 59 deletions(-) diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index 3df9d2cea3d..0680abc1d06 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -6,108 +6,146 @@ Expire Least Recently Used Data from a Collection .. versionadded:: 2.2 -Use Case --------- +.. walk away from article so that it can be useful. +.. read aloud to self +.. few +.. --> passive; more direct to outline that the system will delete things. + +.. specify that the 'application' is the one responsible for updating the field +.. clear up examples - application +.. specify that the 'system' deletes the information - application's reponsibility to keep things alive -There are some cases to keep recently accessed :term:`documents -` in a collection but to delete older unused documents. Some -possible cases are: +Use Cases +--------- +.. good, but no syntatic - group (i.e.) into own sentences - client & server states (i.e. web sessions, client state information) - file caches (i.e. keep recently used files online, move unused files to archives) - particular server logs (i.e. keep active server logs, remove inactive server logs) +.. --> passive; more direct to outline that the system will delete things. In these cases, the most recently accessed documents are important while older unused documents should be removed from the collection. Solution -------- -To maintain only the most recently accessed documents in your -collection, create a special Time To Live (TTL) index. This is an -expiring collection, which any document that is older than the TTL -value will be deleted from the collection. +MongoDB has a :term:`TTL` collection that :progam:`mongod` will +automatically remove any documents from the collection that are older +than specified period. In a :term:`TTL` collection, to keep any document +from being deleted, update the date field of the document within +the :term:`TTL` duration. + +#. Create collection with proper date field. +#. Create TTL Index for the collection with ``expireAfterSeconds``. +#. Update the date field of any document to stay in the collection. + +Pattern +------- -To keep documents in the TTL collection, set the document's date field -with a value less than the TTL value. Any documents that is less than -the TTL value will remain in the collection. +.. token too general --> switch up to 'events' (i.e. events log) +.. token kinda sounds like a real thing -Create TTL Index -~~~~~~~~~~~~~~~~ +cacheing web pages in memory +- you have a web server that serves web pages +- web pages are stored in memory and disk +- want to have system to decide which pages to keep in memory (and + which pages to put to disk) -To create an expiring collection, create an index on the date field of -the collection with the ``expireAfterSeconds`` property. The prototype -form is: +The access time of a web page for a server are recorded in an +``eventLog``. Web pages that are accessed will be +maintained in memory, old web pages that have not been accessed over +an hour will be removed from memory, for more pages to be ca -.. code-block:: javascript +The ``eventLog`` collection would be: - db.collection.ensureIndex( { : 1 }, { expireAfterSeconds: } ) +.. code-block:: javascript -.. note:: + { "_id" : ObjectId("..."), "pageID" : 100, "accessTime" : ISODate("2012-08-02T17:47:15.275Z") } + { "_id" : ObjectId("..."), "pageID" : 101, "accessTime" : ISODate("2012-08-02T17:47:27.764Z") } + { "_id" : ObjectId("..."), "pageID" : 102, "accessTime" : ISODate("2012-08-02T17:47:34.788Z") } - The date field indexed must be a :term:`BSON date type `. +An ``eventLog`` collection that can be created by using the following commands: -Any documents in the collection that are older than the TTL value will -be removed from the collection. +.. code-block:: javascript -Update Entry -~~~~~~~~~~~~ + > db.eventLog.insert( { pageID: 100, accessTime: new ISODate() }) + > db.eventLog.insert( { pageID: 101, accessTime: new ISODate() }) + > db.eventLog.insert( { pageID: 102, accessTime: new ISODate() }) -Update any documents that should remain in the collection by setting -the date field with the current date and time. Use the :func:`update() -` method with the :operator:`$set` -operator. The prototype form is: +Create a 60 minute TTL index on this collection by using command: .. code-block:: javascript - db.collection.update( { : }, { $set: { : new ISODate() } } ) + db.tokenLog.ensureIndex( { accessTime: 1 }, { expireAfterSeconds: 3600 } ) + +:program:`mongod` will now remove any pages in this collection that have not been accessed +in over an hour. -All items that have a date value less than the TTL value will remain -in the collection. -Pattern -------- -The access time for a ``token`` is recorded in the ``tokenLog`` -collection in the ``accessTime`` field. Tokens that are accessed will -be updated. Any tokens that have not been accessed over 30 minutes -should be removed from the collection. +When a ``token`` is accessed, update only its ``accessTime`` field +with the current time and date. For example, if ``token:101`` is +accessed again, update the ``accessTime`` field of ``token:101`` by +using the command: -A ``tokenLog`` collection can be created using the following commands: + +Update any pages that have been accessed in the ``eventLog`` by using command: .. code-block:: javascript - > db.tokenLog.insert( { token: 100, accessTime: new ISODate() }) - > db.tokenLog.insert( { token: 101, accessTime: new ISODate() }) - > db.tokenLog.insert( { token: 102, accessTime: new ISODate() }) + db.eventLog.update( { pageID: 101 }, { $set: { accessTime: new ISODate() } } ) + +.. another set of example for the +.. naming + + +use case: +keep authenticated user information in the system. if they don't access the +system after a certain period, destroy authentication and force them +to reauthenticate +- web mail +- bank login +- + +- upon successful authentication, insert information into collection +- on every server access from user, check authentication info, update + date entry on user +- after no access from user, mongod will automatically delete + information + + +- insert user information after successful authentication +- on next access, check if user is authenticated or not +- update date field for user after server access +- if user is not on authenticated list, force reauthentication + -and the collection would be: +The ``authenticationLog`` collection could be: .. code-block:: javascript - { "_id" : ObjectId("..."), "token" : 100, "accessTime" : ISODate("2012-08-02T17:47:15.275Z") } - { "_id" : ObjectId("..."), "token" : 101, "accessTime" : ISODate("2012-08-02T17:47:27.764Z") } - { "_id" : ObjectId("..."), "token" : 102, "accessTime" : ISODate("2012-08-02T17:47:34.788Z") } + { "_id" : ObjectId("..."), ..., "userID" : 000, "accessTime" : ISODate("2012-08-02T17:47:15.275Z") } + { "_id" : ObjectId("..."), ..., "userID" : 001, "accessTime" : ISODate("2012-08-02T17:47:27.764Z") } + { "_id" : ObjectId("..."), ..., "userID" : 002, "accessTime" : ISODate("2012-08-02T17:47:34.788Z") } -To keep only the most recently accessed ``token`` in the last 30 -minutes, create a 30 minute TTL index on this collection by using command: +An ``authenticationLog`` collection that can be created by using the following commands: .. code-block:: javascript - db.tokenLog.ensureIndex( { accessTime: 1 }, { expireAfterSeconds: 30*60 } ) + > db.authenticationLog.insert( { userID: 100, accessTime: new ISODate() }) + > db.authenticationLog.insert( { userID: 101, accessTime: new ISODate() }) + > db.authenticationLog.insert( { userID: 102, accessTime: new ISODate() }) -Any ``token`` documents that are older than 30 minutes will be -automatically removed from the collection. +Verify the user has been authenticated recently: -When a ``token`` is accessed, update only its ``accessTime`` field -with the current time and date. For example, if ``token:101`` is -accessed again, update the ``accessTime`` field of ``token:101`` by -using the command: +.. code-block:: javascript + + db.authenticationLog.find( { userID: 101 } ) + +On access from the user, update the users' access time: .. code-block:: javascript - db.tokenLog.update( { "token": 101 }, { $set: { accessTime: new ISODate() } } ) + db.authenticationLog.update( { userID: 101 }, { $set: { accessTime: new ISODate() } } ) -As time moves forward, any document that has accessed will remain -while unused documents will be automatically deleted from the -collection. From f62f86d2e6f9b561a34b20e1166fd91daec97bb0 Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Sat, 4 Aug 2012 14:31:20 -0400 Subject: [PATCH 07/17] brainstorming new use cases for LRU TTL collections. --- .../expire-least-recently-used-data.txt | 51 +++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index 0680abc1d06..7b579c0d8f1 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -40,6 +40,15 @@ the :term:`TTL` duration. #. Create TTL Index for the collection with ``expireAfterSeconds``. #. Update the date field of any document to stay in the collection. + +Key points about TTL collections with LRU +- the application is responsible for maintaining ONLY the documents it + wants. +- the 'clean up' aspect is responsible by the + :program:`mongod`. :program:`mongod` will remove any files older + than the TTL time. +- + Pattern ------- @@ -149,3 +158,45 @@ On access from the user, update the users' access time: db.authenticationLog.update( { userID: 101 }, { $set: { accessTime: new ISODate() } } ) + + +Use case + +File caching (image server) + +check memory for file +if file is not in memory, load from archive +update file access time + +pseudo code + +loop start + receive file request + check memory for file + if file not in memory + retreive file from archive to memory + update file access time + serve file from memory + system delete unused files from cache +end loop + +loop start + receive file request + query cacheServer record for file + if file not in cacheServer record + retreive file from archiveServer send to cacheServer + insert cacheServer record's file access time + send cacheServer url to requester + system deletes unused files from cacheServer after specified period +end loop + +Problem: want to serve most accessed images from archive quickly, and +keep around for future requests, but archive machine has slow +access. build mongodb to be fast file caching + +Use MongoDB as a fast image server + +State saving + +Comment drafting +You have: website with comment feature to allow people to comment From 26b3a46a3c442cc47f561ebdeeed091b5d2f876d Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Sun, 5 Aug 2012 10:48:52 -0400 Subject: [PATCH 08/17] draft of use case: state --- .../expire-least-recently-used-data.txt | 93 ++++++++++++++++++- 1 file changed, 90 insertions(+), 3 deletions(-) diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index 7b579c0d8f1..769747e3649 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -115,7 +115,6 @@ system after a certain period, destroy authentication and force them to reauthenticate - web mail - bank login -- - upon successful authentication, insert information into collection - on every server access from user, check authentication info, update @@ -123,7 +122,6 @@ to reauthenticate - after no access from user, mongod will automatically delete information - - insert user information after successful authentication - on next access, check if user is authenticated or not - update date field for user after server access @@ -199,4 +197,93 @@ Use MongoDB as a fast image server State saving Comment drafting -You have: website with comment feature to allow people to comment +You have: website with comment feature to allow people to comment. Any +draft that is actively being worked on within a certain period should +be saved. If a draft has not been touched for a long time, the user +probably won't comment and their draft should be deleted. + +--> want to keep all comments within the same collection + +System set up: + +Application response +- Insert: comment draft into index +- On any new changes: update document with new comment & time +- On submission: delete the ``draft-time`` field + +System response: +- scan through comment index every 60 seconds +- checks any items with ``draft-time`` field +- if (current time - ``draft-time`` field > expireAfterSeconds) remove + document + +Result: draft and comments in same index but index only contains +comments and drafts in progress + +State + +Pattern: want to have authentication list for logged in accounts so +users do not have to go through lengthy logins each time system +access, but want accounts that have had no access to be automagically +deleted. + +system setup: +- collection on system with an application identifier and a date field + storing current access times +- set up index with ``expireAfterSeconds`` + +application response: +- on successful authentication: insert userID & current time +- on each userID access: update userID's accessTime with current time +- when logout specified: remove userID from collection + +System response: +- scan through authentication list every minute. +- checks accessTime, if (current system time - ``accessTime`` field > expireAfterSeconds) remove + document + +Overall result: +- authentication list containing current logins +- Any accounts that have had no activity for a certain period of time +will be purged from the list. + +============ +State saving +============ + + +Use Case +-------- + +You want to keep a list of logged in users that accessed the +system recently, but any users that have not accessed the system +for a long time will be removed from the list and need to login again. + +Solution +-------- + +Your application will ensure authentication and update only recently +accessed accounts, MongoDB will maintain the list and delete any +entries that have not been updated within a specified period. + +Elements required: +- MongoDB collection to store list. +- Application to authenticate users + +Steps required: +- Setup MongodB TTL collection +- Application access MongoDB collection and update on each access. + +System response: +- + +Pattern +------- + +Set up MongoDB TTL collection +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +Application response +~~~~~~~~~~~~~~~~~~~~ + From 6a46a3b06f288adc4330adce819e30c81076c1aa Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Sun, 5 Aug 2012 20:34:18 -0400 Subject: [PATCH 09/17] working out draft for state pattern --- .../expire-least-recently-used-data.txt | 99 ++++++++++++++++--- 1 file changed, 85 insertions(+), 14 deletions(-) diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index 769747e3649..02a7f6a19a4 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -255,35 +255,106 @@ State saving Use Case -------- -You want to keep a list of logged in users that accessed the -system recently, but any users that have not accessed the system -for a long time will be removed from the list and need to login again. +You need to keep a list of updated items but anything not +updated should be deleted automatically. + +For example, you want keep a list of users that are actively accessing +the system so they do not have to repeatly authenticate. Any users that +have not accessed the system for a long time will be removed from the +list will have to reauthenticate on their next access. Solution -------- -Your application will ensure authentication and update only recently -accessed accounts, MongoDB will maintain the list and delete any +Use MongoDB's TTL collection to store the list of items. Your +application will query the collection to verify items and update items as +needed. Any items not updated for a specified period will be deleted +by the :program:`mongod` process. + +For example, your application will ensure authentication and insert +authenticated users into the list. The application will check the list +when a user accesses the system, if the user is on the list, provide +access and update their access time entry, otherwise, force the user +to reauthenticate. MongoDB will maintain the list and delete any entries that have not been updated within a specified period. Elements required: -- MongoDB collection to store list. -- Application to authenticate users +- MongoDB version 2.2 or greater. +- Application to authenticate users, also able to access, insert, and + update entries in MongoDB collection. Steps required: -- Setup MongodB TTL collection -- Application access MongoDB collection and update on each access. - -System response: -- +- Setup MongodB TTL collection. +- Application to insert, access, and update MongoDB collection. Pattern ------- -Set up MongoDB TTL collection -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The ``eventLog`` collection could be: + +.. code-block:: javascript + + { "_id" : ObjectId("..."), "userID" : 100, "accessTime" : ISODate("2012-08-02T17:47:15.275Z") } + { "_id" : ObjectId("..."), "userID" : 101, "accessTime" : ISODate("2012-08-02T17:47:27.764Z") } + { "_id" : ObjectId("..."), "userID" : 102, "accessTime" : ISODate("2012-08-02T17:47:34.788Z") } + +An ``eventLog`` collection like the above can be created by using the following commands: +.. code-block:: javascript + + > db.eventLog.insert( { userID: 100, accessTime: new ISODate() }) + > db.eventLog.insert( { userID: 101, accessTime: new ISODate() }) + > db.eventLog.insert( { userID: 102, accessTime: new ISODate() }) + +Set up TTL collection +~~~~~~~~~~~~~~~~~~~~~ + +Setup MongoDB to delete any documents that have an ``accessTime`` +older than one hour by creating a TTL index using command: + +.. code-block:: javascript + + db.eventLog.ensureIndex( { accessTime: 1 }, { expireAfterSeconds: 3600 } ) + +Any items in the ``eventLog`` collection older than one hour will be +removed by the :program:`mongod` instance. Application response ~~~~~~~~~~~~~~~~~~~~ +Upon successful user authentication, your application will insert the +user's entry into the ``eventLog`` collection using the following command: + +.. code-block:: javascript + + > db.eventLog.insert( { userID: 103, accessTime: new ISODate() }) + +Your application can verify if a user is currently authenticated by +using command: + +.. code-block:: javascript + + > db.eventLog.find( { userID: 101 }) + +If the result is similar to: + +.. code-block:: javascript + + { "_id" : ObjectId("..."), "userID" : 101, "accessTime" : ISODate("2012-08-02T17:47:27.764Z") } + +The user is currently authenticated and may access the system. If +there is no result, the user needs to reauthenticate. + +:program:`mongod` will remove any user entries that have an +``accessTime`` greater than 1 hour (3600 seconds.) + +Overall result +~~~~~~~~~~~~~~ + + + +System response: +- :program:`mongod` will scan TTL collection every minute +- any items in the collection with a date field that is older than + specified will be removed immediately +- any items updated by the application will remain in the collection From cd4d451b27fd6a6fb0eff61c3abe74b241c48254 Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Tue, 7 Aug 2012 08:12:13 -0400 Subject: [PATCH 10/17] draft 1 done. --- .../expire-least-recently-used-data.txt | 371 ++++-------------- 1 file changed, 77 insertions(+), 294 deletions(-) diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index 02a7f6a19a4..e6dc4708a9e 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -6,291 +6,54 @@ Expire Least Recently Used Data from a Collection .. versionadded:: 2.2 -.. walk away from article so that it can be useful. -.. read aloud to self -.. few -.. --> passive; more direct to outline that the system will delete things. - -.. specify that the 'application' is the one responsible for updating the field -.. clear up examples - application -.. specify that the 'system' deletes the information - application's reponsibility to keep things alive - -Use Cases ---------- - -.. good, but no syntatic - group (i.e.) into own sentences -- client & server states (i.e. web sessions, client state information) -- file caches (i.e. keep recently used files online, move unused files to archives) -- particular server logs (i.e. keep active server logs, remove inactive server logs) - -.. --> passive; more direct to outline that the system will delete things. -In these cases, the most recently accessed documents are important -while older unused documents should be removed from the collection. - -Solution --------- - -MongoDB has a :term:`TTL` collection that :progam:`mongod` will -automatically remove any documents from the collection that are older -than specified period. In a :term:`TTL` collection, to keep any document -from being deleted, update the date field of the document within -the :term:`TTL` duration. - -#. Create collection with proper date field. -#. Create TTL Index for the collection with ``expireAfterSeconds``. -#. Update the date field of any document to stay in the collection. - - -Key points about TTL collections with LRU -- the application is responsible for maintaining ONLY the documents it - wants. -- the 'clean up' aspect is responsible by the - :program:`mongod`. :program:`mongod` will remove any files older - than the TTL time. -- - -Pattern -------- - -.. token too general --> switch up to 'events' (i.e. events log) -.. token kinda sounds like a real thing - -cacheing web pages in memory -- you have a web server that serves web pages -- web pages are stored in memory and disk -- want to have system to decide which pages to keep in memory (and - which pages to put to disk) - -The access time of a web page for a server are recorded in an -``eventLog``. Web pages that are accessed will be -maintained in memory, old web pages that have not been accessed over -an hour will be removed from memory, for more pages to be ca - -The ``eventLog`` collection would be: - -.. code-block:: javascript - - { "_id" : ObjectId("..."), "pageID" : 100, "accessTime" : ISODate("2012-08-02T17:47:15.275Z") } - { "_id" : ObjectId("..."), "pageID" : 101, "accessTime" : ISODate("2012-08-02T17:47:27.764Z") } - { "_id" : ObjectId("..."), "pageID" : 102, "accessTime" : ISODate("2012-08-02T17:47:34.788Z") } - -An ``eventLog`` collection that can be created by using the following commands: - -.. code-block:: javascript - - > db.eventLog.insert( { pageID: 100, accessTime: new ISODate() }) - > db.eventLog.insert( { pageID: 101, accessTime: new ISODate() }) - > db.eventLog.insert( { pageID: 102, accessTime: new ISODate() }) - -Create a 60 minute TTL index on this collection by using command: - -.. code-block:: javascript - - db.tokenLog.ensureIndex( { accessTime: 1 }, { expireAfterSeconds: 3600 } ) - -:program:`mongod` will now remove any pages in this collection that have not been accessed -in over an hour. - - - -When a ``token`` is accessed, update only its ``accessTime`` field -with the current time and date. For example, if ``token:101`` is -accessed again, update the ``accessTime`` field of ``token:101`` by -using the command: - - -Update any pages that have been accessed in the ``eventLog`` by using command: - -.. code-block:: javascript - - db.eventLog.update( { pageID: 101 }, { $set: { accessTime: new ISODate() } } ) - -.. another set of example for the -.. naming - - -use case: -keep authenticated user information in the system. if they don't access the -system after a certain period, destroy authentication and force them -to reauthenticate -- web mail -- bank login - -- upon successful authentication, insert information into collection -- on every server access from user, check authentication info, update - date entry on user -- after no access from user, mongod will automatically delete - information - -- insert user information after successful authentication -- on next access, check if user is authenticated or not -- update date field for user after server access -- if user is not on authenticated list, force reauthentication - - -The ``authenticationLog`` collection could be: - -.. code-block:: javascript - - { "_id" : ObjectId("..."), ..., "userID" : 000, "accessTime" : ISODate("2012-08-02T17:47:15.275Z") } - { "_id" : ObjectId("..."), ..., "userID" : 001, "accessTime" : ISODate("2012-08-02T17:47:27.764Z") } - { "_id" : ObjectId("..."), ..., "userID" : 002, "accessTime" : ISODate("2012-08-02T17:47:34.788Z") } - -An ``authenticationLog`` collection that can be created by using the following commands: - -.. code-block:: javascript - - > db.authenticationLog.insert( { userID: 100, accessTime: new ISODate() }) - > db.authenticationLog.insert( { userID: 101, accessTime: new ISODate() }) - > db.authenticationLog.insert( { userID: 102, accessTime: new ISODate() }) - -Verify the user has been authenticated recently: - -.. code-block:: javascript - - db.authenticationLog.find( { userID: 101 } ) - -On access from the user, update the users' access time: - -.. code-block:: javascript - - db.authenticationLog.update( { userID: 101 }, { $set: { accessTime: new ISODate() } } ) - - - -Use case - -File caching (image server) - -check memory for file -if file is not in memory, load from archive -update file access time - -pseudo code - -loop start - receive file request - check memory for file - if file not in memory - retreive file from archive to memory - update file access time - serve file from memory - system delete unused files from cache -end loop - -loop start - receive file request - query cacheServer record for file - if file not in cacheServer record - retreive file from archiveServer send to cacheServer - insert cacheServer record's file access time - send cacheServer url to requester - system deletes unused files from cacheServer after specified period -end loop - -Problem: want to serve most accessed images from archive quickly, and -keep around for future requests, but archive machine has slow -access. build mongodb to be fast file caching - -Use MongoDB as a fast image server - -State saving - -Comment drafting -You have: website with comment feature to allow people to comment. Any -draft that is actively being worked on within a certain period should -be saved. If a draft has not been touched for a long time, the user -probably won't comment and their draft should be deleted. - ---> want to keep all comments within the same collection - -System set up: - -Application response -- Insert: comment draft into index -- On any new changes: update document with new comment & time -- On submission: delete the ``draft-time`` field - -System response: -- scan through comment index every 60 seconds -- checks any items with ``draft-time`` field -- if (current time - ``draft-time`` field > expireAfterSeconds) remove - document - -Result: draft and comments in same index but index only contains -comments and drafts in progress - -State - -Pattern: want to have authentication list for logged in accounts so -users do not have to go through lengthy logins each time system -access, but want accounts that have had no access to be automagically -deleted. - -system setup: -- collection on system with an application identifier and a date field - storing current access times -- set up index with ``expireAfterSeconds`` - -application response: -- on successful authentication: insert userID & current time -- on each userID access: update userID's accessTime with current time -- when logout specified: remove userID from collection - -System response: -- scan through authentication list every minute. -- checks accessTime, if (current system time - ``accessTime`` field > expireAfterSeconds) remove - document - -Overall result: -- authentication list containing current logins -- Any accounts that have had no activity for a certain period of time -will be purged from the list. - -============ -State saving -============ - +.. TODO add introduction Use Case -------- -You need to keep a list of updated items but anything not -updated should be deleted automatically. +You need to keep a list of updated items but anything not updated +should be deleted automatically. This is useful for applications that +require access control such as web-based E-mail, internet banking, +personalized web services, user account verification, etc. -For example, you want keep a list of users that are actively accessing -the system so they do not have to repeatly authenticate. Any users that -have not accessed the system for a long time will be removed from the -list will have to reauthenticate on their next access. +For example, you want keep a list of users that are actively using the +system so they do not have to repeatedly authenticate. Any users who +do not use the system for a long time will automatically be logged out +and must reauthenticate. Solution -------- -Use MongoDB's TTL collection to store the list of items. Your -application will query the collection to verify items and update items as -needed. Any items not updated for a specified period will be deleted -by the :program:`mongod` process. +Use MongoDB's TTL collection to store this list. The application will +only insert new entries, query the collection to verify items on the +list, and update items as needed. Any items not updated for a +specified period will be deleted by the :program:`mongod` process. -For example, your application will ensure authentication and insert -authenticated users into the list. The application will check the list +For example, the application will ensure authentication and insert +logged in users into the list. The application will check the list when a user accesses the system, if the user is on the list, provide access and update their access time entry, otherwise, force the user to reauthenticate. MongoDB will maintain the list and delete any -entries that have not been updated within a specified period. +entries, which have not been updated. + +Requirements: -Elements required: -- MongoDB version 2.2 or greater. -- Application to authenticate users, also able to access, insert, and - update entries in MongoDB collection. +- MongoDB version 2.2 or greater for storing list. +- Application to authenticate users, and is able to access, insert, + and update entries in the MongoDB collection. Steps required: -- Setup MongodB TTL collection. -- Application to insert, access, and update MongoDB collection. + +#. Set up a MongodB TTL collection. +#. Application to insert, access, and update MongoDB collection. Pattern ------- -The ``eventLog`` collection could be: +For this example, the logged in user list will be named: ``authLog`` +to store, record, and update users who are authorized to use the system. + +The ``authLog`` collection could look like the following: .. code-block:: javascript @@ -298,63 +61,83 @@ The ``eventLog`` collection could be: { "_id" : ObjectId("..."), "userID" : 101, "accessTime" : ISODate("2012-08-02T17:47:27.764Z") } { "_id" : ObjectId("..."), "userID" : 102, "accessTime" : ISODate("2012-08-02T17:47:34.788Z") } -An ``eventLog`` collection like the above can be created by using the following commands: +An ``authLog`` collection like the above can be created by using the following commands: .. code-block:: javascript - > db.eventLog.insert( { userID: 100, accessTime: new ISODate() }) - > db.eventLog.insert( { userID: 101, accessTime: new ISODate() }) - > db.eventLog.insert( { userID: 102, accessTime: new ISODate() }) + > db.authLog.insert( { userID: 100, accessTime: new ISODate() }) + > db.authLog.insert( { userID: 101, accessTime: new ISODate() }) + > db.authLog.insert( { userID: 102, accessTime: new ISODate() }) + +The field used to record time, ``accessTime`` in the above example, +must be an ISODate, otherwise, MongoDB's TTL functionality will not +work properly. -Set up TTL collection -~~~~~~~~~~~~~~~~~~~~~ +Set up a TTL collection +~~~~~~~~~~~~~~~~~~~~~~~ -Setup MongoDB to delete any documents that have an ``accessTime`` -older than one hour by creating a TTL index using command: +Set up MongoDB to index the collection's ``accessTime`` field and delete any +items that have ``accessTime`` entries older than 300 seconds or five minutes by: .. code-block:: javascript - db.eventLog.ensureIndex( { accessTime: 1 }, { expireAfterSeconds: 3600 } ) + db.authLog.ensureIndex( { accessTime: 1 }, { expireAfterSeconds: 300 } ) -Any items in the ``eventLog`` collection older than one hour will be -removed by the :program:`mongod` instance. +Any items in the ``authLog`` collection older than 300 seconds will +be automatically removed by the :program:`mongod` instance. The +removal duration can be adjusted by specifying a different value for +``expireAfterSeconds``. Application response ~~~~~~~~~~~~~~~~~~~~ -Upon successful user authentication, your application will insert the -user's entry into the ``eventLog`` collection using the following command: +Active application input for the ``authLog`` collection is required +for new entries, verifying entries, and updating entries. + +For new entries, such as after successful user authentication, the +application must insert into the ``authLog`` collection using the +following command: .. code-block:: javascript - > db.eventLog.insert( { userID: 103, accessTime: new ISODate() }) + > db.authLog.insert( { userID: 103, accessTime: new ISODate() }) -Your application can verify if a user is currently authenticated by -using command: +To verify user authentication, the application can accomplish this by +using operation: .. code-block:: javascript - > db.eventLog.find( { userID: 101 }) + > db.authLog.find( { userID: 101 } ) -If the result is similar to: +If the operation result is similar to: .. code-block:: javascript { "_id" : ObjectId("..."), "userID" : 101, "accessTime" : ISODate("2012-08-02T17:47:27.764Z") } -The user is currently authenticated and may access the system. If -there is no result, the user needs to reauthenticate. +The user is currently authenticated and may access the system. If the +result is empty, the user is not authenticated and needs to +reauthenticate. -:program:`mongod` will remove any user entries that have an -``accessTime`` greater than 1 hour (3600 seconds.) +To update entries for authenticated users, update the ``accessTime`` +entries using the following command: -Overall result -~~~~~~~~~~~~~~ +.. code-block:: javascript + + db.authenticationLog.update( { userID: 101 }, { $set: { accessTime: new ISODate() } } ) +This will set the ``accessTime`` field for ``userID`` 101 to the current +time. MongoDB will not delete this entry because its ``accessTime`` +field is now newer than 300 seconds. +With TTL enabled, the :program:`mongod` instance will scan the +collection every minute and remove any user entries that have an +``accessTime`` greater than five minutes or 300 seconds. Any items +that have been updated within 300 seconds will remain in the collection. + +Overall result +~~~~~~~~~~~~~~ -System response: -- :program:`mongod` will scan TTL collection every minute -- any items in the collection with a date field that is older than - specified will be removed immediately -- any items updated by the application will remain in the collection +The application program only needs to insert new entries, verify and +update time on existing entries. MongoDB will maintain a list of +authenticated users on the list and delete any old entries. From 8bc3f11f0b7d36cb057c991a4870f9022e7eca24 Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Tue, 7 Aug 2012 09:52:44 -0400 Subject: [PATCH 11/17] draft 1 edits --- .../expire-least-recently-used-data.txt | 46 +++++++++++-------- 1 file changed, 28 insertions(+), 18 deletions(-) diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index e6dc4708a9e..1d98338c5b9 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -11,23 +11,31 @@ Expire Least Recently Used Data from a Collection Use Case -------- -You need to keep a list of updated items but anything not updated -should be deleted automatically. This is useful for applications that -require access control such as web-based E-mail, internet banking, -personalized web services, user account verification, etc. - +You need to keep a current list of items, which anything not current +is removed from the list. At any point in time, the list only contains +current items. +You need to keep a list of items but anything not +updated should be deleted automatically. This is useful for +applications that require access control such as web-based E-mail, +internet banking, personalized web services, user account +verification, etc. + +.. TODO rewrite - to be an authorization list For example, you want keep a list of users that are actively using the system so they do not have to repeatedly authenticate. Any users who -do not use the system for a long time will automatically be logged out +are not authorized use the system for a long time will automatically be logged out and must reauthenticate. Solution -------- -Use MongoDB's TTL collection to store this list. The application will -only insert new entries, query the collection to verify items on the -list, and update items as needed. Any items not updated for a -specified period will be deleted by the :program:`mongod` process. +.. TODO be clearer that mongodb will only see the list as a +.. document. it's upto the application to maintain the list. +Use MongoDB's TTL collection to manage the 'garbage clean up' for this +list. Your application will only insert new entries, query the +collection to verify items on the list, and update items as +needed. Any items not updated for a specified period will be deleted +by the :program:`mongod` process. For example, the application will ensure authentication and insert logged in users into the list. The application will check the list @@ -38,7 +46,7 @@ entries, which have not been updated. Requirements: -- MongoDB version 2.2 or greater for storing list. +- MongoDB version 2.2 or greater. - Application to authenticate users, and is able to access, insert, and update entries in the MongoDB collection. @@ -53,7 +61,7 @@ Pattern For this example, the logged in user list will be named: ``authLog`` to store, record, and update users who are authorized to use the system. -The ``authLog`` collection could look like the following: +An ``authLog`` collection could look like the following: .. code-block:: javascript @@ -61,7 +69,7 @@ The ``authLog`` collection could look like the following: { "_id" : ObjectId("..."), "userID" : 101, "accessTime" : ISODate("2012-08-02T17:47:27.764Z") } { "_id" : ObjectId("..."), "userID" : 102, "accessTime" : ISODate("2012-08-02T17:47:34.788Z") } -An ``authLog`` collection like the above can be created by using the following commands: +The ``authLog`` collection above can be created by using the following commands: .. code-block:: javascript @@ -76,16 +84,17 @@ work properly. Set up a TTL collection ~~~~~~~~~~~~~~~~~~~~~~~ -Set up MongoDB to index the collection's ``accessTime`` field and delete any -items that have ``accessTime`` entries older than 300 seconds or five minutes by: +Set up MongoDB to index the collection's ``accessTime`` field and +delete any items that have ``accessTime`` entries older than 300 +seconds or five minutes by: .. code-block:: javascript db.authLog.ensureIndex( { accessTime: 1 }, { expireAfterSeconds: 300 } ) -Any items in the ``authLog`` collection older than 300 seconds will -be automatically removed by the :program:`mongod` instance. The -removal duration can be adjusted by specifying a different value for +Any items in the ``authLog`` collection older than 300 seconds will be +automatically removed by the :program:`mongod` instance. The removal +duration can be adjusted by specifying a different value for ``expireAfterSeconds``. Application response @@ -138,6 +147,7 @@ that have been updated within 300 seconds will remain in the collection. Overall result ~~~~~~~~~~~~~~ +.. TODO make better summary The application program only needs to insert new entries, verify and update time on existing entries. MongoDB will maintain a list of authenticated users on the list and delete any old entries. From f20c134cc7a3467efafcbac590223a807ea4f28c Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Tue, 7 Aug 2012 11:56:38 -0400 Subject: [PATCH 12/17] added in editing notes --- draft/tutorial/expire-least-recently-used-data.txt | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index 1d98338c5b9..01fa893bc2f 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -81,13 +81,15 @@ The field used to record time, ``accessTime`` in the above example, must be an ISODate, otherwise, MongoDB's TTL functionality will not work properly. +.. TODO kill functionality + Set up a TTL collection ~~~~~~~~~~~~~~~~~~~~~~~ Set up MongoDB to index the collection's ``accessTime`` field and delete any items that have ``accessTime`` entries older than 300 seconds or five minutes by: - + .. code-block:: javascript db.authLog.ensureIndex( { accessTime: 1 }, { expireAfterSeconds: 300 } ) @@ -114,6 +116,8 @@ following command: To verify user authentication, the application can accomplish this by using operation: +.. TODO rewrite without 'this' + .. code-block:: javascript > db.authLog.find( { userID: 101 } ) From 052be7e1f703ea6a6cd3c0b0a43c155cadddb67f Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Wed, 8 Aug 2012 18:10:50 -0400 Subject: [PATCH 13/17] temp file --- .../expire-least-recently-used-data.txt | 42 ++++++++++++++----- 1 file changed, 31 insertions(+), 11 deletions(-) diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index 01fa893bc2f..f54268f6936 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -7,20 +7,40 @@ Expire Least Recently Used Data from a Collection .. versionadded:: 2.2 .. TODO add introduction +Least recently used, or LRU data retention patterns are used in simple +data caches, and are useful in number of sitautions where simple TTL +collections are not appropriate. This pattern presents some of these +cases and proides a method for maintaining a collection of documents +in MongoDB where the LRU documents are periodically removed from the +collection using the TTL collection facility. Use Case -------- +#. Authentication sessions. + + An app stores session information in database, and validates current + users' session against stored when servicing requests. + +#. Rendered page cache. + + Assemble pages from database content and store rendered page in a + collection. The page should be stored as long as the page is being + accessed by others. If not, the page should + + (time might be much longer, like a week.) + + assmeble pages from queries to the db and insert the amalgamated + page into the database. implementation might be ttl. + +.. TODO eliminate 'lists' too many. focus on 'collection' You need to keep a current list of items, which anything not current is removed from the list. At any point in time, the list only contains -current items. -You need to keep a list of items but anything not -updated should be deleted automatically. This is useful for -applications that require access control such as web-based E-mail, -internet banking, personalized web services, user account -verification, etc. - -.. TODO rewrite - to be an authorization list +current items. This is useful for applications that require access +control such as web-based E-mail, internet banking, personalized web +services, user account verification, etc. + +.. TODO rewrite - to be session / comment draft collection For example, you want keep a list of users that are actively using the system so they do not have to repeatedly authenticate. Any users who are not authorized use the system for a long time will automatically be logged out @@ -29,8 +49,8 @@ and must reauthenticate. Solution -------- -.. TODO be clearer that mongodb will only see the list as a -.. document. it's upto the application to maintain the list. +.. TODO move stuff from down here up to use case (less talking here, +.. just points for requirements is fine) Use MongoDB's TTL collection to manage the 'garbage clean up' for this list. Your application will only insert new entries, query the collection to verify items on the list, and update items as @@ -50,7 +70,7 @@ Requirements: - Application to authenticate users, and is able to access, insert, and update entries in the MongoDB collection. -Steps required: +Process: #. Set up a MongodB TTL collection. #. Application to insert, access, and update MongoDB collection. From 1ec6e63d0ac26008d0880c432c3b9a56a0a7d399 Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Thu, 9 Aug 2012 14:46:42 -0400 Subject: [PATCH 14/17] starting draft 2 --- .../expire-least-recently-used-data.txt | 48 ++++++++++++------- 1 file changed, 30 insertions(+), 18 deletions(-) diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index f54268f6936..26f3591b3fb 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -6,32 +6,43 @@ Expire Least Recently Used Data from a Collection .. versionadded:: 2.2 -.. TODO add introduction Least recently used, or LRU data retention patterns are used in simple -data caches, and are useful in number of sitautions where simple TTL -collections are not appropriate. This pattern presents some of these -cases and proides a method for maintaining a collection of documents -in MongoDB where the LRU documents are periodically removed from the -collection using the TTL collection facility. +data caches, or substitutes for stateless systems and are useful in +number of situtions where simple TTL collections are not +appropriate. + +This pattern presents some of these cases and proides a method for +maintaining a collection of documents in MongoDB where the LRU +documents are periodically removed from the collection using the TTL +collection facility. Use Case -------- -#. Authentication sessions. +- Online shopping carts + + An online store gives shoppers a virtual cart. The state of each + shopper's cart is maintained on the store's database. The cart + information is updated whenever the shopper is active at the store, + Once the shopper completes payment, the cart info is removed from + the server. If shoppers abandon their carts, contents of the cart + are removed for other shoppers to purchase. - An app stores session information in database, and validates current - users' session against stored when servicing requests. +- Authentication sessions. -#. Rendered page cache. + An app stores session information in database, and validates current + users' session when servicing requests. - Assemble pages from database content and store rendered page in a - collection. The page should be stored as long as the page is being - accessed by others. If not, the page should +- Rendered page cache. - (time might be much longer, like a week.) + Assemble pages from database content and store rendered page in a + collection. The page should be stored as long as the page is being + accessed by others. If not, the page should be deleted. - assmeble pages from queries to the db and insert the amalgamated - page into the database. implementation might be ttl. + The pages are assembled from fact database queries and the + amalgamated pages are stored on the content database. + +- .. TODO eliminate 'lists' too many. focus on 'collection' You need to keep a current list of items, which anything not current @@ -46,8 +57,6 @@ system so they do not have to repeatedly authenticate. Any users who are not authorized use the system for a long time will automatically be logged out and must reauthenticate. -Solution --------- .. TODO move stuff from down here up to use case (less talking here, .. just points for requirements is fine) @@ -64,6 +73,9 @@ access and update their access time entry, otherwise, force the user to reauthenticate. MongoDB will maintain the list and delete any entries, which have not been updated. +Solution +-------- + Requirements: - MongoDB version 2.2 or greater. From 7f5e9537faa42bf5dc223b21c3cc5d053b034eae Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Thu, 9 Aug 2012 18:47:20 -0400 Subject: [PATCH 15/17] revising new draft. --- .../expire-least-recently-used-data.txt | 126 ++++++++---------- 1 file changed, 56 insertions(+), 70 deletions(-) diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index 26f3591b3fb..7a9227e09cc 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -42,7 +42,15 @@ Use Case The pages are assembled from fact database queries and the amalgamated pages are stored on the content database. -- +- Draft comment + + Web site comments are saved on the server temporarily until the + visitor submits. If the visitor does not submit, then the comment + will be cleared from the server. + + Comments are stored in a single collection and any items with a + draft time will be monitored for updates. If the draft comments are + not updated for a period, MongoDB deletes the draft from the collection. .. TODO eliminate 'lists' too many. focus on 'collection' You need to keep a current list of items, which anything not current @@ -79,8 +87,7 @@ Solution Requirements: - MongoDB version 2.2 or greater. -- Application to authenticate users, and is able to access, insert, - and update entries in the MongoDB collection. +- Online store application that connects to MongoDB. Process: @@ -90,100 +97,79 @@ Process: Pattern ------- -For this example, the logged in user list will be named: ``authLog`` -to store, record, and update users who are authorized to use the system. +.. TODO find a better name for cartInfo + +For this example, the logged in user list will be named: ``cartInfo`` +to store, record, and update users who are authorized to use the +system. -An ``authLog`` collection could look like the following: +An ``storeCarts`` collection could look like the following: .. code-block:: javascript - { "_id" : ObjectId("..."), "userID" : 100, "accessTime" : ISODate("2012-08-02T17:47:15.275Z") } - { "_id" : ObjectId("..."), "userID" : 101, "accessTime" : ISODate("2012-08-02T17:47:27.764Z") } - { "_id" : ObjectId("..."), "userID" : 102, "accessTime" : ISODate("2012-08-02T17:47:34.788Z") } + { "_id" : ObjectId("..."), + "cartID" : 100, + "lastChange" : ISODate("2012-08-02T17:47:15.275Z"), + "cartItems": [ soap, sugar, milk ] } -The ``authLog`` collection above can be created by using the following commands: + { "_id" : ObjectId("..."), + "cartID" : 101, + "lastChange" : ISODate("2012-08-02T17:47:15.275Z"), + "cartItems": [ milk, bread, eggs ] } + + { "_id" : ObjectId("..."), + "cartID" : 102, + "lastChange" : ISODate("2012-08-02T17:47:15.275Z"), + "cartItems": [ sugar, flour, eggs ] } + +The above can be created by using the following commands: .. code-block:: javascript - > db.authLog.insert( { userID: 100, accessTime: new ISODate() }) - > db.authLog.insert( { userID: 101, accessTime: new ISODate() }) - > db.authLog.insert( { userID: 102, accessTime: new ISODate() }) + > db.store.insert( { cartID: 100, lastChange: new + ISODate(), "cartItems": [ soap, sugar, milk ] }) -The field used to record time, ``accessTime`` in the above example, -must be an ISODate, otherwise, MongoDB's TTL functionality will not -work properly. + > db.store.insert( { cartID: 101, lastChange: new + ISODate(), "cartItems": [ milk, bread, eggs ] } ) -.. TODO kill functionality + > db.store.insert( { cartID: 102, lastChange: new + ISODate(), "cartItems": [ sugar, flour, eggs ] } }) Set up a TTL collection ~~~~~~~~~~~~~~~~~~~~~~~ -Set up MongoDB to index the collection's ``accessTime`` field and -delete any items that have ``accessTime`` entries older than 300 -seconds or five minutes by: +Set up MongoDB with a TTL index to delete any carts that are older +than 86,400 seconds or 24 hours: .. code-block:: javascript - db.authLog.ensureIndex( { accessTime: 1 }, { expireAfterSeconds: 300 } ) + db.store.ensureIndex( { lastChange: 1 }, { expireAfterSeconds: 86400 } ) -Any items in the ``authLog`` collection older than 300 seconds will be -automatically removed by the :program:`mongod` instance. The removal -duration can be adjusted by specifying a different value for -``expireAfterSeconds``. +``lastChange`` is used to determine which items to be deleted. If this +field contains an entry older than 86,400 seconds, :program:`mongod` +will delete it from the collection. Application response ~~~~~~~~~~~~~~~~~~~~ -Active application input for the ``authLog`` collection is required -for new entries, verifying entries, and updating entries. - -For new entries, such as after successful user authentication, the -application must insert into the ``authLog`` collection using the -following command: - -.. code-block:: javascript - - > db.authLog.insert( { userID: 103, accessTime: new ISODate() }) - -To verify user authentication, the application can accomplish this by -using operation: - -.. TODO rewrite without 'this' +When the shopper adds or removes items from their cart, update the +document using: .. code-block:: javascript - > db.authLog.find( { userID: 101 } ) - -If the operation result is similar to: - -.. code-block:: javascript - - { "_id" : ObjectId("..."), "userID" : 101, "accessTime" : ISODate("2012-08-02T17:47:27.764Z") } - -The user is currently authenticated and may access the system. If the -result is empty, the user is not authenticated and needs to -reauthenticate. - -To update entries for authenticated users, update the ``accessTime`` -entries using the following command: - -.. code-block:: javascript - - db.authenticationLog.update( { userID: 101 }, { $set: { accessTime: new ISODate() } } ) - -This will set the ``accessTime`` field for ``userID`` 101 to the current -time. MongoDB will not delete this entry because its ``accessTime`` -field is now newer than 300 seconds. + db.store.update( { cartID: 101 }, { $set: { lastChange: new + ISODate(), items: [ ... ] } } ) -With TTL enabled, the :program:`mongod` instance will scan the -collection every minute and remove any user entries that have an -``accessTime`` greater than five minutes or 300 seconds. Any items -that have been updated within 300 seconds will remain in the collection. +It is essential to not only update the ``items`` field, but to update +``lastChange`` with the current time. This field is used by +:program:`mongod` to keep track of the document's age. Overall result ~~~~~~~~~~~~~~ -.. TODO make better summary -The application program only needs to insert new entries, verify and -update time on existing entries. MongoDB will maintain a list of -authenticated users on the list and delete any old entries. +A sample Least Recently Used TTL pattern has been demonstrated. TTL +collections have many application areas, when used with the proper +application support, they can be applied to LRU +situations. Fundamentally, setting up a LRU collection is no different +than TTL, but proper application action are necessary to maintain +expected results. From 2b67e9fd8ce72260a1f56022e80f7715fad7e319 Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Thu, 16 Aug 2012 16:59:24 -0400 Subject: [PATCH 16/17] draft 2 --- .../expire-least-recently-used-data.txt | 169 ++++++++---------- 1 file changed, 71 insertions(+), 98 deletions(-) diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index 7a9227e09cc..a2cc84577b6 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -6,170 +6,143 @@ Expire Least Recently Used Data from a Collection .. versionadded:: 2.2 -Least recently used, or LRU data retention patterns are used in simple -data caches, or substitutes for stateless systems and are useful in -number of situtions where simple TTL collections are not -appropriate. +Least recently used, or LRU, data retention patterns are used in simple +data caches or support for stateless systems. They are convenient for a +number of situtions where simple TTL collections are not enough. -This pattern presents some of these cases and proides a method for -maintaining a collection of documents in MongoDB where the LRU -documents are periodically removed from the collection using the TTL -collection facility. +This pattern presents some cases and proides a pattern for maintaining +documents in MongoDB where LRU documents are retained while others are +removed using the TTL collection feature. Use Case -------- -- Online shopping carts +- Online shopping cart - An online store gives shoppers a virtual cart. The state of each - shopper's cart is maintained on the store's database. The cart - information is updated whenever the shopper is active at the store, - Once the shopper completes payment, the cart info is removed from - the server. If shoppers abandon their carts, contents of the cart - are removed for other shoppers to purchase. + A database can be used to track shoppers' carts and items while + they're on the site. If there are any abandoned carts, the database + will clean them up and can make items available to shoppers again. -- Authentication sessions. +- Authentication sessions - An app stores session information in database, and validates current - users' session when servicing requests. + An mobile app stores session information in a database, and + validates current users' session when servicing requests. -- Rendered page cache. +- Rendered page cache - Assemble pages from database content and store rendered page in a + Assemble pages from database content and store rendered pages in a collection. The page should be stored as long as the page is being - accessed by others. If not, the page should be deleted. - - The pages are assembled from fact database queries and the - amalgamated pages are stored on the content database. + requested. - Draft comment - Web site comments are saved on the server temporarily until the - visitor submits. If the visitor does not submit, then the comment + Draft web comments are saved on the server temporarily until the + visitor submits it. If the visitor does not submit, then the comment will be cleared from the server. - Comments are stored in a single collection and any items with a - draft time will be monitored for updates. If the draft comments are - not updated for a period, MongoDB deletes the draft from the collection. - -.. TODO eliminate 'lists' too many. focus on 'collection' -You need to keep a current list of items, which anything not current -is removed from the list. At any point in time, the list only contains -current items. This is useful for applications that require access -control such as web-based E-mail, internet banking, personalized web -services, user account verification, etc. - -.. TODO rewrite - to be session / comment draft collection -For example, you want keep a list of users that are actively using the -system so they do not have to repeatedly authenticate. Any users who -are not authorized use the system for a long time will automatically be logged out -and must reauthenticate. - - -.. TODO move stuff from down here up to use case (less talking here, -.. just points for requirements is fine) -Use MongoDB's TTL collection to manage the 'garbage clean up' for this -list. Your application will only insert new entries, query the -collection to verify items on the list, and update items as -needed. Any items not updated for a specified period will be deleted -by the :program:`mongod` process. - -For example, the application will ensure authentication and insert -logged in users into the list. The application will check the list -when a user accesses the system, if the user is on the list, provide -access and update their access time entry, otherwise, force the user -to reauthenticate. MongoDB will maintain the list and delete any -entries, which have not been updated. +- Transcoded media cache + + Archival images and videos are stored in a high quality format and + transcoded to device specific formats for distribution. Caching + frequently accessed media improve overall performance and save on + computing power without creating overly complex + + setting up a list to keep track of where various transcoded versions + exist Solution -------- +Use a MongoDB TTL collection with your application to create a Least +Recently Used collection. Your application updates current items while +MongoDB automatically remove expired items. + Requirements: - MongoDB version 2.2 or greater. -- Online store application that connects to MongoDB. +- Application to connect to MongoDB. Process: +#. Collection setup. #. Set up a MongodB TTL collection. -#. Application to insert, access, and update MongoDB collection. +#. Set up a application to insert, access, and update MongoDB + collection. Pattern ------- -.. TODO find a better name for cartInfo +For an online shopping cart, MongoDB will track the shoppers' items in +the ``carts`` collection for a limited time. + +The store application needs to update the collection when: + +- the shopper accesses the site, +- adds or removes items, or +- checks out. -For this example, the logged in user list will be named: ``cartInfo`` -to store, record, and update users who are authorized to use the -system. +If the shopper leaves the site, their cart will be available for a +limited time, eventually, the cart will be removed. -An ``storeCarts`` collection could look like the following: +Collection setup +~~~~~~~~~~~~~~~~ + +The ``carts`` collection may be the following: .. code-block:: javascript { "_id" : ObjectId("..."), "cartID" : 100, "lastChange" : ISODate("2012-08-02T17:47:15.275Z"), - "cartItems": [ soap, sugar, milk ] } + "products": [ soap, sugar, milk ] } { "_id" : ObjectId("..."), "cartID" : 101, "lastChange" : ISODate("2012-08-02T17:47:15.275Z"), - "cartItems": [ milk, bread, eggs ] } + "products": [ milk, bread, eggs ] } { "_id" : ObjectId("..."), "cartID" : 102, "lastChange" : ISODate("2012-08-02T17:47:15.275Z"), - "cartItems": [ sugar, flour, eggs ] } + "products": [ sugar, flour, eggs ] } -The above can be created by using the following commands: +The ``carts`` collection can be created by using the following commands: .. code-block:: javascript - > db.store.insert( { cartID: 100, lastChange: new - ISODate(), "cartItems": [ soap, sugar, milk ] }) - - > db.store.insert( { cartID: 101, lastChange: new - ISODate(), "cartItems": [ milk, bread, eggs ] } ) - - > db.store.insert( { cartID: 102, lastChange: new - ISODate(), "cartItems": [ sugar, flour, eggs ] } }) + db.carts.insert( { cartID: 100, lastChange: new ISODate(), products: [ "soap", "sugar", "milk" ] }) + db.carts.insert( { cartID: 101, lastChange: new ISODate(), products: [ "milk", "bread", "eggs" ] } ) + db.carts.insert( { cartID: 102, lastChange: new ISODate(), products: [ "sugar", "flour", "eggs" ] } ) Set up a TTL collection ~~~~~~~~~~~~~~~~~~~~~~~ -Set up MongoDB with a TTL index to delete any carts that are older -than 86,400 seconds or 24 hours: +The following command will set :program:`mongod` to monitor the +``lastChange`` field and delete any documents that are older than +86,400 seconds or 24 hours: .. code-block:: javascript - db.store.ensureIndex( { lastChange: 1 }, { expireAfterSeconds: 86400 } ) - -``lastChange`` is used to determine which items to be deleted. If this -field contains an entry older than 86,400 seconds, :program:`mongod` -will delete it from the collection. + db.carts.ensureIndex( { lastChange: 1 }, { expireAfterSeconds: 86400 } ) Application response ~~~~~~~~~~~~~~~~~~~~ -When the shopper adds or removes items from their cart, update the -document using: +To keep any documents in the collection, update the ``lastChange`` +field with a newer date. The following command will update the time of +``lastChange`` of cart ``101`` and add an item to the ``products`` list. .. code-block:: javascript - db.store.update( { cartID: 101 }, { $set: { lastChange: new - ISODate(), items: [ ... ] } } ) - -It is essential to not only update the ``items`` field, but to update -``lastChange`` with the current time. This field is used by -:program:`mongod` to keep track of the document's age. + db.carts.update( { cartID: 101 }, { $set: { lastChange: new ISODate(), products: [ "milk", "bread", "eggs", "banana" ] } } ) Overall result ~~~~~~~~~~~~~~ -A sample Least Recently Used TTL pattern has been demonstrated. TTL -collections have many application areas, when used with the proper -application support, they can be applied to LRU -situations. Fundamentally, setting up a LRU collection is no different -than TTL, but proper application action are necessary to maintain -expected results. +Any documents in a TTL collection that is updated properly will remain +in the collection, while others will be deleted by +:program:`mongod`. Your application will only have to perform simple +updates to individual documents. + +With basic application updates, any TTL collection can easily become a +Least Recently Used collection. From 17c4f67f4d0a73b5e208870b6d5d2048a564aa45 Mon Sep 17 00:00:00 2001 From: Andrew Leung Date: Fri, 17 Aug 2012 10:17:31 -0400 Subject: [PATCH 17/17] minor revision --- .../tutorial/expire-least-recently-used-data.txt | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/draft/tutorial/expire-least-recently-used-data.txt b/draft/tutorial/expire-least-recently-used-data.txt index a2cc84577b6..131d64780f6 100644 --- a/draft/tutorial/expire-least-recently-used-data.txt +++ b/draft/tutorial/expire-least-recently-used-data.txt @@ -7,8 +7,8 @@ Expire Least Recently Used Data from a Collection .. versionadded:: 2.2 Least recently used, or LRU, data retention patterns are used in simple -data caches or support for stateless systems. They are convenient for a -number of situtions where simple TTL collections are not enough. +data caches or support for stateless systems. By extending TTL +collections with application support provides additional features. This pattern presents some cases and proides a pattern for maintaining documents in MongoDB where LRU documents are retained while others are @@ -43,13 +43,11 @@ Use Case - Transcoded media cache Archival images and videos are stored in a high quality format and - transcoded to device specific formats for distribution. Caching - frequently accessed media improve overall performance and save on - computing power without creating overly complex - - setting up a list to keep track of where various transcoded versions - exist - + transcoded to device specific formats for distribution. Keeping + lists of frequently accessed media in cache and transcoding archive + materials on demand can provide excellent application response while + maximizing resources. + Solution --------