소셜 네트워크 알림 시스템


10

배경

소셜 네트워킹 기능이 포함 된 클라이언트 용 앱을 개발 중입니다. 나는 원래 모바일 프론트 엔드를 개발하고 있었지만 상황에 따라 백엔드 개발을 담당하게되었습니다.

일반적으로 Google 시스템을 통해 사용자는 소셜 네트워크에서 예상 한대로 다른 사용자를 팔로우하고 팔로우중인 사용자에 대한 알림을받을 수 있습니다. 주의 할 점은 대부분의 사용자 기반이 이러한 개인 중 하나 이상을 따를 것으로 예상하면서 작은 하위 집합 (최대 수백 명)의 사용자 만 추적 할 수 있다는 것입니다.

UI쪽에는 숫자가 포함 된 알림 버튼이 있으며 버튼을 클릭하면 알림 화면으로 이동합니다.

문제

나는 알림을 구현하기위한 전략과 데이터베이스에서 하나 이상의 알림 테이블을 만드는 데 도움이되는 대부분의 리소스를 연구했습니다. (내가 좋아하는 예는 /programming/9735578/building-a-notification-system 여기에서 허용되는 답변 입니다.)

나를 버리는 것은 대부분의 데이터베이스 기반 알림 전략에는 각 팔로어에 대한 각 알림에 대한 행을 삽입해야한다는 것입니다. 따라서 수천 명의 사람들이 Sally를 따르는 경우 해당 테이블에 천 개의 행을 삽입합니다. 확장 성이 있습니까? 수만 또는 수십만 명의 사용자가 Sally를 팔로우하고 하루에 수십 개의 게시물을 작성하는 시점에 도달하면 어떻게됩니까?

내 원래 아이디어는 쿼리로 모든 것을 처리하는 것이 었습니다. 알림 버튼의 숫자는 알림 화면을 마지막으로 방문한 시간보다 최근에 게시 된 콘텐츠의 행 수를 요청하여 얻을 수 있지만 더 자세한 쿼리에서 개별 알림이 생성됩니다 알림 화면을 방문했을 때 이 방법은 쓰기 나 추가 스토리지가 필요하지 않지만 융통성이 없으며 서버를 상당히 어렵게 만들 수 있습니다.

설정

이전 개발자가 설정 한 백엔드는 CodeIgniterMySQL 데이터베이스를 사용 합니다. 현재 크 래피 GoDaddy 공유 호스팅 계정에서 실행 중이지만 프로덕션에 들어가기 전에 업그레이드 될 것으로 가정하고 호스팅 패키지는 사용자 증가에 따라 확장됩니다.

현재 우리의 유일한 프론트 엔드는 모바일 앱이지만 나중에 웹 사이트도 구축 할 계획입니다. 지금은 서버에서 알림에 대한 실시간 푸시 업데이트를 얻는 것에 대해 걱정하지 않습니다.

추가

저는 백엔드를 전문적으로 다루지 않으며 해당 부서에서 근무하고 있습니다. 고객은 그것을 알고 있으며, 이러한 성격의 프로젝트의 범위를 설명하기 위해 최선을 다했지만 지금은 다른 사람이 프로젝트를 수행하는 것을 믿지 않을 것임을 분명히했습니다. 테스터 추가를 시작하기 전에 한 달 더해야 할 일이 있으며 모든 종류의 성능 지표를 얻을 수 있습니다. 앞으로 5 년 동안 얼마나 많은 사용자가 있는지, 어떤 하드웨어가 있을지 예측할 수 없지만 클라이언트는 수십만 명 이상의 사용자를 기대하고 있습니다.

나는 이것이 여기에 게시되기에 충분한 문제가되기를 바란다. 필요한 경우 다듬을 수 있습니다. 질문이 있거나 중요한 세부 사항을 생략했는지 문의하십시오.

tl; dr

  • 데이터베이스 기반 알림 시스템이 모든 사용자가 동일한 수백 명 중 일부만 팔로우 할 경우 장기 확장성에 부정적인 영향을 미칩니 까?
  • 각 팔로어에 대한 각 알림에 대해 별도의 알림 행이 없어도 데이터베이스 기반 알림을 만드는 방법이 있습니까?
  • 완전히 쿼리 중심의 알림 시스템이 확장 가능합니까? 아니면 DB에 데이터를 쓰지 않는 것 외에 다른 장점이 있습니까?
  • 너무 일찍 생각하고 있습니까? 지금 작동하는 것을 제작해야하는데, 고객이 예산이 제한되어 있고 최종 제품이 인기가 있는지 아직 알지 못한다면 문제가 될 경우 최적화에 대해 걱정할 수 있습니까?

알림을 만료 할 수 있습니까? 예를 들어, 2 주 이상 지난 항목을 삭제하십시오. 그것은 사이트가 성숙함에 따라 사용되는 테이블의 크기와 다소 균형을 이루어야합니다.
GrandmasterB

문제가되지는 않겠지 만, 인기있는 사용자가 게시 할 때마다 알림 테이블에 50,000 개의 항목을 기록하는 데이터베이스를 잠그는 성능에 더 관심이있었습니다.
user45623

비슷한 (그러나 작은) 알림 시스템으로 프로젝트를 진행했습니다. 새로운 게시물 대기열을보고 알림을 처리하는 백그라운드 프로세스가있었습니다 (이 경우 실제로 이메일을 보내기 위해 두 번째 대기열에 삽입했습니다). 실시간은 아니었지만 일반적으로 몇 분 안에 모든 것을 처리했습니다.
GrandmasterB

