"Out of date"-Technical implementation of life-cycle data

"Out of date"-technical implementation of data with life Cycle 1 Introduction

This article can be used as a technical implementation part of a previous theoretical article .

Here is a direct elevator to the above:

Http://www.cnblogs.com/beer/p/6029861.html

Design of multi-platform identity authentication architecture based on token

2 Data life cycle

The so-called "data lifecycle" means that a certain lifetime is set for the data, and after that time the data is deleted (invalidated).

When it comes to web development, there are many requirements scenarios where data is required to have a certain life cycle, such as:

• User logon session with a certain limitation
• The aging control of the invitation code system
• Time-lapse QR code/SMS/Email Verification System
• Interface Call Authentication token validity
• Term control of third party authorizations
• Time-lapse control for shared content
• Log records for a period of time

This article will introduce the implementation of this feature in the following two database features as an example:

• Mongodb
• Redis

3 mongodb3.1 Implementation method

There is a TTL (Time to live Lifetime) index feature in MongoDB:

The TTL index is a special index in which MongoDB will automatically remove documents from the collection after a certain period of time. This is an ideal feature for certain types of information, such as machine-generated event data, logs, session information, and so on, which require only a limited amount of time to be stored in the database.

• If you could set the life cycle, it would be deleted automatically after that time.
• The period of deletion is about one minute (related to the load of the MongoDB service), and the MongoDB daemon periodically checks these indexed fields

How to implement in MongoDB :

Db.ttl_log_session.createIndex ({"LastModifiedDate": 1}, {expireafterseconds:3600})

The main explanations are as follows:

• Indexing ttl_log_session Collections
• Index field lastmodifieddate
• Index order is ascending
• Effective life cycle is 3600 seconds

The result: This document will be deleted after 3600 seconds, starting with the lastmodifieddate moment.

3.2 Expiration Time Accuracy

Some considerations for deleting operations:

• TTL index does not guarantee that expired data will be deleted immediately

  There may be a delay between document expiration and MongoDB's deletion of documents from the database.

• Background task to delete outdated data runs every 60 seconds

  The document will still exist in the collection after the document expires and before the background task runs or ends (the delete operation has not yet completed).

• The duration of the delete operation actually depends on the load of your Mongod instance

  The expired data may remain in the database for more than 60 seconds between the intervals that the two background tasks run.

4 Redis

Redis is an in-memory database that features fast IO. The performance will be significantly higher than MongoDB.

4.1 Implementation Methods

By the following means:

EXPIRE Key seconds

Sets the time-to-live for a given key, which is automatically deleted when key expires (survival time is 0).

Here are some basic operations related to setting the time to live:

Redis> set Cache_page "www.google.com"okredis> EXPIRE cache_page  # Set Expiration time is1Redis > TTL cache_page    redis> EXPIRE cache_page 30000   1redis>  29996

Precautions:

• The time-to-live can be removed by using the DEL command to remove the entire key, or by the SET and Getset commands (overwrite)
• If you rename a key using RENAME, the renamed Key has the same life time as before
• Renaming a key with a time-to-live to another another_key with a time-to-live, the old Another_key (and its lifetime) will be deleted, and the old key will be renamed to Another_key

4.2 Expiration Time Accuracy

• In the Redis 2.4 release, the latency of the expiration time is within 1s

  Even if the key has expired, it may be accessed within one second after it expires

• In the new Redis 2.6 release, the delay is reduced to within 1ms

5 Summary

In the process of web development, many occasions need to use the data lifecycle function. For the implementation of this function, you can refer to the following conclusions before the appropriate technology selection:

The main conclusions of this article on the "Data Lifecycle" topics are as follows:

• You can do some timing tasks on the Web application layer, but that's not as efficient as working directly at the database level.
• The In-memory database (Reids) is much better than the disk database (MongoDB) and can be up to 60,000 times times more control over the expiration time accuracy.

In the selection of technology to pay attention to the following several characteristics of the comparison:

1. IO speed
2. Data persistence
3. Backup and replication set of data
4. The use of databases for multi-core
5. The cost and difficulty of deploying a DB cluster
6. Cost and difficulty of development

In the end, we can get the appropriate technical solution and realize the function of our system.

Author:	Harmo ha mo
Author Introduction:	Https://zhengwh.github.io
Technical Blog:	Http://www.cnblogs.com/beer
Email:	[Email protected]
Qq:	1295351490
Time:	2016-02
Copyright Notice:	Welcome to learn to exchange for the purpose of the reader to reprint, but please "annotated source"
Support this article:	If you are inspired by the article, you can click the button in the lower right corner of the blog to "recommend"

"Out of date"-Technical implementation of life-cycle data