2013-06-12 3 views
0

전 SQL 경험이 거의없는 프런트 엔드 개발자입니다. 나는 일하는 조직을위한 데이터 질의 시스템을 개발하는 것을 고려 중이다.다중 테이블과 Postgres의 테이블 인덱스

현재 대부분의 데이터는 일련의 스프레드 시트에 있습니다. 워크 시트의 계획 시나리오 (예 : "효율적")와 경제 부문 (예 : "농업")을 기준으로 한 다른 값을 가진 100 개의 워크 시트 (예 : 테이블)가 동일한 템플릿 (국가의 열 포함)에서 파생되었습니다. 각 워크 시트에는 약 8000 개의 행이 있습니다.

각 워크 시트마다 별도의 데이터베이스 테이블을 만들지 만 테이블을 통해 동일한 CREATE 문을 사용합니까? 이 경우 저는이 라인을 따라 인덱스를 생성 할 상상 :

CREATE INDEX sector_scenario_lower_country ON sector_scenario(lower(country)); 

내가 (각 sector_scenario 테이블에 대해 한 번)이 지수 100 번을 만들어야 할 것입니다. 내가 찾고있는 데이터 행을 찾고 싶을 때, 나는 정확한 테이블을 확인하기 위해 내 앱을 사용해야한다. (이것은 많은 문제가되거나 시간이 많이 걸리지 않아야한다.)

SELECT col4, col5, col6 FROM sector_scenario WHERE lower(country) = "brazil"; 

또는 시나리오 및 섹터 열을 데이터베이스 테이블에 추가 한 다음 모든 단일 워크 시트를 해당 단일 테이블에 복사해야합니까? 이 경우

, 난 그냥 한 번 다음과 같은 인덱스를 만들 것입니다 :

CREATE INDEX main_table_idx ON main_table(scenario, sector, lower(country)); 

그때 꽤 정기적으로 다음과 같은 쿼리를 만들 것입니다 : 분명히

SELECT col4, col5, col6 FROM main_table WHERE scenario = "efficient" AND sector = "agriculture" AND lower(country) = "brazil"; 

을 두 번째 옵션이 많이 될 것입니다 설정 작업이 줄어 듭니다. 그러나 비슷한 성능을 기대할 수 있습니까?

+0

정답은 데이터의 의미와 사용 방법에 따라 다릅니다. 나는이 책에 대해 좋은 소식을 들었는데, Mere Mortals를위한 데이터베이스 디자인. 몇 가지 고려 사항을 파악하는 데 도움이 될 수 있습니다. –

답변

3

둘째 해결 방법은 모든 행을 하나의 테이블에 넣고 하나의 테이블에 대한 인덱스를 작성하는 것입니다.

매우 드문 경우에만 다른 테이블로 데이터를 분리 할 수 ​​있습니다. 내가 생각할 수있는 유일한 데이터는 다른 사람의 데이터와 별도로 데이터를 저장해야한다는 사용자 요구 사항입니다.

첫 번째 시나리오에서 색인의 전체 크기가 두 번째 시나리오의 크기와 비교 가능한지 여부는 질문 하나입니다. 첫 번째 시나리오의 인덱스가 - 평균적으로 - 빈 페이지의 절반 (마지막에)을 가졌을 때, 나는 그것이 더 클 수 있다고 생각합니다. 시나리오를 저장하는 추가 오버 헤드는 값당 한 번만 발생합니다. 실제로 크기를 테스트하지 않고서는 데이터 크기가 단일 테이블 접근 방식을 선호한다고 생각합니다.

각 테이블의 많은 양의 데이터로 작업하면 테이블 또는 인덱스가 사용 가능한 메모리를 오버 플로우시킬 수있는 다른 가능성이 있습니다. 이것이 문제라면, 테이블을 분해하는 것은 좋은 일입니다. 그러나 올바른 방법은 분할을 사용하여 각 세그먼트를 별도의 테이블로 분리하는 것입니다. 여러 테이블을 독립적으로 관리하는 것은 아닙니다.

+0

+1하지만 수십억 개의 행이있을 때 샤딩이 다른 유효한 이유가되지 않습니까? –

+0

@Denis. . . 업데이트 된 답변을 참조하십시오. 짧은 양식은 하나의 테이블이 가장 좋습니다. 너무 큰 경우에는 분할을 사용하십시오. –

+0

장점 a +2. :-) –

1

매우 자세한 답변을 드릴만큼 충분한 정보를 제공하지는 않지만 가장 가능성이 높거나 1 개의 테이블을 원한다고 말하면서 기록에 남지는 않을 것입니다. 성능은 하드웨어 (설정, 하드웨어 설정 등) 목록에 너무 많은 것에 의존하지만, PostgreSQL은 8M 행에는 아무런 문제가 없어야합니다. 올바른 색인을 생성하면 성능이 향상됩니다. 그리고 그렇게하기 위해 pgAdminIII에 쿼리를 작성하고 analyze 함수를 사용해야합니다.결과를 해석하는 방법에 대한 조사가 필요하지만, 실적이 좋지 않은 쿼리를 최적화하는 데 도움이되는 사용자를 위해 SO에 대한 스키마, 쿼리 및 쿼리 분석을 항상 게시 할 수 있습니다. Postgres 커뮤니티가 성능 문제를 해결하는 데 매우 도움이되고 열의가 있다고 생각합니다.

+0

이렇게 효과적으로 작성된 인덱스 된 단일 테이블뿐만 아니라 같은 수의 행을 가진 인덱스되지 않은 별도의 테이블을 제대로 말하면 실수가 아닙니다. 이 일반에 대한 명확하고 눈에 띄는 예외는 없습니까? –

+2

PostgreSQL의 버전, 쿼리 (select vs counts 등) 및 메모리 양에 따라 다릅니다. 그러나 나는 거의 항상 대답은 "예"라고 생각합니다. 별도의 테이블은 데이터를 분할하는 방법 일뿐입니다. 이것은 전체 테이블이 하드웨어에 따라 (메모리에 따라) 맞출 수 있으며 (특정 상황에서) 아주 좋은 성능을 (때때로) 볼 수 있지만, 많이 알지 못해서는 추천 할 수 없습니다 더 많은 정보. –