PostgreSQL 안티패턴: "죽은" 무리와 싸우기

PostgreSQL의 내부 메커니즘의 특성으로 인해 어떤 상황에서는 매우 빠르지만 다른 상황에서는 "별로 빠르지 않을" 수 있습니다. 오늘 우리는 DBMS의 작동 방식과 개발자가 DBMS를 사용하여 수행하는 작업 간의 충돌에 대한 전형적인 예에 ​​중점을 둘 것입니다. 업데이트와 MVCC 원칙.

의 간략한 이야기 훌륭한 기사:

UPDATE 명령으로 행이 수정되면 실제로 DELETE 및 INSERT라는 두 가지 작업이 수행됩니다. 안에 문자열의 현재 버전 xmax는 UPDATE를 수행한 트랜잭션의 수와 동일하게 설정됩니다. 그러면 생성됩니다 새 버전 같은 줄; xmin 값은 이전 버전의 xmax 값과 일치합니다.

이 거래가 완료된 후 일정 시간이 지나면 이전 버전 또는 새 버전이 결정됩니다. COMMIT/ROOLBACK, 인식됩니다 "죽음"(죽은 튜플) 지나갈 때 VACUUM 표에 따라 지워졌습니다.

그러나 이것은 즉시 일어나지는 않지만 "죽은"문제는 매우 빠르게 획득 될 수 있습니다. 기록 대량 업데이트 큰 테이블에서 조금 후에 같은 상황에 직면하게 될 것입니다 VACUUM은 도움을 드릴 수 없습니다.

#1: 나는 그것을 옮기는 것을 좋아한다

귀하의 메서드가 비즈니스 로직에 대해 작업 중인데 갑자기 일부 레코드에서 X 필드를 업데이트해야 한다는 사실을 깨닫게 되었다고 가정해 보겠습니다.

UPDATE tbl SET X = <newX> WHERE pk = $1;

그런 다음 실행이 진행됨에 따라 Y 필드도 업데이트되어야 함을 알 수 있습니다.

UPDATE tbl SET Y = <newY> WHERE pk = $1;

... 그리고 Z도 있습니다. 왜 사소한 일에 시간을 낭비합니까?

UPDATE tbl SET Z = <newZ> WHERE pk = $1;

현재 데이터베이스에 이 레코드의 버전이 몇 개 있습니까? 응, 4개! 이 중 하나는 관련이 있으며 3개는 [자동]VACUUM으로 정리해야 합니다.

이런 식으로하지 마십시오! 사용 하나의 요청으로 모든 필드 업데이트 — 거의 항상 메소드의 논리는 다음과 같이 변경될 수 있습니다.

UPDATE tbl SET X = <newX>, Y = <newY>, Z = <newZ> WHERE pk = $1;

#2: 사용은 DISTINCT FROM, Luke!

그래서 당신은 여전히 ​​​​원했습니다 테이블의 수많은 레코드 업데이트 (예를 들어 스크립트나 변환기를 사용하는 동안) 그리고 다음과 같은 내용이 스크립트에 적용됩니다.

UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2;

대략 이 형식의 요청은 빈 새 필드를 채우는 것이 아니라 데이터의 일부 오류를 수정하기 위해 매우 자주 발생하며 거의 항상 발생합니다. 동시에 그녀 자신도 기존 데이터의 정확성은 전혀 고려되지 않습니다. -하지만 헛된 일이야! 즉, 원하는 내용이 정확히 포함되어 있어도 레코드가 다시 작성됩니다. 그런데 왜 그럴까요? 문제를 해결해 봅시다:

UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2 AND X IS DISTINCT FROM <newX>;

많은 사람들이 이런 훌륭한 운영자의 존재를 알지 못하므로 여기에 치트 시트가 있습니다. IS DISTINCT FROM 그리고 도움이 되는 기타 논리 연산자:

... 그리고 복잡한 작업에 대해 조금 ROW()-표현:

#3: 차단을 통해 내 연인을 알아봅니다.

발사되고있다 두 개의 동일한 병렬 프로세스, 각각은 "진행 중"이라는 항목을 표시하려고 시도합니다.

UPDATE tbl SET processing = TRUE WHERE pk = $1;

이러한 프로세스가 실제로 서로 독립적으로 작업을 수행하지만 동일한 ID 내에서 작업을 수행하더라도 두 번째 클라이언트는 첫 번째 트랜잭션이 완료될 때까지 이 요청에 대해 "잠겨" 있습니다.

결정 번호 1: 작업이 이전 작업으로 축소됩니다.

다시 추가해보자 IS DISTINCT FROM:

UPDATE tbl SET processing = TRUE WHERE pk = $1 AND processing IS DISTINCT FROM TRUE;

이 형식에서 두 번째 요청은 데이터베이스의 어떤 것도 변경하지 않으며 모든 것이 이미 예상대로이므로 차단이 발생하지 않습니다. 다음으로, 적용된 알고리즘에서 해당 레코드를 “찾지 못함”이라는 사실을 처리합니다.

결정 번호 2: 권고 잠금

읽을 수 있는 별도의 기사에 대한 큰 주제입니다. 권장 차단의 적용 방법 및 "갈퀴".

결정 번호 3: 멍청한 전화

하지만 이것이 바로 당신에게 일어나야 할 일입니다 동일한 레코드로 동시 작업? 아니면 클라이언트 측에서 비즈니스 로직을 호출하는 알고리즘을 망쳤습니까? 그리고 생각해보면?..

출처 : habr.com