PostgreSQL에서 소개 한 JSONB에 대한 설명

PostgreSQL은 방금 JSONB를 도입 했으며 이미 해커 뉴스에서 유행하고 있습니다. 누군가 PostgreSQL에 이전에 있었던 Hstore 및 JSON과 다른 점을 설명 할 수 있다면 좋을 것입니다. 장점과 한계는 무엇이며 언제 사용해야합니까?

첫째, hstore키와 값은 texts 만 가능 하지만 값은 sql NULLs 일 수있는 key => 값 쌍만 저장할 수있는 contrib 모듈 입니다.

둘 다 json& jsonb는 유효한 JSON 값 을 저장할 수 있습니다 ( spec에 정의 됨 ).

F.ex. 이 유효한 JSON 표현이다 : null, true, [1,false,"string",{"foo":"bar"}], {"foo":"bar","baz":[null]}- hstoreJSON은 무엇을 할 수 있는지에 비해 조금 하위 집합입니다 (하지만 당신은이 부분 집합, 그것의 벌금을 필요로하는 경우).

json& 의 유일한 차이점은 jsonb스토리지입니다.

• json 일반 텍스트 형식으로 저장되며
• jsonb 이진 표현으로 저장됩니다

이것의 3 가지 주요 결과가 있습니다 :

• jsonb일반적으로 저장하는 데보다 많은 디스크 공간이 필요합니다 json(때로는 그렇지 않음)
• jsonb 입력 표현보다 빌드하는 데 더 많은 시간이 걸립니다 json
• json작업은 걸릴 크게 보다 더 많은 시간을 jsonb(또한 구문 분석하는 것은에서 당신은 어떤 작업을 할 때마다 수행해야합니다 및 json입력 값)

때 jsonb안정적인 릴리스와 함께 사용할 수 있습니다 당신은 쉽게 선택할 수 있습니다 때, 두 가지 주요 사용 사례가있을 것입니다 :

1. 애플리케이션에서 JSON 표현으로 만 작업하는 경우 PostgreSQL은이 표현을 저장하고 검색하는 데만 사용됩니다 json.
2. PostgreSQL의 JSON 값에 대해 많은 작업을 수행하거나 일부 JSON 필드에서 인덱싱을 사용하는 경우을 사용해야합니다 jsonb.

Peeyush :

짧은 대답은 다음과 같습니다.

• PostgreSQL 내 에서 정렬, 슬라이싱, 스 플라이 싱 등과 같은 많은 JSON 조작을 수행하는 경우 속도 이유로 JSONB를 사용해야합니다.
• JSON에서 임의의 키 검색을 위해 인덱스 조회가 필요한 경우 JSONB를 사용해야합니다.
• 위의 작업을 수행하지 않으면 JSON을 사용해야합니다.
• 키 순서, 공백 및 중복 키를 유지해야하는 경우 JSON을 사용해야합니다.

더 긴 답변을 얻으려면 9.4 릴리스에 더 가까운 전체 "HowTo"기록을 수행 할 때까지 기다려야합니다.

json과 jsonb의 차이점에 대한 간단한 설명 ( PostgresProfessional의 원본 이미지 ) :

SELECT '{"c":0,   "a":2,"a":1}'::json, '{"c":0,   "a":2,"a":1}'::jsonb;

          json          |        jsonb 
------------------------+--------------------- 
 {"c":0,   "a":2,"a":1} | {"a": 1, "c": 0} 
(1 row)

• json : 텍스트 스토리지«현재 그대로»
• jsonb : 공백 없음
• jsonb : 중복 키 없음, 마지막 키 승리
• jsonb : 키가 정렬됩니다

더 많은 음성 비디오 와 슬라이드 쇼 프리젠 테이션 jsonb 개발자가. 또한 그들은 JsQuery 를 도입 했습니다 .pg.extension은 강력한 jsonb 쿼리 언어를 제공합니다.

