수백만 명의 사용자를 관리하는 방법?

정말 큰 것을 발사하려고합니다. 서버와 데이터베이스를 준비해야합니다.

각 100,000 명의 사용자 세트를 별도의 사용자 테이블에 그룹화하고 싶지만 한 사용자를 로그인하려고하는 사용자를 적절한 사용자 테이블에 연결하는 방법을 모르겠습니다.

예를 들어, 사용자 jay@mail.com가 사용자 테이블 # 36과 관련이 있다는 것을 어떻게 알 수 있습니까?

하나의 사용자 테이블에 1000 만 명의 사용자가 있거나 100,000의 100 개가있는 것과 동일합니까?

페이스 북은 어떻습니까? 나는 그들이 9 억 5 천만 항목을 가진 하나의 글로벌 사용자 테이블을 가지고 있다고 믿을 수 없다.

내일 수십억 명의 사용자가 없을 것이며 MySQL은 아무런 문제없이 수백만 행을 처리 할 수 ​​있습니다. 내 사용자 테이블에 5 백만 명의 사용자가 있고 나를 믿어도 걱정할 사항이 없습니다.

샤딩이 필요할 때까지 샤딩에 대해 걱정하지 마십시오 . 존재하거나 존재하지 않을 수있는 문제에 대해 조기에 최적화하려고 시도하고 있으며 프로세스 중에 혁신 할 수있는 속도가 심각하게 손상 될 수 있습니다. 문제가 발생할 때 신속하게 시작하고 찾을 수 있습니다. 스케일링 문제가 무엇인지 미리 예측할 수 없습니다.

이 규모에 도달하면 이런 종류의 문제를 해결할 수있는 돈과 자원이 많이 있습니다.

실제로 큰 데이터 세트를 처리하고 처음부터 시작해야하는 경우 외부 컨설턴트가 회사를 더 잘 지원할 수 있을지 확실하지 않습니다. 제발 틀리지 말아주세요.하지만 많은 고객과 함께 프로젝트를 망치면 회사에 PR 영향을 줄 것입니다.

하나의 테이블에 10M 튜플과 관련하여 인덱싱이 좋으면 괜찮습니다. 우리는 하나의 테이블에 여러 개의 100M 튜플을 저장해야합니다.

다음은 페이스 북 데이터베이스 디자인 의지도가있는 2010 년의 게시물입니다. Facebook 데이터베이스 디자인

다음과 같은 파티션 유형에 대한 mysql 문서를 읽을 수 있습니다. MySQL 문서 : Partinioning

MySQL은 다음 유형을 지원합니다.

범위 분할. 이 유형의 파티셔닝은 주어진 범위 내에 속하는 열 값을 기반으로 파티션에 행을 할당합니다. 18.2.1 절“RANGE 파티션”을 참조하십시오.

LIST 파티셔닝. 파티션이 개별 값 세트 중 하나와 일치하는 열을 기반으로 선택된다는 점을 제외하고 RANGE에 의한 파티션과 유사합니다. 18.2.2 절“LIST 분할”을 참조하십시오.

해시 파티셔닝. 이 유형의 파티셔닝을 사용하면 테이블에 삽입 할 행의 열 값에서 작동하는 사용자 정의 표현식이 리턴 한 값을 기반으로 파티션이 선택됩니다. 이 함수는 음수가 아닌 정수 값을 생성하는 MySQL에서 유효한 식으로 구성 될 수 있습니다. 이 유형의 LINEAR HASH 확장도 사용할 수 있습니다. 18.2.3 절.“HASH 분할”을 참조하십시오.

키 분할. 이 유형의 파티셔닝은 평가할 열이 하나 이상 제공되고 MySQL 서버가 자체 해싱 기능을 제공한다는 점을 제외하고 HASH의 파티셔닝과 유사합니다. MySQL에서 제공하는 해싱 함수는 열 데이터 유형에 관계없이 정수 결과를 보장하므로 이러한 열에는 정수 값 이외의 값이 포함될 수 있습니다. 이 유형의 선형 키 (LINEAR KEY)도 사용할 수 있습니다. 18.2.4 절.“키 분할”을 참조하십시오.

