저는 1 억 5 천만 명의 사용자가있는 사이트의 수석 개발자입니다. 우리는 초기에 계획하고 신중하게 확장했기 때문에 확장 문제가 거의 없었습니다. 다음은 내 경험에서 제안 할 수있는 몇 가지 전략입니다.

SCHEMA
먼저 스키마를 비정규 화하십시오. 즉, 여러 관계형 테이블을 갖는 대신 하나의 큰 테이블을 선택해야합니다. 일반적으로 조인은 여러 준비 및 데이터 정렬을 수행하면 디스크 I / O가 손상되므로 귀중한 DB 리소스가 낭비됩니다. 가능하면 피하십시오.

여기서 중복되는 데이터는 중복 데이터를 저장 / 풀링한다는 것입니다. 그러나 데이터 및 케이지 내부 대역폭이 매우 저렴하고 (더 큰 디스크) 다중 준비 I / O가 훨씬 비싸기 때문에 (서버가 더 많기 때문에) 이는 수용 가능합니다. .

인덱싱
쿼리가 적어도 하나의 인덱스를 사용하는지 확인합니다. 그러나 자주 쓰거나 업데이트하면 색인 비용이 발생합니다. 이를 피하기위한 몇 가지 실험적인 트릭이 있습니다.

인덱싱되지 않은 열을 인덱싱 된 열과 병렬로 추가하여 추가 할 수 있습니다. 그런 다음 인덱싱되지 않은 열을 인덱싱 된 열에 일괄 적으로 쓰는 오프라인 프로세스를 가질 수 있습니다. 이런 식으로 mySQL이 인덱스를 다시 계산해야 할 때 더 잘 제어 할 수 있습니다.

전염병과 같은 계산 쿼리를 피하십시오. 쿼리를 계산해야하는 경우 쓰기시 한 번 수행하십시오.

CACHING
나는 매우 memcached를하는 것이 좋습니다. PHP 스택 (Facebook)에서 가장 큰 플레이어에 의해 입증되었으며 매우 유연합니다. 이를 수행하는 두 가지 방법이 있습니다. 하나는 DB 계층에서 캐싱하고 다른 하나는 비즈니스 로직 계층에서 캐싱입니다.

DB 계층 옵션을 사용하려면 DB에서 검색 한 쿼리 결과를 캐싱해야합니다. md5 ()를 사용하여 SQL 쿼리를 해시하고 데이터베이스로 이동하기 전에이를 조회 키로 사용할 수 있습니다. 이것의 단점은 구현하기가 쉽다는 것입니다. 단점 (구현에 따라 다름)은 캐시 만료와 관련하여 모든 캐싱을 동일하게 취급하기 때문에 유연성이 떨어집니다.

내가 작업하는 상점에서는 비즈니스 계층 캐싱을 사용합니다. 즉, 시스템의 각 콘크리트 클래스가 자체 캐싱 스키마 및 캐시 시간 초과를 제어합니다. 이것은 우리에게는 꽤 효과가 있었지만 DB에서 검색 한 항목은 캐시의 항목과 같지 않을 수 있으므로 캐시와 DB를 함께 업데이트해야합니다.

데이터 보호
복제는 지금까지만 가능합니다. 예상보다 빨리 쓰기 작업에 병목 현상이 발생합니다. 이를 보완하려면 가능한 빨리 데이터 샤딩을 지원해야합니다. 당신이하지 않으면 나중에 자신을 촬영하고 싶을 것입니다.

구현하는 것은 매우 간단합니다. 기본적으로 데이터 저장소에서 키 권한을 분리하려고합니다. 기본 DB와 클러스터 ID 간의 매핑을 저장하려면 글로벌 DB를 사용하십시오. 이 매핑을 쿼리하여 클러스터를 얻은 다음 클러스터를 쿼리하여 데이터를 가져옵니다. 이 조회 작업에서 지옥을 캐시하여 무시할 수있는 작업으로 만들 수 있습니다.

이것의 단점은 여러 샤드의 데이터를 함께 수집하기가 어렵다는 것입니다. 그러나, 당신은 그것의 주위에 길을 엔지니어링 할 수 있습니다.

오프라인 처리
사용자가 백엔드를 기다리지 않아도되도록 기다리지 마십시오. 작업 큐를 작성하고 오프라인으로 처리 할 수있는 모든 처리를 사용자 요청과 별도로 수행하십시오.

---

답변