mongo - TTL

DB/MongoDB 2014. 1. 15. 16:34


Expire Data from Collections by Setting TTL

New in version 2.2.

This document provides an introduction to MongoDB’s “time to live” or “TTL” collection feature. TTL collections make it possible to store data in MongoDB and have themongod automatically remove data after a specified number of seconds or at a specific clock time.

Data expiration is useful for some classes of information, including machine generated event data, logs, and session information that only need to persist for a limited period of time.

A special index type supports the implementation of TTL collections. TTL relies on a background thread in mongod that reads the date-typed values in the index and removes expired documents from the collection.

Considerations

  • The _id field does not support TTL indexes.
  • You cannot create a TTL index on a field that already has an index.
  • A document will not expire if the indexed field does not exist.
  • A document will not expire if the indexed field is not a date BSON type or an array of date BSON types.
  • The TTL index may not be compound (may not have multiple fields).
  • If the TTL field holds an array, and there are multiple date-typed data in the index, the document will expire when the lowest(i.e. earliest) date matches the expiration threshold.
  • You cannot create a TTL index on a capped collection, because MongoDB cannot remove documents from a capped collsection.
  • You cannot use ensureIndex() to change the value of expireAfterSeconds. Instead use the collMod database command in conjunction with the index collection flag.
  • When you build a TTL index in the background, the TTL thread can begin deleting documents while the index is building. If you build a TTL index in the foreground, MongoDB begins removing expired documents as soon as the index finishes building.

When the TTL thread is active, you will see delete operations in the output of db.currentOp() or in the data collected by thedatabase profiler.

When using TTL indexes on replica sets, the TTL background thread only deletes documents on primary members. However, the TTL background thread does run on secondaries. Secondary members replicate deletion operations from the primary.

The TTL index does not guarantee that expired data will be deleted immediately. There may be a delay between the time a document expires and the time that MongoDB removes the document from the database.

The background task that removes expired documents runs every 60 seconds. As a result, documents may remain in a collection after they expire but before the background task runs or completes.

The duration of the removal operation depends on the workload of your mongod instance. Therefore, expired data may exist for some time beyond the 60 second period between runs of the background task.

All collections with an index using the expireAfterSeconds option have usePowerOf2Sizes enabled. Users cannot modify this setting. As a result of enabling usePowerOf2Sizes, MongoDB must allocate more disk space relative to data size. This approach helps mitigate the possibility of storage fragmentation caused by frequent delete operations and leads to more predictable storage use patterns.

Procedures

To enable TTL for a collection, use the ensureIndex() method to create a TTL index, as shown in the examples below.

With the exception of the background thread, a TTL index supports queries in the same way normal indexes do. You can use TTL indexes to expire documents in one of two ways, either:

  • remove documents a certain number of seconds after creation. The index will support queries for the creation time of the documents. Alternately,
  • specify an explicit expiration time. The index will support queries for the expiration-time of the document.

Expire Documents after a Certain Number of Seconds

To expire data after a certain number of seconds, create a TTL index on a field that holds values of BSON date type or an array of BSON date-typed objects and specify a positive non-zero value in the expireAfterSeconds field. A document will expire when the number of seconds in the expireAfterSeconds field has passed since the time specified in its indexed field.[1]

For example, the following operation creates an index on the log.events collection’s createdAt field and specifies theexpireAfterSeconds value of 3600 to set the expiration time to be one hour after the time specified by createdAt.

db.log.events.ensureIndex( { "createdAt": 1 }, { expireAfterSeconds: 3600 } )

When adding documents to the log.events collection, set the createdAt field to the current time:

db.log.events.insert( {
   "createdAt": new Date(),
   "logEvent": 2,
   "logMessage": "Success!"
} )

MongoDB will automatically delete documents from the log.events collection when the document’s createdAt value [1] is older than the number of seconds specified in expireAfterSeconds.

