배열이 많고 업데이트가 많은 대형 테이블에서 PostgreSQL 속도가 느림

Question

3 열 인덱스와 배열 열이있는 매우 큰 테이블 (20M 레코드)이 있습니다. 배열 열은 모든 행에 대해 매일 새 값을 추가하여 업데이트됩니다. 또한 삽입이 있지만 업데이트만큼이나 많지는 않습니다.

배열의 데이터는 [[date_id_1, my_value_for_date_1], [date_id_2, my_value_for_date_2]]과 같은 세 가지 키에 해당하는 일일 측정을 나타냅니다. 이러한 일별 값의 그래프를 그리는 데 사용됩니다. 시간이 지남에 따라 키 값 (a, b, c)을 시각화하려고한다고 가정하면 SELECT values FROM t WHERE a = my_a AND b = my_b AND c = my_c입니다. 그런 다음 values 배열을 사용하여 그래프를 그립니다.

일일 1 회 대량으로 발생하는 업데이트의 성능이 시간이지나면서 크게 악화되었습니다.

PostgreSQL 8.3.8 사용.

해결 방법을 찾을 수있는 힌트를 줄 수 있습니까? Postgres의 일부 매개 변수를 조정하여 다른 데이터베이스로 이동하는 것 (비 관계형 데이터베이스가이 특정 테이블에 더 적합 할 것으로 추측되지만 그와 관련된 많은 경험이 없습니다) 일 수도 있습니다.

Answer 1

필자는 테이블에 FILLFACTOR를 살펴볼 것입니다. 기본적으로 100으로 설정되었으므로 70으로 낮출 수 있습니다 (처음부터). 그런 다음 테이블을 다시 작성하려면 VACUUM FULL을 수행해야합니다.

ALTER TABLE tablename SET (FILLFACTOR = 70); 
VACUUM FULL tablename; 
REINDEX TABLE tablename; 

이 UPDATE에게 다른 페이지에 배치하는 것이 더 효율적입니다 원래, 같은 페이지에 행의 업데이트 된 사본을 배치 할 수있는 기회를 제공합니다. 또는 데이터베이스가 이전에 업데이트 된 많은 부분에서 이미 조각난 경우 이미 충분할 수도 있습니다. 이제 데이터베이스에는 HOT updates을 수행 할 수있는 옵션이 있습니다. 업데이트 할 열이 임의의 인덱스와 관련이 없다고 가정합니다.

Answer 2

배열이 여기로가는 길인지 확실하지 않습니다.

별도의 테이블에 하나의 값과 행당 키를 저장하지 마십시오. 일괄 업데이트는 순수 삽입 작업입니다.

Answer 3

글쎄 3 열 인덱스는 걱정할 필요가 없습니다. 그렇다고 반드시 그렇게 느리게 만들지는 않습니다. 그러나 그 배열 열은 참으로 문제 일 수 있습니다. 매일 그 배열 열에 값을 추가한다고합니다. 추가로, 당신은 모든 20 mln에 값을 추가하는 것을 의미합니까? 테이블에 기록? 아니면 그냥 몇 가지 기록?

상황이 완전히 나에게 명확하지는 않지만 해당 배열 열을 제거하는 방법을 살펴볼 것을 제안합니다. 예를 들어 별도의 테이블로 만듭니다. 그러나 이는 상황에 따라 달라지며 옵션이 아닐 수도 있습니다. 그것은 나일지도 모르지만, 나는 항상 내 테이블 중 하나에 그런 칼럼을 가지고 '더러운'느낌. 대부분의 경우 해당 배열 열로 해결하려는 문제에 대한 더 나은 솔루션이 있습니다. 즉, 그러한 열이 유효한 상황은 분명하지만, 지금은 아무 것도 생각할 수 없습니다. 20 만 달러짜리 테이블에는 없다. 레코드 수.

Answer 4

문제는 업데이트 중입니다. 스키마를 배열 기반에서 하루에 여러 행으로 변경하면 성능 문제가 해결됩니다.

어떤 종류의 cronjob과 함께 나중에 배열에 롤업을 추가 할 수는 있지만 업데이트는하지 마십시오.