▲

GN⁺: PostgreSQL 옵티마이저 10년간의 개선

 (rmarcus.info)
2P by neo 1달전 | favorite | 댓글 1개

PostgreSQL 옵티마이저의 10년간의 개선사항들

  • 쿼리 최적화 연구자로서 지난 10년간 PostgreSQL의 정교한 오픈 소스 쿼리 옵티마이저를 활용하여 연구해 옴
  • 데이터베이스 작업을 시작한 이후 10년 동안 PostgreSQL이 얼마나 개선되었는지 궁금해짐
  • 변경 내역과 의견은 많았지만, 강력한 경험적 비교를 찾을 수 없어서 직접 PostgreSQL 8에서 16까지 Join Order Benchmark(JOB)를 실행하기로 함
  • 각 데이터베이스 버전에 대해 90번째 백분위수 쿼리 지연 시간을 기록함

테스트 환경 구성

  • Arch Linux의 Docker 컨테이너 내에서 GCC 13.2를 사용하여 각 버전의 PostgreSQL을 빌드함
  • 쿼리 옵티마이저의 품질을 측정하기 위해 shared_buffers를 8GB로 설정(전체 데이터베이스를 보유할 수 있을 만큼 큼)
  • 모든 버전에 대해 work_mem를 8MB로 설정함
  • 각 쿼리는 캐시를 따뜻하게 하기 위해 한 번 실행된 다음 추가로 5번 실행한 중간값 지연 시간을 기록함

전반적인 성능 개선

  • PostgreSQL의 꼬리 성능은 크게 향상되었지만, 13~16 버전은 대체로 안정적이었음
  • 8 버전과 16 버전을 비교했을 때, PostgreSQL의 옵티마이저는 지난 10년 동안 꼬리 지연 시간을 거의 절반으로 줄임
  • 전체 쿼리 분포를 조사할 수 있음(로그 스케일 참고)

회귀 분석을 통한 개선 정량화

  • 회귀 분석을 사용하여 지연 시간의 하락 기울기가 유의미한지 확인하고, 각 PostgreSQL 버전이 얼마나 많은 개선을 가져오는지 정량화할 수 있음
  • PostgreSQL 주요 버전 번호를 쿼리 지연 시간에 대해 회귀분석하면, 각 새로운 주요 버전의 PostgreSQL은 평균적으로 Join Order Benchmark에서 15%의 성능 향상을 가져옴
  • 그러나 선형 모델은 변화를 측정하는 데 arguably a poor measure임

추가 고려사항

  • 물론 이러한 모든 개선 사항이 쿼리 옵티마이저 때문은 아님. 병렬 작업자부터 just-in-time(JIT) 컴파일에 이르기까지 실행 엔진에 대한 개선도 역할을 함
  • JOB의 각 쿼리 계획이 연도별로 어떻게 변했는지 조사하는 것도 흥미로울 것임

주요 포인트

  • 데이터베이스를 업그레이드하세요! PostgreSQL 8에서 16으로 이동하면 워크로드의 꼬리 지연 시간을 크게 개선할 수 있음
  • 연구자들은 PostgreSQL이 움직이는 목표라는 점에 유의해야 함
    • 학습된 쿼리 최적화 연구는 시간이 지남에 따라 PostgreSQL의 다른 버전과 비교해 왔음
    • 이전 기술이 PostgreSQL을 30% 개선하고 최신 기술은 PostgreSQL을 25% 개선한다고 해서, 최신 기술이 더 강력한 PostgreSQL과 비교하고 있을 수 있음

GN⁺의 의견

  • PostgreSQL은 지속적으로 성능을 개선해 왔지만, 최근 버전에서는 개선 폭이 줄어들고 있음. 이는 이미 상당한 최적화가 이루어졌기 때문일 수 있음. 앞으로의 개선은 세부적인 영역에 집중될 것으로 보임

  • 단순히 쿼리 옵티마이저뿐 아니라 실행 엔진의 개선도 성능 향상에 기여하고 있음. 병렬 처리나 JIT 컴파일 등 다양한 측면에서의 최적화가 이루어지고 있음

  • 이 실험은 Join Order Benchmark에 한정된 것으로, 실제 업무에서의 성능 개선 효과는 워크로드에 따라 다를 수 있음. 자신의 업무 특성에 맞는 벤치마크를 수행해 보는 것이 좋겠음

  • 연구자들은 PostgreSQL의 버전 변화를 고려해야 함. 같은 알고리즘이라도 비교 대상인 PostgreSQL 버전에 따라 상대적인 성능 향상 폭이 달라질 수 있기 때문

  • 오래된 버전의 PostgreSQL을 사용 중이라면 업그레이드를 적극 고려해 볼 만함. 10년 전 버전에 비해 최신 버전은 현저한 성능 개선이 이루어졌음. 물론 업그레이드에 따른 호환성 등의 이슈는 감안해야 할 것임

▲
neo 1달전  [-]
Hacker News 의견

요약:

  • 최적화 문제를 잘 해결하려면 비용에 대한 데이터가 중요함. PostgreSQL은 개선의 여지가 많음. 특히 syscall latency 데이터, foreign key 통계 등이 부족함.
  • 대규모 쿼리의 경우 실행 중 계획을 수정할 수 있는 deferred planning 등의 기법 도입이 필요함.
  • 기계학습은 비용 예측 모델 개선에 활용하는 게 적절함. 기계학습으로 직접 쿼리 계획을 세우는 건 적절치 않음.
  • shared buffer를 크게 잡아 데이터를 모두 메모리에 올려 벤치마킹하는 건 옵티마이저의 실제 성능을 제대로 평가하기 어려움.
  • JIT 컴파일러는 아직 성능 저하만 초래하는 경우가 많음.
  • PostgreSQL 버전 넘버링이 10버전부터 바뀌었으므로 8.x, 9.x 버전을 major 버전으로 보고 성능 추이를 분석하는 것도 흥미로울 듯함.
  • 제시된 그래프만으로는 성능 개선 추세를 명확히 확인하기 어려움. Tail latency는 개선된 듯 보이나 나머지는 각각 다를 수 있음.
  • 훌륭한 옵티마이저를 만드는 건 상당히 도전적인 과제임.
  • 쿼리 최적화가 SQL 수준인지 알고리즘 수준인지 궁금함.
답변달기