[1](12) If the field contains an array of BSON date-typed objects, data expires if at least one of BSON date-typed object is older than the number of seconds specified in expireAfterSeconds.

<<<<<<< HEAD Expire at a Certain Clock Time ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ======= .. seealso:: $currentDateoperator

Expire Documents at a Certain Clock Time

>>>>>>> 9ba5a55... DOCS-2437 and DOCS-2194 edits

To expire documents at a certain clock time, begin by creating a TTL index on a field that holds values of BSON date type or an array of BSON date-typed objects and specify an expireAfterSeconds value of 0. For each document in the collection, set the indexed date field to a value corresponding to the time the document should expire. If the indexed date field contains a date in the past, MongoDB considers the document expired.

For example, the following operation creates an index on the app.events collection’s expireAt field and specifies theexpireAfterSeconds value of 0:

db.app.events.ensureIndex( { "expireAt": 1 }, { expireAfterSeconds: 0 } )

For each document, set the value of expireAt to correspond to the time the document should expire. For instance, the following insert() operation adds a document that should expire at July 22, 2013 14:00:00.

db.app.events.insert( {
   "expireAt": new Date('July 22, 2013 14:00:00'),
   "logEvent": 2,
   "logMessage": "Success!"
} )

MongoDB will automatically delete documents from the app.events collection when the documents’ expireAt value is older than the number of seconds specified in expireAfterSeconds, i.e. 0 seconds older in this case. As such, the data expires at the specified expireAt value.



출처 - http://docs.mongodb.org/manual/tutorial/expire-data/






mongodb ttl collection 사용에 관하여(pymongo 추가)

IT아저씨 Barracuda | 2012/11/10 15:09 | DBMS

 

[mongodb client UI]


MongoDB 2.2.x 2.1.2 부터 TTL(Time To Live) 기능이 제공되고 있다. IT에 익숙한 분이라면 icmp, DNS, cache server 등의 프로토콜이나 설정/작동 방법상에서 자주 나타나는 용어라는 것을 알 수 있으리라.


mongodb에서의 이 기능은 단순하게 설명하자면, 지정된 시간 이전의 레코드를 자동으로 지우는(purging, removing) 기능이다. 주로 통계성 데이터나 모니터링 데이터 등 시계열 데이터가 저장되어 있을 경우나 일정 시간 동안만 저장되어야 하는 session 정보 등을 저장하는데 유용하게 사용할 수 있겠다.

중요한 주의사항 몇 가지를 아래에 정리해 두고 테스트를 진행해 본다.
  1. mongodb의 Date 에 해당하는 날짜시간 데이터가 저장되는 필드가 필요하고, 여기에 ensureIndex로 인덱스를 두는 방식이다
  2. 해당 필드는 다른 index 에 복합적으로 참조되지 않아야 한다(단일 필드, 단일 인덱스)
  3. 해당 필드에는 위 1번에서 처럼 Date BSON type의 데이터가 UTC 기준으로 저장되어야 자동으로 지워진다
  4. mongodb의 ttl thread는 1분단위로 동작한다. 즉 10초로 설정한다고 데이터 저장 후 10초만에 지워지는 것이 아니라 1분 가량의 오차가 존재하며, DB 시스템의 부하 정도(mongod의 workload가 얼마나 큰지)에 따라 달라질 수 있다는 즉, 정확히 해당 시간 경과후 지워진다는 보장은 없다는 것.
  5. 모든 컬렉션의 공통 필드인 _id 필드는 ttl 필드로 사용할 수 없다.
  6. capped collection은 ttl index를 적용할 수 없다.

각설하고, 아래와 같이 간단히 테스트 해 본다

