2012-08-06 2 views
1

내 웹 사이트는 통지 시스템입니다. facebook과 같은 알림 시스템. 또는 stackoverflow. 문제가 있습니다.nodejs 알림 시스템

  1. DB에 저장하는 방법은 무엇입니까? 사용자 문서에 모든 알림을 저장할 수 있습니까? 또는 떨어져 문서 (왜냐하면 내가 monogdb는 문서의 크기에 대한 제한이 있다고 생각하기 때문에?) 또는 지능적으로 저장? (inc 또는 db (값 : true/false 참조)를 사용하여 쿼리가 정교 해짐)

  2. 페이지를 가져 오는 방법은 무엇입니까? 예를 들어, 내 inbox에있는 링크를 클릭하여 stackoverflow을 클릭하면 해당 페이지로 리디렉션됩니다. 하지만 나, 나는 에 대한 multipage 시스템을 가지고있다. : 나는 100 명의 친구가있다. 페이지 당 30 개의 목록이 있습니다. 따라서 알림을 클릭하면 리디렉션 할 수 없습니다. 좋은 페이지를 알 수 없으므로 (사용자는 삭제할 수 있기 때문입니다)

대단히 감사합니다. 다른 아이디어가 있다면 알려주세요. 감사.

편집 :

(내 영어 죄송합니다, 난 프랑스어 해요) 첫 번째 문제를 들어

, 나는 시간 내 구조를 선택하는 온다 기다릴 필요가 있음을 알고 있습니다. 내 통보가 좀 복잡하기 때문에 감정에 전진해라.

둘째로, 나는 문제를 해결했다.

{ 
    friends: [ 
    {_id: xxxxx, ts: xxxx}, 
    {_id: xxxxx, ts: xxxx} 
    ] 
} 

내가 모든 친구를 표시 상상 : 내가 이렇게 내 데이터를 저장 이 (가 알아 보았 쉽게이기 때문에 친구의 exemple을.) : 나는 설명 페이지 당 30. 문제는 다음과 같습니다.

  • mongo를 사용하여 정렬 할 수없는 모든 친구를 표시하고 싶습니다. (약간의 문제)
  • 친구를 특별한 친구로이 목록 (페이지 당 30 개)으로 안내하려면 항상 sortts 개로 유지하십시오. 나는 그 페이지를 알 수 없다. 유니 솔루션은 모든 문서를 가져가는 것입니다. 하지만 성능이 매우 좋지 않습니다.

그래서, 나는이 같은 저장 :

{ 
    friends: { 
    xxxx: {ts:xxx}, 
    xxxx: {ts:xxx} 
    } 
} 

내가 문서를 정렬 할 수 있습니다 알고, 사용과 생략하고 제한. 내가 원하는 부분을 원한다면 모든 문서를 가져갈 필요가 없습니다.

페이지를 알기 위해서는 < 또는>에 해당하는 숫자를 입력하십시오.> 예를 들어 11 명의 친구를 사귀고 싶은 친구들에게> 모든 친구 (예 : : 50 친구) 50과 11, 나는 페이지를 추측 할 수있다.

이 해결책이 좋습니까? - 난 카운트 필요 -의 수를 알 수있는 쿼리> 또는 < 을 그리고 난 내가 수를 사용하는 이유 당신이 이해하지 못하는 수 the sort ts

유지, 친구를 나열된 페이지를 취할 수 있습니다. 그들은 같은 문서에 저장하지 않기 때문에 필요합니다.

2 편집 :

