2012-08-27 5 views
1

MongoDB (및 첫 번째 NoSQL) 데이터베이스를 디자인 중이며 파일에 대한 정보를 컬렉션에 저장하려고합니다. 각 파일 문서의 일부로 파일 액세스 로그 (읽기 및 쓰기)를 저장하려고합니다.MongoDB로 파일 액세스 로깅

것은 나는 문서의 한 부분으로 로그 메시지의 배열을 만들 생각했다 :

{ 
    "filename": "some_file_name", 
    "logs" : [ 
     { "timestamp": "2012-08-27 11:40:45", "user": "joe", "access": "read" }, 
     { "timestamp": "2012-08-27 11:41:01", "user": "mary", "access": "write" }, 
     { "timestamp": "2012-08-27 11:43:23", "user": "joe", "access": "read" } 
    ] 
} 

각 로그 메시지는 타임 스탬프, 액세스 유형, 파일에 액세스하는 사람의 이름이 포함됩니다. 나는 이것이 특정 파일에 대한 로그에 매우 빠르게 액세스 할 수 있으며 로그와 함께 수행되는 가장 일반적인 작업이라고 생각했습니다.

MongoDB의 문서 크기 제한은 16Mbyte입니다. 매우 자주 액세스되는 파일이이 한계에 부딪 힐 수 있다고 생각합니다.

이 유형의 로깅을 위해 NoSQL 스키마를 설계하는 더 좋은 방법이 있습니까?

+0

하나의 대안은 별도의 컬렉션'logs'입니다 (각 항목은 참조하는 파일 이름을가집니다). – Thilo

답변

2

같은 것하는 파일을 찾을 수 쿼리 :

타임 스탬프 단어를 = 18 , 시간 소인 값 = 8, 사용자 단어 = 8, 사용자 값 = 20 (최대 10 개 (최소 10 자)), 액세스 단어 = 12, 액세스 값 10입니다. 따라서 총계는 76 바이트입니다. 그래서 ~ 220000 개의 로그 레코드를 가질 수 있습니다.

실제 공간의 절반은 필드 이름으로 사용됩니다. timestamp = t, user = u, access = a라는 이름을 지정할 경우 ~ 440000 개의 로그 항목을 저장할 수 있습니다.

그래서 대부분의 시스템에서는 충분하다고 생각합니다. 내 프로젝트에서 나는 항상 mongodb를 사용하여 좋은 성능을 얻을 수있는 방법이기 때문에 별도의 컬렉션을 만들지 않고 임베드하려고했습니다.

향후 로그 레코드를 별도의 컬렉션으로 이동할 수 있습니다. 또한 성능 향상을 위해 로그 파일 외에도 빠른 검색을 위해 파일 문서에 30 개의 마지막 로그 레코드 (단순한 비정규 파일)를 가질 수 있습니다.

또한 컬렉션이 하나 인 경우 필요한 경우 로그를로드하지 않도록하십시오 (mongodb에 필드를 포함하거나 제외 할 수 있음). 또한 페이징을 수행하려면 $slice을 사용하십시오.

마지막으로 한 가지 : Enjoy mongo!

+1

나는 이것이 오히려 나쁜 충고라고 생각한다. 임베디드 어레이는 항상 커질 수 없습니다. 이로써 적절한 위치에서의 업데이트가 불가능하게되고, 이러한 거대한 개체로 인한 비표준 업데이트가 특히 비쌉니다. 단일 76 바이트 추가는 멀티 MB 작업으로 끝날 수 있습니다. – Thilo

2

문서 한도가 문제가되는 것으로 생각되면 몇 가지 대안이 있습니다.

분명한 것은 로그마다 새 문서를 만드는 것입니다.

그러면 collecton이 "로그"가됩니다. 이 스키마.

{ 
    "filename": "some_file_name", 
    "timestamp": "2012-08-27 11:40:45", 
    "user": "joe", 
    "access": "read" 
} 

먼저 하나의 로그 레코드의 평균 크기를 계산하려고하자 "조"읽기는

db.logs.find({user: "joe", access: "read"})