게으른 사용자를 위한 업그레이드: PostgreSQL 12가 성능을 향상시키는 방법

PostgreSQL 12"세계 최고의 오픈 소스 관계형 데이터베이스"의 최신 버전인 가 몇 주 안에 출시될 예정입니다(모든 것이 계획대로 진행된다면). 이는 XNUMX년에 한 번씩 수많은 새로운 기능이 포함된 새 버전을 출시하는 일반적인 일정을 따르며, 솔직히 이는 인상적입니다. 이것이 제가 PostgreSQL 커뮤니티의 활동적인 회원이 된 이유입니다.

제 생각에는 이전 릴리스와 달리 PostgreSQL 12에는 분할 또는 쿼리 병렬 처리와 같은 한두 가지 혁신적인 기능이 포함되어 있지 않습니다. 나는 PostgreSQL 12의 주요 기능이 더 뛰어난 안정성이라고 농담한 적이 있습니다. 비즈니스의 중요한 데이터를 관리할 때 꼭 필요한 것이 아닌가요?

그러나 PostgreSQL 12는 여기서 끝나지 않습니다. 새로운 기능과 개선 사항을 통해 애플리케이션의 성능이 향상됩니다. 업그레이드만 하면 됩니다!

(글쎄, 인덱스를 다시 빌드할 수도 있지만 이번 릴리스에서는 예전만큼 무섭지 않습니다.)

PostgreSQL을 업그레이드하고 불필요한 소란 없이 즉시 상당한 개선을 누릴 수 있다면 좋을 것입니다. 몇 년 전 저는 PostgreSQL 9.4에서 PostgreSQL 10으로의 업그레이드를 검토하고 PostgreSQL 10의 향상된 쿼리 병렬 처리 덕분에 애플리케이션 속도가 어떻게 빨라졌는지 확인했습니다. 그리고 가장 중요한 것은 거의 아무것도 필요하지 않다는 것입니다(구성 매개변수만 설정하면 됩니다). max_parallel_workers).

동의하세요. 업그레이드 후 애플리케이션이 즉시 더 잘 작동하면 편리합니다. 그리고 PostgreSQL에는 점점 더 많은 사용자가 있기 때문에 우리는 사용자를 기쁘게 하기 위해 매우 열심히 노력합니다.

그렇다면 PostgreSQL 12로 간단히 업그레이드하면 어떻게 만족할 수 있을까요? 지금 말씀 드리겠습니다.

주요 인덱싱 개선

인덱싱이 없으면 데이터베이스가 멀리 가지 않습니다. 정보를 빨리 찾을 수 있는 또 다른 방법은 무엇입니까? PostgreSQL의 기본 인덱싱 시스템은 다음과 같습니다. B-트리. 이 유형의 인덱스는 스토리지 시스템에 최적화되어 있습니다.

우리는 단순히 연산자를 사용합니다 CREATE INDEX ON some_table (some_column), PostgreSQL은 우리가 지속적으로 값을 삽입, 업데이트 및 삭제하는 동안 인덱스를 최신 상태로 유지하기 위해 많은 작업을 수행합니다. 마치 마술처럼 모든 것이 저절로 작동합니다.

그러나 PostgreSQL 인덱스에는 한 가지 문제가 있습니다. 부풀려져 있다 추가 디스크 공간을 차지하고 데이터 검색 및 업데이트 성능을 저하시킵니다. "부풀어 오른다"는 것은 인덱스 구조를 비효율적으로 유지한다는 의미입니다. 이는 제거하는 가비지 튜플과 관련이 있을 수도 있고 아닐 수도 있습니다. 진공 (정보를 제공한 Peter Gaghan에게 감사드립니다)피터 거게건)). 인덱스 팽창은 인덱스가 활발하게 변경되는 워크로드에서 특히 두드러집니다.

