이것은 반 가상적이며 대규모 데이터베이스 테이블을 다루는 경험이 없으므로 어떤 이유로 든 이것이 끔찍한 지 전혀 모릅니다. 상황에 따라 :
웹 기반 응용 프로그램을 상상해보십시오. 회계 소프트웨어는 20,000 명의 클라이언트가 있고 각 클라이언트에는 1000 개 이상의 항목이 있습니다. 그것은 내가 알고있는 2 천만 개의 행으로 복잡한 쿼리 속도를 확실히 늦출 수 있습니다.
이런 경우 각 클라이언트에 대해 데이터베이스에 새 테이블을 만드는 것이 더 합리적입니까? 데이터베이스가 20k (또는 그 이상) 테이블을 갖는 데 어떻게 반응합니까?
답변:
일반적으로 말하자면, 아니요, 고객 당 테이블 (실제로 데이터베이스를 의미한다고 생각합니다)이 의미가 없습니다. 데이터베이스 테이블의 경우 2 천만 행이 상대적으로 작습니다. 데이터베이스가 올바르게 조정 (인덱싱)되고 쿼리가 올바르게 구성되는 한 쿼리 속도는 문제가되지 않습니다. 20,000 개의 개별 데이터베이스를 관리하는 데 따른 추가 복잡성으로 인해 별도의 이점으로 얻을 수 있다고 생각하는 이점이 무엇이든 상쇄됩니다. 예를 들어, 테이블 구조를 변경하려고하면 어떻게됩니까? 이제 20,000 번해야합니다!
최악의 경우, 데이터베이스 크기가 문제가되는 것을 발견 한 후에는 나중에 별도의 데이터베이스로 분할 할 수 있습니다.
나쁜 생각 인 것 같습니다.
이국적인 구조로 데이터베이스를 능가하려고하지 마십시오. 데이터베이스 엔진은 대규모 데이터 세트를 처리하기 위해 많은 최적화로 설계되었습니다. 예를 들어, 설명하는 것은 수동으로 인덱스를 구현하려는 시도와 거의 비슷합니다. DB 엔진에서 제공하는 인덱스 만 사용하면 직접 수행 할 수있는 것보다 훨씬 더 나은 성능을 구현할 수 있으므로 유지 관리가 많이 필요하지 않습니다.
또한 일반적인 경험 법칙입니다. 응용 프로그램을 정상적으로 사용하는 동안 데이터베이스 구조 (테이블, 필드)를 조작하거나 생성 해야하는 방식으로 데이터베이스를 설계하지 않는 것이 좋습니다. 성능 최적화를 어렵게 만들고 잠재적으로 보안 허점을 생성하는 일상적인 작업을 수행 할 수있는 권한을 사용자에게 너무 많이 부여합니다.
다음은 사람들이이 질문을 할 때 항상 읽을 것을 권장하는 기사입니다.
http://datacharmer.blogspot.com/2009/03/normalization-and-smoking.html
단일 테이블 IMHO는 문제가되지 않으므로 아직 존재하지 않는 문제는 생성하지 마십시오. 성능을 돕기 위해 할 수있는 일이 많이 있습니다. clientID 또는 날짜 필드를 기반으로 단일 테이블을 여러 파일로 분할하여 IO에 도움을 줄 수 있습니다. DB는 사이트에 필요한 모든 쿼리에 대해 20,000 개의 서로 다른 SQL 문을 추적, 최적화 및 캐시 할 필요가 없습니다. clientid로 색인을 생성 할 수 있습니다. 20K 클라이언트는 많은 하드웨어 비용을 지불 할 수 있습니다.
이 유형의 테이블에는 NoSQL 유형 db를 사용할 수 있습니다.
20K 클라이언트의 경우 데이터베이스가 가장 약한 링크가 아닐 수 있으므로 왜 이렇게 많은 복잡성이 발생합니까?