> db.tt_col.save( { id: 'id1', name: 'aaa', dt: new Date() } );
> db.tt_col.save( { id: 'id2', name: 'bbb', dt: new Date() } );
> db.tt_col.save( { id: 'id3', name: 'ccc', dt: new Date() } );
> db.tt_col.find();
{ "_id" : ObjectId("509de58b1493b98702441310"), "id" : "id1", "name" : "aaa", "dt" : ISODate("2012-11-10T05:26:35.370Z") }
{ "_id" : ObjectId("509de5ac1493b98702441311"), "id" : "id2", "name" : "bbb", "dt" : ISODate("2012-11-10T05:27:08.218Z") }
{ "_id" : ObjectId("509de5ba1493b98702441312"), "id" : "id3", "name" : "ccc", "dt" : ISODate("2012-11-10T05:27:22.450Z") }
> db.tt_col.ensureIndex( {dt: 1}, {expireAfterSeconds: 10} );
> db.tt_col.find();
{ "_id" : ObjectId("509de58b1493b98702441310"), "id" : "id1", "name" : "aaa", "dt" : ISODate("2012-11-10T05:26:35.370Z") }
{ "_id" : ObjectId("509de5ac1493b98702441311"), "id" : "id2", "name" : "bbb", "dt" : ISODate("2012-11-10T05:27:08.218Z") }
{ "_id" : ObjectId("509de5ba1493b98702441312"), "id" : "id3", "name" : "ccc", "dt" : ISODate("2012-11-10T05:27:22.450Z") }
잘 보면 날짜/시간 부분이 localtime이 아닌 UTC 기준시간으로 저장되어 있음에 유의한다.

약 40초 후에 컬렉션의 데이터를 조회해 보니 3건의 데이터가 삭제되어 있음을 확인할 수 있다. 
> db.tt_col.find().count();
0
> db.tt_col.find();
>


응용할 수 있는 트릭이라면, 지워지게 하고 싶지 않은 데이터가 있을 경우 어떨게 하면 될까?


한 가지 방법은 보관이 필요한 데이터를 찾아서 ttl 설정 필드 값을 Date() 로 update하는 것이다. 만약 계속 보존처리를 해야 한다면 매번 update를 수행해야 할 것이고,

계속 보존해야 한다면, 단순하게도 다음과 같이 ttl 필드를 Date가 아닌 다른 데이터 값으로 설정하면 된다.

> db.tt_col.update( { id: 'id1' }, { dt: null } );


[pymongo 2.3]

사용 방법은 유사하지만 python 내에서 ttl 기능 설정/사용시에 유의할 사항이 있다. 아래 예시의 함정을 찾아 보자.


Python 2.7.2 (default, Aug 19 2011, 20:41:43) [GCC] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> import pymongo

>>> from datetime import datetime, date, time, timedelta

>>> datetime.now()

datetime.datetime(2012, 11, 2, 2, 3, 50, 18750)

>>> pyMongoConnStr = 'mongodb://10.10.10.70:28017/myschema'

>>> connMongo = pymongo.Connection( pyMongoConnStr )

>>> connMongo.myschema.tt_col.save( { 'a':1, 'b':2, 'dt': datetime.now() } )
ObjectId('50aa68a94422527639f91a34')
>>> connMongo.monitor.t_col.ensure_index( 'dt', pymongo.ASCENDING, expireAfterSeconds = 15 )
>>> connMongo.myschema.tt_col.find_one()
{u'a': 1, u'dt': datetime.datetime(2012, 11, 2, 2, 13, 13, 517000), u'_id': ObjectId('50aa68a94422527639f91a34'), u'b': 2}


15초 가량 후에 해당 row가 삭제되어야 하는데, 10분이 지나도 멀쩡하게 남아 있다. index 설정을 봐도 잘못 된게 없고, 시스템 시간도 정확하게 현재시간을 가리키고 있는데, ...


결론을 말하자면, 위에서 등록한 row는 한국 시간으로 9시간 가량 후에 지워질 것이다. 왜냐하면 mongodb의 ttl thread 는 UTC 를 기준으로 작동하는데, python에서 mongodb에 등록한 데이터(row)에서 dt 필드의 값인 datetime.now() 는 KST(대한민국표준시; 또는 시스템 시간이 localtime) 기준의 시간 값이기 때문이다. 즉 python에서 ttl index 필드의 시간 값을 설정할 때는 반드시 datetime.utcnow() 를 사용하여야만 한다. 이점 유의하자.