PostgreSQL 12는 B-트리 인덱스의 성능을 크게 향상시켰으며 TPC-C와 같은 벤치마크를 사용한 실험에 따르면 현재 평균 40% 더 적은 공간이 사용되는 것으로 나타났습니다. 이제는 B-트리 인덱스 유지 관리(즉, 쓰기 작업)뿐만 아니라 인덱스가 훨씬 작기 때문에 데이터 검색에도 소요되는 시간이 줄어듭니다.

테이블을 적극적으로 업데이트하는 애플리케이션 - 일반적으로 OLTP 애플리케이션(실시간 거래 처리) - 디스크를 사용하고 요청을 훨씬 더 효율적으로 처리합니다. 디스크 공간이 많을수록 인프라를 업그레이드하지 않고도 데이터베이스를 확장해야 하는 공간이 늘어납니다.

일부 업그레이드 전략에서는 이러한 이점을 활용하기 위해 B-트리 인덱스를 재구축해야 합니다(예: pg_upgrade 인덱스를 자동으로 다시 작성하지 않습니다.) 이전 버전의 PostgreSQL에서는 테이블에 대규모 인덱스를 재구축하면 그 동안 변경이 불가능했기 때문에 상당한 다운타임이 발생했습니다. 하지만 PostgreSQL 12에는 또 다른 멋진 기능이 있습니다. 이제 다음 명령을 사용하여 인덱스를 병렬로 다시 작성할 수 있습니다. 동시에 재색인가동 중지 시간을 완전히 방지합니다.

PostgreSQL 12의 인덱싱 인프라에는 다른 개선 사항이 있습니다. 마법이 있었던 또 다른 일 - 미리 쓰기 로그, 일명 WAL(미리 쓰기 로그)입니다. 미리 쓰기 로그는 실패 및 복제가 발생할 경우 PostgreSQL의 모든 트랜잭션을 기록합니다. 애플리케이션은 이를 보관 및 특정 시점 복구. 물론 미리 쓰기 로그는 디스크에 기록되므로 성능에 영향을 줄 수 있습니다.

PostgreSQL 12는 인덱스 생성 중에 GiST, GIN 및 SP-GiST 인덱스에 의해 생성되는 WAL 레코드의 오버헤드를 줄였습니다. 이는 몇 가지 실질적인 이점을 제공합니다. WAL 레코드는 디스크 공간을 덜 차지하며 재해 복구나 특정 시점 복구 등에서 데이터가 더 빠르게 재생됩니다. 애플리케이션에서 이러한 인덱스를 사용하는 경우(예를 들어 PostGIS 기반 지리공간 애플리케이션은 GiST 인덱스를 많이 사용함) 이는 사용자의 노력 없이도 경험을 크게 향상시킬 수 있는 또 다른 기능입니다.

파티셔닝 - 더 크고, 더 좋고, 더 빠릅니다.

PostgreSQL 10 도입 선언적 파티셔닝. PostgreSQL 11에서는 사용하기가 훨씬 쉬워졌습니다. PostgreSQL 12에서는 섹션 규모를 변경할 수 있습니다.

PostgreSQL 12에서는 특히 테이블에 수천 개의 파티션이 있는 경우 파티셔닝 시스템의 성능이 크게 향상되었습니다. 예를 들어 쿼리가 수천 개의 파티션이 있는 테이블에서 몇 개의 파티션에만 영향을 미치는 경우 훨씬 더 빠르게 실행됩니다. 이러한 유형의 쿼리에 대한 성능만 향상되는 것은 아닙니다. 또한 여러 파티션이 있는 테이블에서 INSERT 작업이 얼마나 빠른지 확인할 수 있습니다.

다음을 사용하여 데이터를 기록합니다. 복사 - 그런데, 이거 좋은 방법이네 대량 데이터 다운로드 그리고 여기 예가 있습니다 JSON 수신 — PostgreSQL 12의 분할된 테이블도 더욱 효율적이 되었습니다. COPY를 사용하면 모든 것이 이미 빨라졌지만 PostgreSQL 12에서는 확실히 빠릅니다.