• hstore "와이드 컬럼"스토리지 유형에 더 가깝고, 키-값 쌍의 플랫 (중첩되지 않은) 사전이며 항상 합리적인 이진 형식 (해시 테이블, 따라서 이름)으로 저장됩니다.
• jsonJSON 문서를 텍스트로 저장하고 문서가 저장 될 때 유효성 검사를 수행하고 필요한 경우 출력에서 ​​구문 분석합니다 (예 : 개별 필드에 액세스). 전체 JSON 사양을 지원해야합니다. 전체 JSON 텍스트가 저장되므로 형식이 유지됩니다.
• jsonb성능상의 이유로 바로 가기가 필요합니다. JSON 데이터는 입력시 구문 분석되어 2 진 형식으로 저장되며 사전의 키 순서는 유지되지 않으며 중복 키도 아닙니다. JSONB 필드의 개별 요소에 대한 액세스는 항상 JSON 텍스트를 구문 분석 할 필요가 없으므로 빠릅니다. 출력시 JSON 데이터가 재구성되고 초기 형식이 손실됩니다.

IMO, 대한 상당한 이유가 없다 되지 사용 jsonb하면 기계 판독 데이터로 작업하는 경우가 있습니다 일단은.

JSONB는 "더 나은"버전의 JSON입니다.

예를 보자.

SELECT '{"c":0,   "a":2,"a":1}'::json, '{"c":0,   "a":2,"a":1}'::jsonb;

          json          |        jsonb 
------------------------+--------------------- 
 {"c":0,   "a":2,"a":1} | {"a": 1, "c": 0} 
(1 row)

1. JSON은 공백을 저장하므로 키 "a"가 저장 될 때 공백을 볼 수 있지만 JSONB는 공백을 볼 수 없습니다.
2. JSON은 키의 모든 값을 저장합니다. 이것이 "a"키에 대해 여러 값 (2 및 1)을 볼 수있는 반면 JSONB는 마지막 값만 "저장"합니다.
3. JSONB는 요소가 삽입되는 순서를 유지하고 JSONB는 "정렬 된"순서를 유지합니다.
4. JSONB 객체는 JSON에서 "원시 데이터"와 달리 압축 해제 된 바이너리로 저장되며, 검색 중에 데이터를 다시 분석 할 필요가 없습니다.
5. JSONB는 인덱싱도 지원하므로 상당한 이점이 있습니다.

일반적으로 객체 키 순서에 대한 레거시 가정과 같은 특수한 요구가없는 한 JSONB를 선호해야합니다.

나는 오늘 pgopen에 있었고 벤치 마크는 mongodb보다 훨씬 빠르며 선택에 대해 약 500 % 더 빠르다고 생각합니다. mongodb와 비교할 때 적어도 모든 것이 적어도 200 % 빠릅니다. 단 하나의 예외는 mongodb가 더 잘 처리하는 전체 json 열을 완전히 다시 작성 해야하는 업데이트입니다.

jsonb의 진 인덱싱은 놀랍습니다.

또한 postgres는 내부적으로 jsonb 유형을 유지하며 기본적으로 숫자, 텍스트, 부울 등의 유형과 일치합니다.

jsonb를 사용하여 조인도 가능합니다

저장 프로 시저에 PLv8을 추가하면 기본적으로 node.js 개발자에게는 꿈이 될 것입니다.

이진 jsonb로 저장되면 모든 공백을 제거하고 속성 순서를 변경하며 속성의 마지막 발생을 사용하여 중복 속성을 제거합니다.

json 열과 대조되는 jsonb 열에 대해 쿼리 할 때 인덱스 외에도 postgres는 실제로 모든 행에서 텍스트를 json으로 변환하는 기능을 실제로 실행할 필요가 없으므로 막대한 시간을 절약 할 수 있습니다.

데이터 유형 json과 jsonb데이터 유형 의 차이점에 대해서는 공식 설명을 언급 할 가치가 있습니다.

PostgreSQL은 JSON 데이터 저장을위한 두 가지 유형을 제공합니다 : json및 jsonb. 이러한 데이터 유형에 대한 효율적인 쿼리 메커니즘을 구현하기 위해 PostgreSQL은 8.14.6 절에 설명 된 jsonpath 데이터 유형도 제공합니다 .