이 솔루션의 문제는, 내가 query object을해야하고 mongo query (예의 update object 외부 있다는 것입니다 : friends.xxxxxx: {$exists:true}

추신을 위해 : 그리고 이점 사용할 수 있습니다 MongoDB를위한 ts 대신 date? 나는 ts을 사용하고 있습니다하지만 난 date을 저장합니다 생각하지, 더 ts.

,691,363 (210)

3 EDIT

나는 Sammaye 같이 할 것입니다. 별도의 문서에 보관하십시오. 다음을보십시오 : http://mongly.com/Multiple-Collections-Versus-Embedded-Documents/#1 and http://openmymind.net/2012/1/30/MongoDB-Embedded-Documents-vs-Multiple-Collections/

답변

3

@Stennie는 완전한 대답을합니다.

그러나 최근 나는 내 웹 사이트에서 PHP와 비슷한 작업을 수행했습니다. 이해해야 할 첫 번째 사항은 알림 시스템 또는 벽 (두 가지가 매우 다른 것) 중 어떤 것이 든 내게 불분명 한 것인가하는 것입니다. 귀하가 무엇을 의미하는지 확실하지 않습니다.

어떻게 가져 왔습니까? 그 페이지 ? 예를 들어, stackoverflow에 대한 내받은 편지함의 링크를 클릭하면 페이지로 리디렉션됩니다. 하지만 나, 내가 예를 들어 여러 페이지에있는 시스템을 가지고 : 나는 100 친구가 있습니다. 여기에 가 30 페이지에 있습니다. 따라서 알림을 클릭하면 로 리디렉션 할 수 없습니다. 좋은 페이지를 알 수 없기 때문에 (사용자 은 삭제할 수 있습니다).

영어가 그리 좋지 않아서 읽을 때 혼란 스럽습니다. 당신이 그것을 확장 할 수 있다면 사람들이 더 잘 대답 할 수있을 것이라고 확신합니다.

알림 시스템의 경우 많은 알림 개체 모음도 작동하는 것으로 나타났습니다. 그래서 나는 다음과 같은 스키마를 가졌습니다 :

{ 
    _id: {}, 
    to_user: ObjectId{}, 
    user_id: ObjectId{}, // Originating user 
    custom_text: "has posted a new comment on your wall post", 
    read: false, 
    ts: MongoDate() 
} 

그리고이 말 그대로 문자 메시지를 생성해야합니다. 사용자가 알림을 생성하는 작업을 커밋 할 때마다 to_user이 알림을받을 필요가있을 때마다 채워지는 새 행을 DB에 씁니다. 그래서 나는 동일한 작업을 커밋 여러 사용자에 관해서는 실제로 OjbectId 's의 목록에 user_id 필드 변환을 말할 수있다 :

Sam, Dan and Mike all commented on your wall post

I 사용자가에서에서 본 마지막 ts를 저장 ts하여 다음 쿼리 그들의 행을 통해 매번 최신 알림에 대한 범위 기반 쿼리를 수행 할 수 있습니다. 이것은 내 개인적인 경험에서 샤딩과 쿼리에 아주 잘 작동합니다.

희망 하시겠습니까?

+0

당신의 정보를 당신을 감사하십시오 :), 나는 나의 대답을 편집했다. –

+0

나는 이렇게 생각한다. 모든 문제를 해결한다. –

1

embed or link은 MongoDB의 데이터 모델링에 대한 일반적인 질문입니다. 알림 수가 제한되지 않으면 별도의 컬렉션에 저장하는 것이 좋습니다.

현재의 경우 16MB 문서 제한은 실제로 다른 고려 사항 등의 문제만큼되지 않습니다 :

  • 단일 문서의 모든 알림을 포함하여 발생할 수있는 성능 문제는 빠르게 성장하고있는 문서입니다 데이터베이스에서 더 자주 재배치해야 할 수도 있습니다 (Padding Factor 참조).

  • 매우 짧은 기간에 문서에 여러 업데이트 (예 : "읽기"플래그 설정)를 적용하면 동일한 문서를 업데이트 할 때 더 많은 경합이 발생할 수 있습니다 (Atomic Operations 참조). 당신이 범위 쿼리 또는 skip()와 함께 limit()을 사용할 수 있습니다 페이징 구현하기 위해

. 범위 쿼리 (예 : 인덱스가있는 notificationDate을 기반으로 함)는 인덱스를 효과적으로 사용하고 컬렉션이 커짐에 따라 skip()보다 우수한 성능을 보입니다.

+0

내 대답을 편집 해 주셨습니다. –