이러한 장점 덕분에 PostgreSQL을 사용하면 훨씬 더 큰 데이터 세트를 저장하고 검색하기 쉽게 만들 수 있습니다. 그리고 당신의 노력은 없습니다. 시계열 데이터 기록과 같이 애플리케이션에 파티션이 많은 경우 간단한 업그레이드만으로 성능이 크게 향상됩니다.

이것이 정확히 "업그레이드하고 즐기는" 개선 사항은 아니지만 PostgreSQL 12에서는 분할된 테이블을 참조하는 외래 키를 생성할 수 있으므로 분할 작업이 즐거워집니다.

WITH 쿼리가 훨씬 더 좋아졌습니다.

언제 기본 제공 공통 테이블 표현식에 패치가 적용되었습니다. (일명 CTE, 일명 WITH 쿼리)에 대한 기사를 쓰고 싶었습니다. PostgreSQL을 사용하는 애플리케이션 개발자는 얼마나 행복했는지. 이는 응용 프로그램 속도를 높이는 기능 중 하나입니다. 물론 CTE를 사용하지 않는 한.

나는 종종 SQL 초보자들이 CTE를 사용하는 것을 좋아한다는 것을 알게 되는데, CTE를 특정 방식으로 작성하면 정말 명령형 프로그램을 작성하는 것처럼 느껴집니다. 개인적으로 나는 이러한 쿼리를 다시 작성하여 돌아다니는 것을 좋아했습니다. без CTE 및 생산성 향상. 이제 모든 것이 달라졌습니다.

PostgreSQL 12를 사용하면 부작용 없이 특정 유형의 CTE를 인라인할 수 있습니다(SELECT), 요청이 끝날 무렵에 한 번만 사용됩니다. 내가 다시 작성한 CTE 쿼리를 계속 추적한다면 대부분이 이 범주에 속할 것입니다. 이를 통해 개발자는 이제 빠르게 실행되는 명확한 코드를 작성할 수 있습니다.

게다가 PostgreSQL 12는 사용자가 아무것도 할 필요 없이 SQL 실행 자체를 최적화합니다. 그리고 지금은 그러한 쿼리를 최적화할 필요가 없을지라도 PostgreSQL이 계속해서 쿼리 최적화 작업을 수행하고 있다는 것은 좋은 일입니다.

JIT(Just-in-Time) - 이제 기본값

지원되는 PostgreSQL 12 시스템 Llvm JIT 컴파일은 기본적으로 활성화됩니다. 우선 지원을 받아보세요. JIT 일부 내부 작업의 경우 두 번째로 선택 목록(SELECT 이후에 있음)의 표현식(가장 간단한 예는 x + y)이 포함된 쿼리, 집계, WHERE 절이 포함된 표현식 등은 JIT를 사용하여 성능을 향상시킬 수 있습니다.

PostgreSQL 12에서는 JIT가 기본적으로 활성화되어 있기 때문에 저절로 성능이 향상되지만 JIT를 도입한 PostgreSQL 11에서 애플리케이션을 테스트하여 쿼리 성능을 측정하고 조정해야 할 사항이 있는지 확인하는 것이 좋습니다.

PostgreSQL 12의 나머지 새로운 기능은 어떻습니까?

PostgreSQL 12에는 표준 SQL/JSON 경로 표현식을 사용하여 JSON 데이터를 검사하는 기능부터 매개변수를 사용한 다단계 인증에 이르기까지 수많은 멋진 새 기능이 있습니다. clientcert=verify-full, 생성된 열 등이 있습니다. 별도의 게시물로 충분합니다.

PostgreSQL 10과 마찬가지로 PostgreSQL 12는 업그레이드 직후 전반적인 성능을 향상시킵니다. 물론 자신만의 방식이 있을 수 있습니다. 제가 PostgreSQL 10에서 했던 것처럼 개선을 적용하기 전에 프로덕션 시스템에서 비슷한 조건에서 애플리케이션을 테스트해 보세요. PostgreSQL 12가 이미 예상보다 안정적이더라도 테스트를 게으르지 마십시오. 애플리케이션을 프로덕션 환경에 출시하기 전에 철저히 검토해야 합니다.

출처 : habr.com