2016-10-09 8 views
0

의 당신이 정의와 테이블을 상상해 보자MySQL InnoDB가 동시 업데이트를 처리 할 수있는 이유와 PostgreSQL에서 실행할 수없는 이유는 무엇입니까?

CREATE TABLE public.positions 
(
    id serial, 
    latitude numeric(18,12), 
    longitude numeric(18,12), 
    updated_at timestamp without time zone 
) 

그리고 당신은 같은 테이블에 50,000 행이.

당신은 30 개 다른 스레드에서 같은 쿼리를 실행하면 문 (이 특정 데이터 세트) 50,000 1,000 행

업데이트됩니다

update positions 
set updated_at = now() 
where latitude between 234.12 and 235.00; 

, MySQL의 InnoDB의 : 지금 테스트 목적으로이 같은 업데이트를 실행합니다 성공하고 postgres는 많은 교착 상태로 실패합니다.

왜?

답변

3

평범한 행운, 나는 말할 것입니다.

30 개의 스레드가 진행되어 동일한 1000 개의 행을 업데이트하려는 경우 동일한 순서로 이러한 행에 액세스 할 수 있습니다 (이 경우 서로를 잠그고 순차적으로 수행함). 또는 서로 다른 순서로 액세스 할 수 있습니다. 케이스가 교착 상태가됩니다).

InnoDB와 PostgreSQL의 경우는 같습니다.

귀하의 경우 상황이 다른 이유를 분석하려면 실행 계획을 비교하여 시작해야합니다. 어쩌면 PostgreSQL이 같은 순서로 모든 행에 액세스하지 못하는 이유를 알 수 있습니다. 이제 디스크를 공유 할 수 있습니다

  • 동시 큰 순차적 스캔 읽기 (제프 데이비스)

    :

    이 정보 부족, 난 당신이 동시 순차적 스캔 속도를 높이는 feature introduced in version 8.3가 발생하는 것으로 추측에는 요

    이 작업은 테이블 중간에서 새 순차 스캔을 시작하고 (다른 순차 스캔이 이미 진행중인 경우) 시작 부분까지 줄 바꿈하여 완료됩니다. 이는 ORDER BY을 지정하지 않은 쿼리에서 반환되는 행의 순서에 영향을 미칠 수 있습니다. 필요한 경우이 매개 변수를 사용하지 않으려면 synchronize_seqscans 구성 매개 변수를 사용할 수 있습니다.

확인은 PostgreSQL의 실행 계획을 순차적 스캔을 사용하고 synchronize_seqscans을 변경하면 교착 상태를 피할 수 있는지 확인합니다.

+0

네 말이 맞아. 당신은 다음을 사용하여 포스트 그레스에서 이것을 해결할 수 있습니다 : UPDATE .... 어디에서 id (SELECT ... FROM ... WHERE ... id에 의한 업데이트 순서). – SDReyes

+0

나는 * right * 솔루션이 30 개 스레드가 동일한 행을 업데이트하도록하지 않을 것이라고 생각합니다. –

+0

, 우리는 DB를 강조하고 있습니다. 이것은 우리가 벤치마킹의 일부이기 때문에 우리가하는 것입니다! xD – SDReyes