출처 - http://bryans.tistory.com/m/post/view/id/79















'DB > MongoDB' 카테고리의 다른 글

mongodb - User Privilege Roles  (0) 2014.02.23
mongodb - backup  (0) 2014.02.23
mongodb - 콜렉션 필드 형변환 (How to change the type of a field)  (0) 2013.10.07
mongodb - Query, Update and Projection Operators  (0) 2013.07.23
mongodb - GridFS  (0) 2013.06.18
Posted by linuxism
,


초기화 벡터 ( 영어 : initialization vector, IV )는 비트 라인이며, 스트림 암호 또는 블록 암호 를 임의의 암호화 사용 모드 에서 실행할 때 동일한 암호화 키 스트림을 생성해서 매번 다른 스트림을 생성하기 위하여 요구된다. 그러면 매번 암호 키를 바꾸는 등 시간이 걸리는 작업을 줄일 수있다.

IV의 크기는 사용하는 암호화 알고리즘과 암호화 프로토콜에 따라 일반적으로 암호의 블록 크기와 같거나 암호화 키와 같은 크기이다. IV는 수신자가 암호를 해독하는 데 필수적이다. IV를 전달하는 방법으로는 키 교환 및 핸드 셰이크에 동의 한 후 패킷과 함께 IV 쓰기 또는 IV의 계산 방법을 공유 두거나 현재 시간과 같은 증분 측정 값 ( RSA SecurID , 바스코 Digipass 등의 하드웨어 인증 토큰)와 보낸 사람 또는받는 사람의 ID 파일 ID 패킷 섹터 번호와 클러스터 번호 등을 매개 변수로 사용한다. 프로토콜에 따라 여러 변수를 조합하거나 해시 함수 를 사용한다. IV를 무작위 로 선택한 경우 충돌 가능성을 고려해야, 증분 IV를 nonce로 사용하는 경우 관련 IV 공격에 대한 내성을 고려해 둘 필요가있다.

블록 암호 편집 ]

블록 암호 와 스트림 암호 는 IV의 구현은 다르다. 직접적인 블록 암호 또는 ECB 모드에서는 동일한 평문을 같은 키로 암호화하면 동일한 암호문이 보안에 큰 위협이된다. 따라서 IV를 일반 텍스트의 첫 번째 블록에 선형 가산 (또는 XOR )하거나 운영 모드에 따라 평문 전에 IV를 포함 두어 암호화한다.

스트림 암호 편집 ]

스트림 암호는 IV가 키 스트림의 초기 값으로 암호화 장치로 설정된 첫 번째 비트를 출력하기 전에 여러 번 암호화 장치를 돈다. 성능을 향상시키기 위해이 사전에 도는 횟수는 가능한 한 적게되도록 설계한다. 그러나 최소 횟수를 요구하는 것은 쉬운 일이 아니라 엔트로피 손실 암호 생성 당 고유성 스트림 암호의 보안 문제가 관련 IV 공격 및 IV 관련 공격 등을 고려하여야한다. 따라서 스트림 암호의 IV는 중요한 문제이며, 현재도 연구가 활발히 이루어지고있다.

WEP 편집 ]

IEEE 802.11 의 암호화 알고리즘 으로 WEP (Wired Equivalent Privacy)가 있지만, WEP 사용하는 IV는 "약하게"쉽게 해석 가능하다 [1] . 스푸핑 패킷 주입하여 WEP는 5 분 이내에 해독 할 수있다. 따라서 WEP는 급속히 쇠퇴했다.

관련 항목 편집 ]

각주 편집 ]

  1. Nikita Borisov, Ian Goldberg, David Wagner. Intercepting Mobile Communications : The Insecurity of 802.11 2006 년 9 월 12 일 보기. .

