배경 :
합리적으로 확장 할 수있는 웹 응용 프로그램을 만들었습니다. Google 또는 Twitter는 아니지만 내 앱은 각 사용자마다 상당히 많은 양의 데이터를 사용하므로 데이터 요구 사항이 상당히 높습니다. 나중에 모든 것을 다시 설계하지 않고도 합리적으로 확장 할 준비가 되었으면합니다.
나는 데이터베이스 전문가가 아닌 소프트웨어 개발자라고 생각한다. 내가 여기에 게시하는 이유입니다. 더 많은 데이터베이스 전문 지식을 가진 사람이 나에게 조언을 줄 수 있기를 바랍니다.
비교적 많은 수의 사용자가 있지만 Facebook 번호와 같은 것은 없지만 다음과 같은 DB가 있어야합니다.
하나의 "큰 테이블":
- 2 억 5 천만 레코드
- 20 열
- 약 100GB의 데이터
- 색인화 된 bigint (20) 외래 키가 있습니다
- 색인화 된 varchar (500) string_id 열이 있습니다
- int (11) "value"열이 있습니다
다른 4 개의 테이블 :
- 각 천만 레코드
- 각각 약 2-4GB의 데이터
- 이 각 테이블에는 4-8 개의 열이 있습니다.
- 하나의 열은 datetime date_created입니다.
- 하나의 열은 varchar (500) string_id 열입니다.
- 각 테이블에서 하나 또는 두 개의 열이 조인에서 선택됩니다
이 테이블 중 하나는 평균 저장에 사용됩니다. 스키마는 bigint (20) id, varchar (20) string_id, datetime date_created, float average_value입니다.
내가하고 싶은 것 -비교적 비싼 두 쿼리 :
새로운 평균값을 계산하십시오.
- 외래 키를 사용하여 큰 테이블에서 최대 수백만 개의 개별 레코드를 선택하십시오.
- string_id로 그룹화하여 새 평균을 계산하십시오.
- 평균 테이블에 결과를 삽입하십시오.
- 현재 구성된대로이 쿼리는 두 개의 조인을 사용합니다.
사용자에게 서비스를 제공하기 위해 비정규 화 된 읽기 전용 레코드를 만듭니다.
- 외래 키를 사용하여 큰 테이블에서 1,000-40,000 개의 레코드를 선택하십시오.
- 문자열 ID 열을 사용하여 최신 레코드에서 다른 네 개의 테이블 각각과 결합하십시오.
- 비정규 화 된 테이블에 결과를 삽입하십시오.
- 이 레코드는 프런트 엔드에서 사용자에게 정보를 표시하는 데 사용됩니다.
- 현재 구성된대로이 쿼리는 4 개의 조인을 사용합니다.
고가의 각 쿼리를 배치 백엔드 데이터베이스에서 실행하여 결과를 사용자의 요청을 처리하는 실시간 프론트 엔드 DB 서버로 푸시 할 계획입니다. 이러한 쿼리는 정기적으로 실행됩니다. 나는 얼마나 자주 결정하지 않았다. 평균 쿼리는 하루에 한 번 수행 될 수 있습니다. 비정규 화 쿼리는 아마도 몇 분마다 더 빈번해야합니다.
이러한 각 쿼리는 현재 "큰 테이블"에 100K 레코드의 데이터 세트가있는 초저가 시스템의 MySQL에서 몇 초 안에 실행됩니다. 스케일링 능력과 스케일링 비용이 모두 걱정됩니다.
질문 :
- 이 접근법이 건전 해 보입니까? 큰 그림으로 볼 때 분명히 문제가 있습니까?
- RDBMS가 올바른 도구입니까, 아니면 하둡 제품군과 같은 다른 "빅 데이터"솔루션을 봐야합니까? 데이터가 구조화되어 관계형 모델에 잘 맞기 때문에 RDBMS를 사용하는 경향이 있습니다. 그러나 특정 시점에서 더 이상 RDBMS를 사용할 수 없다는 것을 이해하고 있습니다. 그게 사실입니까? 이 스위치는 언제 필요할까요?
- 작동합니까? 이러한 쿼리를 적절한 시간 내에 실행할 수 있습니까? 쿼리 # 1을 기다리는 데 몇 시간이 걸릴 수 있지만 쿼리 # 2는 몇 분 안에 완료됩니다.
- 하드웨어 관점에서 무엇을 고려해야합니까? 내 RAM 및 CPU 병목 현상은 무엇입니까? RAM에 인덱스를 유지하는 것이 중요하다고 가정합니다. 고려해야 할 다른 것이 있습니까?
- 언젠가 데이터를 분할하고 여러 서버를 사용해야 할 것입니다. 내 유스 케이스가 이미 해당 카테고리에있는 것처럼 보입니까, 아니면 단일 머신을 수직으로 수직 확장 할 수 있습니까? 이것은 10 배의 데이터로 작동합니까? 100 배?