json및 jsonb데이터 유형을 입력으로 거의 동일한 값 세트를 받아 들인다. 주요한 실질적인 차이점은 효율성 중 하나입니다. json데이터 유형을 저장 처리 기능을 각각 실행한다 재분석에 입력 된 텍스트의 정확한 사본; 상태 jsonb데이터가 저장되는 어떠한 파싱이 필요하지 않기 때문에, 매우 빠른 처리에 의한 추가 이진 변환 오버 약간 느린 입력을 만드는 형식이지만 분해. jsonb인덱싱도 지원하므로 중요한 이점이 될 수 있습니다.

json유형은 입력 텍스트의 정확한 사본을 저장 하기 때문에 토큰간에 의미 상 미미한 공백과 JSON 오브젝트 내의 키 순서를 보존합니다. 또한 값 내의 JSON 오브젝트에 동일한 키가 두 번 이상 포함되어 있으면 모든 키 / 값 쌍이 유지됩니다. (처리 기능은 마지막 값을 작동 값으로 간주합니다.) 대조적으로,jsonb 공백을 보존하지 않고 오브젝트 키의 순서를 보존하지 않으며 중복 오브젝트 키를 유지하지 않습니다. 입력에 중복 키가 지정되면 마지막 값만 유지됩니다.

일반적으로 대부분의 애플리케이션은 JSON 데이터를 jsonb 객체 키 순서에 대한 레거시 가정과 같은 특수한 요구가없는 한 .

PostgreSQL은 데이터베이스 당 하나의 문자 세트 인코딩 만 허용합니다. 따라서 데이터베이스 인코딩이 UTF8이 아닌 한 JSON 유형이 JSON 스펙을 엄격하게 준수하는 것은 불가능합니다. 데이터베이스 인코딩에 표시 할 수없는 문자를 직접 포함 시키려고하면 실패합니다. 반대로 데이터베이스 인코딩으로 표현할 수 있지만 UTF8로는 표현할 수없는 문자는 허용됩니다.

출처 : https://www.postgresql.org/docs/current/datatype-json.html

위의 답변에서 언급되지 않은 또 다른 중요한 차이점은 json유형에 대한 항등 연산자가 없지만에 대한 것입니다 jsonb.

당신이 사용할 수 없다는이 수단 DISTINCT이 선택시 키워드 json테이블에서 타입 및 / 또는 다른 필드는 (당신이 사용할 수있는 DISTINCT ON대신에, 그러나 때문에 같은 경우의 항상 불가능 이 ).

내가 말할 수있는 한,

• hgre는 현재 존재하므로 Postgresql 9.3에서 다른 객체와 배열을 키 / 값 쌍의 값으로 중첩 할 수 없습니다. 그러나 향후 hstore 패치는 중첩을 허용합니다. 이 패치는 9.4 릴리스에 포함되지 않으며 곧 포함되지 않을 수도 있습니다.

• 은 현재 존재하는 JSON는 않습니다 중첩을 허용하지만, 텍스트 기반이며, 색인을 허용하지 않으며, 따라서는 "천천히"

• 9.4와 함께 출시 될 jsonb는 json의 현재 중첩 기능과 hstore의 GIN / GIST 색인을 가지므로 빠릅니다.

postgresql 9.4에서 일하는 사람들은 새로운 빠른 jsonb 유형이 MongoDB와 같은 noSQL 데이터 저장소를 사용하기로 선택한 사람들에게 호소하지만 이제는 관계형 데이터베이스를 쿼리 가능한 비정형 데이터와 한 지붕 아래에서 결합 할 수 있다고 말합니다.

http://www.databasesoup.com/2014/02/why-hstore2jsonb-is-most-important.html

PostgreSQL 9.4 jsonb의 벤치 마크는 MongoDB보다 빠르거나 어떤 경우에는 빠릅니다.

http://texture.io/alphabetum/postgresql-incl-hstore-vs-mongodb