일부 내용을 읽은 분 TOAST Postgres는 PGLZ를 호출하는 LZ 계열 압축 알고리즘을 사용한다는 것을 알게되었습니다. 그리고 2KB보다 큰 값을 자동으로 입력합니다.Postgres의 내장 PGLZ 압축은 GZIP와 어떻게 비교됩니까?
PGLZ는 속도와 압축률면에서 GZIP과 어떻게 비교됩니까?
PGLZ와 GZIP의 속도와 압축 속도가 비슷한지 알고 싶습니다. 큰 JSON 문자열을 Postgres에 데이터로 삽입하기 전에 여분의 GZIP 단계를 수행하는 것이 불필요하거나 해로운 경우가 있습니다.
상당히 빠르지 만 압축률은 gzip보다 낮습니다. CPU 비용을 낮추기 위해 최적화되었습니다.
DB에서 직접 조작 할 필요가 없다고 가정하거나, gzip을 해제하는 기능을 사용하지 않아도된다는 가정하에, 큰 데이터를 gzip으로 처리하기 전에 확실히 bytea 필드에 저장해야합니다. 먼저. 당신은 DB에서 그것을해야만한다면 plpython이나 plperl과 같은 일을 할 수 있지만, 일반적으로 앱에서 그렇게하는 것이 더 편리합니다.
추가 압축 작업을 수행하려는 경우 LZMA와 같은 더 강력한 압축 방법을 사용해보십시오.
PostgreSQL의 TOAST에 gzip 및/또는 LZMA 압축에 대한 지원을 추가하려는 노력이있었습니다. 이렇게하는 데있어 주된 문제점은 이전 버전의 디스크 형식과의 호환성을 유지하고 미래와의 호환성을 유지해야한다는 것입니다. 지금까지 아무도 관련 핵심 팀 구성원을 만족시키는 구현을 생각해 내지 못했습니다. 예 : pluggable compression support. 그것은 플러그 형 지원이 거부되면 catch-22에서 멈추는 경향이 있습니다. (이유는 해당 스레드 참조) 아무도 새로운 기본 방법으로 채택해야하는 적합한 소프트웨어 특허 안전 알고리즘에 동의 할 수 있으며 변경 방법에 동의합니다 여러 압축 방법을 처리하는 형식 등이 있습니다.
크레이그 감사합니다! 어떤 시점에서 추가 압축에 대한 생각이 그만한 가치가 있다고 말하는가? 내 상황은 잠재적으로 수백만 개의 JSON BLOB를 각각 10-100K까지 포함합니다. –
말하기 어렵습니다. 실험 할 시간입니다! 얼마나 자주 당신이 그들을 찾는가, 당신이 그들을 얼마나 자주 업데이트하는지, 당신의 공간 제약이 무엇인지 등과 같은 너무 많은 로컬/앱 특정 요소들에 달려 있습니다. –
압축을 여러 유사한 값에 어떻게 적용 할 수 있습니까? 예를 들어, "온도"열은 중간 값의 몇도 이내에 떠오르게됩니다. –