답변:


10

따라서 수천 명의 사람들이 Sally를 따르는 경우 해당 테이블에 천 개의 행을 삽입합니다. 확장 성이 있습니까?

예, 데이터베이스 테이블이 올바르게 색인화되어 있다면 가능합니다.

수만 또는 수십만 명의 사용자가 Sally를 팔로우하고 하루에 수십 개의 게시물을 작성하는 시점에 도달하면 어떻게됩니까?

영구히 모든 알림을 추적하려는 경우 Sally에 대해 매일 수십만 또는 수십만 개의 알림 레코드를 생성합니다. 이러한 종류의 트래픽을 가진 Sally와 같은 사용자의 비율은 항상 매우 적습니다.

내 원래 아이디어는 쿼리로 모든 것을 처리하는 것이 었습니다. 알림 버튼의 숫자는 알림 화면을 마지막으로 방문한 시간보다 최근에 게시 된 콘텐츠의 행 수를 요청하여 얻을 수 있지만 더 자세한 쿼리에서 개별 알림이 생성됩니다 알림 화면을 방문했을 때

이것은 불필요하게 복잡해 보입니다. 알림에 대한 자세한 통계가 필요한 경우 알림을 저장하십시오.

데이터베이스 기반 알림 시스템이 모든 사용자가 동일한 수백 명 중 일부만 팔로우 할 경우 장기 확장성에 부정적인 영향을 미칩니 까?

그것이 작동하는 이유입니다. 적은 수의 사람들이 항상 대부분의 트래픽을 생성합니다.

각 팔로어에 대한 각 알림에 대해 별도의 알림 행이 없어도 데이터베이스 기반 알림을 만드는 방법이 있습니까?

예 ... 알림을 저장하지 마십시오. 불을 잊어 버리는 스타일로 알림 이메일을 보내면됩니다. 또는 일정 기간 동안 알림을 저장 한 다음 삭제하십시오. 또는 각 알림을 읽은 후에 삭제하십시오.

완전히 쿼리 중심의 알림 시스템이 확장 가능합니까? 아니면 DB에 데이터를 쓰지 않는 것 외에 다른 장점이 있습니까?

나는 이것이 무엇을 의미하는지 잘 모르겠습니다. 알림을 쿼리 하려면 데이터베이스에 알림 을 저장해야합니다. 그렇지 않으면 쿼리 할 것이 없습니다.

너무 일찍 생각하고 있습니까?

올바른 테이블이있는 올바르게 정규화 된 인덱스 데이터베이스를 디자인 할 수있는 사람에게 문의하십시오. 그러한 데이터베이스가 설명하는 시나리오를 효과적으로 처리하지 못한 이유는 없습니다.

실제 사례

내가 아는 한, Stack Exchange는 모든 알림을 포함하여 모든 것을 영구적으로 저장 합니다. 이들은 MySql과 유사한 데이터베이스 기술 및 일부 캐싱 기술을 사용합니다. 하드웨어 및 스토리지 공간은 크지 만 트래픽 양은 좋은 문제입니다.


와우, 당신은 모든 것을 어리둥절하게 해결했습니다! 고마워 Robert! 데이터베이스가 정규화되었지만 아직 인덱싱을 보지 못했습니다. 불행히도, 나는 누군가에게 프로젝트의 특정 세부 사항을 논의 할 수없는 조건이 엄격하고 고객이 누군가를 믿지 않을 것이라는 점을 알게 되었기 때문에 "나를 도울 수있는 사람과 이야기 할 수 없다" 하지만 프로젝트에 대해 ... 글쎄, 색인에 대한 연구를 할 수 있어야합니다. 감사!
user45623

1
인덱싱을위한 일반적인 경험 규칙 : 모든 외래 키는 중복으로 인덱싱되어야합니다. 모든 기본 키는 이미 색인화되어 있어야합니다. WHERE 절을 검색하거나 적용해야하는 필드는 색인화되어야합니다. 그것들은 적어야합니다.
Robert Harvey

1
이것은 올바르지 않습니다. 이것은 확장 할 수 없습니다. 모든 "Sally"에 대해 N은 사용자 수인 N 개의 행을 생성합니다. 합리적인 수의 사용자가 있다면 이것은 빠른 문제가 될 것입니다. 100 명의 "Sallys"가 1 만 명의 사용자에게 10 회 게시하는 것은 하루에 천만 행입니다. 실제로 원하는 것은 이것을 뒤집고 "Sally"게시물 당 하나의 행을 작성하고 Sally를 따르는 모든 사용자가 자신의 개인 사본 대신이를 가져 가게하는 것입니다. 물론 사용자 별 로직 (예 : 집계)이 필요한 경우 문제가 발생할 수 있습니다.
Ben

1
... 여기서 "포스트 당 한 행을 피하십시오"라는 설명은 대부분의 시스템에서 이러한 포스트가 붙어 있어야하기 때문에 분명히 짚맨입니다. 또한 "복잡하기 때문에"쿼리를 피하지 않아도됩니다. 시스템이 확장 될 때 지속 불가능한 오버 헤드가 발생할 수 있으므로 쿼리를 피하십시오.
Ben
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.