트위터 감각으로 사용자의'활동 '을 따르는 앱을 디자인하고 있지만 데이터베이스/쿼리 디자인/효율성에 대해서는 경험이별로 없습니다. 이를 관리하고 피할 수있는 함정 등을위한 모범 사례가 있습니까? 나는 이것이 제대로 수행되지 않으면 DB에 매우 큰로드를 생성 할 수 있습니다.'추종자 및 효율성
차이가 나는 경우 사람들은 비교적 적은 수의 사람들에게만 '따라 가기'만합니다 (그러나 한 사람에게는 팔로워가 많을 수 있음). 그러나 이것은 확실하지 않으며, 나는 그것에 의지하고 싶지 않을 것입니다.
감사의 말을 전합니다. 감사.
매우 간단하고 쉽게 normalisation 전체로 할 수 있습니다. 고유 한 ID를 가진 사용자 테이블이있는 경우 USERID 및 FOLLOWERID 열이있는 테이블이 각각 TABLE_FOLLOWERS이고 각 사용자의 모든 팔로어를 일대일 대응 관계로 설명합니다.
반값에 가까운 데이터베이스 서버에서 수백만 번 어시스턴트를 사용하더라도 좋은 데이터베이스 (IE가 아닌 MS 액세스)를 사용하는 한 잘 수행됩니다.
이는 지원해야 할 사용자 수에 따라 다릅니다. 사용자가 얼마나 많이 팔리는가? 이전 질문에 대한 귀하의 대답이 낙관적 인 것으로 드러나면 어떤 종류의 자금 지원/개발 노력을 할 것으로 기대하십니까?
소규모 프로젝트의 경우 데이터베이스를 무시하고 응용 프로그램을 User 개체가있는 List[followers]을 유지하는 간단한 개체 모델로 디자인하십시오. 정상적인 작동을 위해서는 RAM에 모든 것을 보관하고 ORM을 사용하여 주기적으로 데이터베이스에 보관하십시오 (아마도 postgresql 또는 mysql).
큰 프로젝트의 경우에는 관계형 데이터베이스를 전혀 사용하지 않을 것입니다. 하지만 정확히 내가 사용하는 것은 프로젝트의 구체적인 세부 사항에 달려 있습니다.
단지 스파이크를하려는 경우 ORM 방식을 사용하십시오. 그러나 그것이 확장되지 않는다는 것을 명심하십시오.
RAM 개체 저장소에 대한 소개 자료의 방향을 알려주시겠습니까? 특히 어떤 기술에 대해 이야기하고 있습니까? 레디 스 (Redis) 같은 것이 있습니까? – Chris
스파이크의 경우 실제로는 RAM에 직접 간단한 데이터 구조를 유지하는 것이 좋습니다. 평균 100 명의 팔로워와 사용자 당 100 바이트의 단순한 객체를 가진 100,000 명의 사용자와 4 바이트 참조를 가정하면 팔로워 그래프에는 40MB, 사용자 DB에는 10MB 만 필요합니다. 인덱싱 오버 헤드가 3 배가 되더라도 쉽게 할 수있는 일은 RAM에 저장할 수 있고 DB에별로 어려움없이 지속될 수 있습니다. – Recurse
너는 아마 http://highscalability.com/을 읽어야하고, 이것이 거대한 사이트에 의해 어떻게 관리되는지에 관한 기사 일 것이다.
모델은 매우 간단합니다. 문제는 서브 스크립 션 테이블 크기입니다. 1 백만 명의 사용자가 있고 각각이 1000에 가입하면 구독 테이블에 10 억 개의 행이 있습니다. 나는 그것이 오랫동안 것을 알고
alt text http://www.damirsystems.com/dp_images/follower_model.png
좋은 다이어그램. 감사. – user749665
@Damir .. 다이어그램에서 "EnableSubscription"의 의미를 설명해 주시겠습니까? 그게 뭐야? 이 방법 중 어떤 방식으로 작동하고 따르고 따라야합니까? 그리고 왜 bool을 사용합니까? 피벗 테이블을 사용하고 userID와 Follower 둘 다로 userID를 참조 할 수 없습니까?그 EnableSubcription 아마 사용자가 당신을 따르는 금지? – Chriz74
, 나는'FOLLOWERID'would 저장소 여러 값을 궁금? – lazyprogrammer