우선, 사용자를 별도의 테이블로 분리하지 마십시오. 그것은 사물을 복잡하고 무의미하게 만듭니다. MySQL 및 기타 데이터베이스와 같은 데이터베이스는 문제없이 동일한 테이블에있는 수백만 레코드의 데이터베이스를 사용할 수 있습니다 (올바른 PRIMARY KEYS 설정). 각 사용자 (기본 사용자 테이블에서)에 대해 데이터베이스 AUTO_INCREMENT AND PRIMARY 고유 키 필드를 사용하므로 모든 레코드는 고유합니다 (UID). 그런 다음 다른 테이블에서 해당 고유 ID를 사용하여 참조하고 있습니다. 그런 다음 PRIMARY KEY로 설정 한 모든 테이블에서 데이터베이스 서버의 정보 처리 속도가 빨라져야합니다. Drupal CMS에서 사용자 정보를 저장하는 방법을 배울 수 있습니다. 수백만 명의 사용자와 매우 큰 회사 (대형 미디어 회사, 정부, 심지어 세계 최대 은행에서 사용)가 10 년 이상 동안 테스트했습니다. www.drupal에서. org에는 같은 표에 1,6 백만 페이지가 넘는 페이지 (노드)가 저장되어 있으며 매월 백만 명 이상의 순 방문자가 있으며 웹 사이트는 고장없이 작동합니다. 모든 것은 적절한 최적화 및 구성에 관한 것입니다.

1 천만 건의 레코드를 기록한 후 성능에 만족하지 않으면 (적절한 최적화 및 db 구성 변경 후) 사용자를 다른 테이블로 분리할지 여부를 결정할 수 있습니다. 따라서 사용자 레코드가 보관되는 위치 (UID 및 table_name)에 대한 정보가있는 새 테이블을 추가하여 실제로 기능을 확장 할 수 있습니다. 그런 다음 다른 테이블에서이 정보를 요청하면이 테이블이 올바른 테이블을 찾습니다. 그러나 1 억 ~ 1 억 개가 넘는 레코드가 없으면 사용자를위한 하나의 큰 테이블을 갖는 것이 좋습니다. 그러나 성능을 크게 향상 시키지는 않습니다 (데이터베이스는 방대한 데이터를 처리하도록 설계되었습니다). 정보를 단순하게 유지하는 것이 좋습니다. 일반적으로 회사는 다른 데이터베이스 서버 (마스터 및 슬레이브)를 결정하고 다른 데이터베이스 서버를 결정합니다. 로드 밸런싱 기능과 함께 다시 작동합니다. 1000 만 명의 사용자가 있다면 다른 DB 서버에 대한 비용을 지불 할 수 있습니다.

user.install 파일 의 user테이블 스키마 예를 참조하십시오 .

다른 답변에서 알 수 있듯이 사용자를 여러 테이블로 나누는 것은 좋은 생각이 아닙니다. userid에 인덱스가있는 대부분의 데이터베이스는 백만 행을 처리 할 수 ​​있습니다. 그러나 인덱스의 총 항목 수에 따라 쿼리 당 대기 시간이 증가 할 수 있습니다. 데이터 세트가 작 으면 일반 데이터베이스에서 단일 테이블로 관리 할 수 ​​있습니다.

당신이 백만 개 이상의 레코드를 성장한다면 당신의 미래에 대한 생각에 대해서도 다른 생각을 던지려고 노력할 것입니다. 이러한 많은 수의 고객으로 인해 다운 타임 등을 원하지 않습니다. 따라서보고 싶은 nosql 데이터베이스가 많이 있습니다. 응용 프로그램에서 샤딩을 직접 관리하는 대신 샤딩을 수행합니다. 또한 데이터 중복성을 제공하므로 가동 시간이 늘어납니다. 페이스 북과 모두 캐시에 memcache 등을 많이 사용합니다. 그러나 그들이 영구 상점에 무엇을 사용하는지 잘 모르겠습니다.

주의해야 할 중요한 점은 nosql 데이터베이스와 조인 등을 수행 할 수 없다는 것입니다. 따라서 사용 사례를 계획하고 결정하십시오. 조인 및 다중 레코드 트랜잭션이 필요한 경우 nosql 데이터베이스가 적합하지 않습니다.

알파벳 범위를 기준으로 나누지 않겠습니까? 수백만 명의 사용자가있는 경우 각 문자 또는 문자 쌍에 대해 별도의 테이블을 만듭니다 (사용자 이름이 'a'로 시작하는 사용자의 경우 'a'표). 처음에는 많은 오버 헤드가 있지만 큰 데이터베이스를 기대하고 특정 사용자에게 사용해야하는 테이블을 구별 할 수 있기를 원하므로 알파벳 순서가 가장 쉽고 쉬운 선택이라고 생각합니다.