PostgreSQL 빠른 키 값 저장소

키 값 저장 안내

PostgreSQL에서는
​

JSON

SQL과 NoSQL을 잊어라--PostgreSQL에서 JSON을 사용하면 둘 다 좋을 수 있다

Arctype의 Derek Xiao・ 2월 3일・ 8분 읽기

#database #sql #programming #discuss

지리공간 데이터

Postgres에서 지리적 공간 데이터를 사용합니다.

Arctype의 Derek Xiao・ 20년 12월 29일・ 3분 읽기

#sql #postgres #database #beginners

모호한 검색
​

PostgreSQL에서 모호한 검색을 위한 안내서

Arctype의 Arctype 팀・ 8월 19일・ 7분 읽기

#postgres #guide

전체 텍스트 검색
​

PostgreSQL 전체 텍스트 검색을 사용하여 텍스트 데이터 검색

Arctype의 Arctype 팀・ 9월 30일・ 9분 읽기

#postgres #guide

본고는 키 값 저장 기능을 연구하고자 하는데, 이것은 그다지 유행하지 않지만, 여전히 PostgreSQL의 NosQL 기능에서 없어서는 안 될 역할을 하고 있다.
​

확장 및 데이터로 PostgreSQL 설정

JSON 및 JSONB와 달리 키 값 저장소는 별도의 확장자 HStore 입니다.PostgreSQL 설치 자체와 함께 묶여 있기 때문에 바로 설치할 수 있습니다.
​

Hstore 활성화

CREATE EXTENSION HSTORE

​
키 값 저장소 확장을 사용합니다.
참고 확장은 수퍼유저가 액세스하는 경우에만 사용할 수 있습니다.그렇지 않으면 시스템에서 오류가 발생합니다.
​

테이블 및 Hstore 열 작성

우리는 많은 사람들을 관건적인 가치로 유지하는 간단한 시범표를 만들 것이다.이를 위해 데이터 형식 자체를 hstore로 만들어야 합니다.
​

CREATE TABLE hstore_example (score hstore)

​
기본 형식은 항상 int 이기 때문에 키 값 구조 형식을 지정할 필요가 없습니다.데이터베이스 레벨이든 애플리케이션 레벨이든 조작을 위해서는 적당한 데이터 브로드캐스트가 필요하다.이것은 JSON 데이터 형식과 유사하며 그 중에서 모든 데이터는 text이다.

테스트 데이터 채우기

데이터를 text열에 삽입하는 것은 매우 간단하다.
​

INSERT INTO hstore_example values('"Jason" => 100');
INSERT INTO hstore_example values('"Jack" => 200');
INSERT INTO hstore_example values('"Perry" => 150');

​

중첩된 데이터 삽입도 가능하다.그러나 이 예에서 우리는 단지 끼워 넣는 단계만 삽입했다.
​

키 값 조회 시작

우리는 키워드를 검색해서 줄을 조회할 수 있다.
​

SELECT
    *
FROM
    hstore_example
WHERE
    score ? 'Jason';

​
특정 키의 값을 획득,
​

SELECT
    score -> 'Jason' as score
FROM
    hstore_example
WHERE
    score -> 'Jason' is NOT NULL 

​

자세한 작업 목록은 PostgreSQL 공식 문서JSONB에서 확인할 수 있습니다.
https://www.postgresql.org/docs/current/hstore.html
현재 몇 개의 강력한 조작부호가 우리가 각종 데이터 조작을 할 수 있도록 도와줄 수 있으며, 응용 프로그램 논리에서 그것들을 처리할 필요가 없다.성능, 보안 등 여러 가지 이유로 우리는 항상 응용 프로그램 수준이 아닌 데이터베이스 단계에서 데이터 조작을 해야 한다.
​

더 빠른 검색을 위한 색인 만들기

hstore 확장 지원HStore 유형의 인덱스.우리는 다음과 같이 이 인덱스를 만들 수 있습니다.
​

CREATE INDEX hstore_example_idx ON hstore_example USING GIN (score)

​
이것은 우리가 HStore 만들 수 있는 GIN 인덱스와 속도와 기능적으로 유사합니다. 특히 키가 끼워져 있고 검색이 정상적으로 직접적이지 않을 때 검색 속도를 현저히 높일 수 있습니다.이러한 인덱스는 JSON GIN보다 훨씬 작아 메모리/캐시에서 보다 빠르게 검색할 수 있습니다.
다른 한편, 색인은 쓰기 속도를 떨어뜨리기 때문에 색인을 광범위하게 사용하기 전에 적당한 균형을 고려해야 한다.애플리케이션/솔루션을 프로덕션에 투입하기 전에 벤치마크를 수행해야 합니다.
​

Hstore의 내부 구조

GIN 내부 스토리지는 JSON type 입니다.JSON과 마찬가지로 모든 읽기/수정 작업을 수행하려면 디스크에서 전체 필드를 읽어야 합니다.따라서 Redis와 Memcache 등 전통적인 키 값 저장에 비해HStore는 진정으로 최적화되지 않았다.
TOAST 테이블 구조에 대한 문서도 강력히 추천되고 왜 읽기/쓰기는 부분적인 업데이트가 아니라 하나의 전체적인 필드로만 이루어지는지 설명한다.
https://www.postgresql.org/docs/current/storage-toast.html
따라서 K/V 구조가 복잡하고 중첩된 경우에는 적절한 유형varlena 또는 HStore 유형으로 저장하는 것이 좋습니다.
​

결론

잠재적인 용례 장면은 유사할 수 있으나 다음과 같은 예에 국한되지 않는다.

캐시를 유지합니다.

장면을 빠르게 읽기/업데이트합니다(예: API 속도 제한기 유지 관리).

점수/간단한 시간 서열 데이터를 유지한다.

JSON 키 값 저장의 대체품이 아니다.그것들은 서로 다른 용례를 겨냥하여 최적화를 진행하였다.그러나 앞에서 언급한 바와 같이 이러한 특성은 PostgreSQL에 존재한다. 왜냐하면 많은 상황에서 단독 데이터 저장소를 사용하는 것은 과도한 사용과 유지보수 문제이기 때문이다.우리는 이 공백을 메우는 다리로 PostgreSQL의 NosQL 기능을 사용할 수 있다.만약 업무가 확장된다면 우리는 다른 데이터베이스로 옮길 수 있다.그러나 그 전에 우리는 PostgreSQL을 쉽게 사용할 수 있다. ACID에 맞는 NosQL 기능을 제공하고 단독 데이터베이스의 추가 비용을 유지하지 않아도 된다.