참고 문헌 편집 ]

  • B. Schneier 'Applied Cryptography', Wiley 1996
  • N. Ferguson and B. Schneier 'Practical Cryptography', Wiley 2003



출처 - http://ja.wikipedia.org/wiki/%E5%88%9D%E6%9C%9F%E5%8C%96%E3%83%99%E3%82%AF%E3%83%88%E3%83%AB



'Security > Common' 카테고리의 다른 글

shiro - 쿠키(Cookie) 인증 처리  (0) 2013.12.31
SAML 이해  (0) 2013.12.29
openid - 개념  (0) 2013.06.15
SOCKet Secure (SOCKS)  (0) 2013.04.02
crytography - key  (0) 2012.12.24
Posted by linuxism
,

web - HATEOAS

Web/Common 2014. 1. 12. 10:43


HATEOAS, an abbreviation for Hypermedia as the Engine of Application State, is a constraint of the REST application architecture that distinguishes it from most other network application architectures. The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. In a service-oriented architecture (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language (IDL).

RESTful service can be described as well to be available for the client code-generation, RSDL (RESTful Service Description Language) using dynamic metadata collection to achieve this goal.

The HATEOAS constraint serves to decouple client and server in a way that allows the server to evolve functionality independently.

Details[edit]

A REST client enters a REST application through a simple fixed URL. All future actions the client may take are discovered within resource representations returned from the server. The media types used for these representations, and the link relations they may contain, are standardized. The client transitions through application states by selecting from the links within a representation or by manipulating the representation in other ways afforded by its media type. In this way, RESTful interaction is driven by hypermedia, rather than out-of-band information.[1]

A client does not need to understand every media type and communication mechanism offered by the server and this understanding may be improved on the fly through "code-on-demand" provided to the client by the server.[2]

Origins[edit]

The HATEOAS constraint is an essential part of the "uniform interface" feature of REST, as defined in Roy Fielding's doctoral dissertation.[2] Fielding has further described the concept on his blog.[1]

The purpose of some of the strictness of this and other REST constraints, Fielding explains, is "software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design".[1]

References[edit]

  1. Jump up to:a b c Fielding, Roy T. (20 Oct 2008). "REST APIs must be hypertext-driven". Retrieved 20 May 2010.
  2. Jump up to:a b "Representational State Transfer (REST)"



출처 - http://en.wikipedia.org/wiki/HATEOAS






The point of HATEOAS is that you are getting links on other resources from responses on your requests. Difference, in comparison with URL Templates, is that the client knows, has hardwired, just few URLs (entry points), and the rest of URLs is getting from responses on the fly. It brings loose coupling between client and server and that's main benefit of HATEOAS.

Working with HATEOAS is same as surfing on Web, you just click on a link that is included in last response (e.g. HTML page), then again, and again. Point is that you don't know all the URLs before you get first response on URL that you know, the entry point.

Today, HATEOAS is not well adopted, unfortunately. Most of APIs are publishing URL templates, and that means tight coupling; so I think you cannot expect support from existing frameworks now, but it's not so hard to implement your own URL repository, on client, that will collect URLs from responses you get.

share|improve this answer
2 
Ok i understand better the philosophy. But i think that the client side is the most difficult part of HATEOAS, the server side is more easy to make. Thx for your reply. –  Thomas Pons Apr 12 '13 at 15:48



출처 - http://stackoverflow.com/questions/15972843/where-can-i-find-a-practical-hateoas-javascript-client-example/15974431#15974431


'Web > Common' 카테고리의 다른 글

웹 페이지 속도 개선  (0) 2014.03.18
web - tomcat gzip config  (0) 2014.02.07
web - SPDY  (0) 2014.01.09
해상도  (0) 2013.11.19
ie - 저장된 페이지의 새 버전 확인 > 자동 설정 상태에서 클라이언트 캐싱 제어  (0) 2013.10.09
Posted by linuxism
,