인덱싱과 hstore가있는 JSONB

이 단계에서 가능한 최소한의 가정 (웹 앱이 실제로 어떻게 진화하는지에 대한 가정)으로 데이터베이스 디자인을 결정하려고합니다.

JOINS가 비싸다는 것을 이해하는 첫 번째 단계로, 표준화 된 작은 테이블이 아닌 소수의 모 놀리 식 테이블을 고려하고 있습니다. 두 번째 요점으로 hstore 대 일반 테이블 대 JSONB (GiST 색인 사용)를 사용하는 것이 혼란 스럽습니다.

AFAIK (자유롭게 수정하십시오) :

일반적으로 Postgres에서 hstore는 다른 데이터 유형보다 성능이 우수한 것으로 알려져 있습니다. FOSDEM PGDAY의 프레젠테이션에는 흥미로운 통계가 있습니다 (슬라이드 후반). https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf
hstore의 장점은 빠른 인덱싱 (GiN 또는 GiST)입니다. 그러나 JSONB를 사용하면 GiN 및 GiST 인덱싱을 JSON 데이터에도 적용 할 수 있습니다.
2 사분면에서 전문에서이 블로그는 (끝까지 스크롤) "이 시점에서 모든 새로운 애플리케이션에 jsonb와 hstore 사용을 대체 아마 가치"라고 : http://blog.2ndquadrant.com/postgresql-anti-patterns-unnecessary -jsonhstore- 동적 열 /

따라서 다음을 결정하고 싶습니다.

데이터의 주요 (구조화 된) 부분 : 몇 개의 관계형 테이블 (상대적으로 열이 많음)에 두어야합니까, 아니면 hstore를 사용하는 여러 키-값 저장소 여야합니까?
임시 (사용자 제공 / 구조화되지 않은) 데이터의 경우 hstore의 JSON 또는 임시 키 값 저장소에 있어야합니까 (주 관계형 테이블 중 하나에 키가 저장된 상태)?

postgresql database-design

— 요게 쉬
소스

조인은 비싸지 않습니다. 누가 당신에게 말 했어요? 기본적으로 관계형 데이터베이스의 전체 개념은 (실제적인 관점에서) 조인을 중심으로 이루어 지므로 이러한 제품은 조인에 매우 능숙합니다. 정상적인 사고 방식은 제대로 표준화 된 구조로 시작하여 퍼포먼스가 실제로 읽기 측에서 필요할 때 멋진 비정규 화 및 유사한 것들로 진행됩니다. JSON(B)과 hstore(와 EAV) 알 수없는 구조를 가진 데이터에 좋다.

— dezso

@Yogesch 해당 링크에는 흥미롭고 모순되는 내용이 포함되어 있습니다. :) 도덕적으로 MySQL은 조인에 나쁜 것처럼 보였으며 NoSQL 사람들은 실제 사실을 기반으로하지 않고이 개념을 일반화하는 경향이 있습니다. 반면에 Aaron과 Max는이 p-word에 민감합니다. 광범위하게 사용하면 비 원어민 (자신 포함)이 잘못된 단어를 어떻게 행복하게 사용하는지 알 수 있습니다.

— dezso

@Yogesch 현실적으로 나는 어떤 종교적 텍스트라도 잔혹성을 정당화하는 데 사용될 수있는 것처럼 (역사 전체에 걸쳐 보여지는 것처럼) 인터넷을 통해 어떤 것도 "증명"할 수있는 출처가 있다고 확신한다. 일을 적게할수록 비용이 적게 드는 것은 사실이지만 , 항상 약간의 상충 관계가 있습니다 .

— Erik

@Yogesch : 데이터 액세스 패턴을 미리 알고있는 읽기 작업이 많은 경우 조인을 피하는 것이 중요하므로 필요한 모든 데이터를 단일 행에 안전하게 넣을 수 있습니다. 그러나 이로 인해 다른 조인의 잠재적 비용이 증가합니다. 다양한 질문에 대답하기 위해 다양한 방법으로 데이터에 참여할 필요가 없다고 말하는 사람은 누구입니까? 이제 관계형 데이터 모델링 이론으로 간단히

— Chris

@Yogesch 실제로 데이터베이스에서 병목 현상은 거의 RAM이나 CPU가 아니지만 I / O입니다.이 방법으로 중복 데이터 저장을 피하는 것이 여전히 중요합니다. Chris가 말했듯이 데이터를 항상 한 가지 방식으로 만 보는 경우 가격 대비 가치가 있습니다. 그렇지 않은 경우, 크고 유연하지 않은 데이터 덩어리가 있습니다.

— dezso

관계형 데이터베이스는 조인을 중심으로 설계되었으며이를 잘 수행하도록 최적화되었습니다.

정규화 된 디자인을 사용 하지 않는 적절한 이유가 없으면 정규화 된 디자인을 사용하십시오.

jsonb물건이 좋아하는 hstore당신이 경우에 좋다 할 수없는 등의 데이터 모델이 빠르게 변화하고 사용자 정의하는 경우와 같이 정규화 된 데이터 모델을 사용합니다.

관계형으로 모델링 할 수 있으면 관계형으로 모델링하십시오. 당신이 등 JSON을 고려 할 수없는 경우 경우에 당신이 사이에 선택하고 JSON / jsonb 당신이하지에 이유가없는 한 / hstore, 일반적으로 jsonb 선택합니다.

그것이 바로이 주제를 다루는 블로그 게시물 에서 말한 내용입니다. 전체 게시물을 읽으 십시오 . 인용 한 단락 은 동적 구조 를 선택하는 경우 hstore보다 jsonb를 선택해야하지만 나머지 블로그 게시물은 일반적으로 가능한 경우 관계형을 선호하는 이유에 관한 것입니다.

그래서. 주요 구조 부품을 관계형으로 모델링합니다. 열이 많은 테이블이 실제로 넓은 경우에는 추가 정규화가 필요하다는 신호일 수 있습니다. 조인을 두려워하지 마십시오. 조인을 사랑하는 법을 배우십시오. 많은 작은 테이블을 조인하면 비정규 화 된 큰 테이블을 쿼리하고 유지 관리하는 것보다 속도가 빠릅니다. 특정 경우에, 그리고 바람직하게는 구체화 된 뷰를 통해 필요한 경우에만 비정규 화하지만, 해결해야 할 실제적인 구체적인 문제가있을 때까지하지 마십시오.

자유롭고 구조화되지 않은 사용자 제공 데이터의 경우 jsonb를 사용하십시오. hstore뿐만 아니라 성능도 뛰어나야하지만 더 유연하고 작업하기가 더 쉽습니다.

이해해야 할 한 가지 : jsonb에서 사용되는 것과 같은 GiST 및 GIN 인덱스는 일반적으로 일반 b- 트리 인덱스보다 훨씬 덜 효율적입니다. 더 유연하지만 일반 열의 b- 트리 인덱스는 거의 항상 훨씬 빠릅니다.

— 크레이그 링거
소스

크레이그에게 감사드립니다. 이제 저는 훨씬 더 잘 이해하고 무엇을해야할지 알고 있습니다. 후속 질문 : 좋아요 또는 팔로어 와 같은 것을 두 열 형식 (post_id 및 user_id, likes 같은 )으로 저장하는 경우 관계형 테이블을 두 개의 열 또는 hstore와 함께 사용하는 것이 더 낫습니까? (나는 이것을 새로운 질문으로 만드는 것을 신경 쓰지 않는다)

— Yogesch

@Yogesch 일관되고 안정적인 형식의 bog 표준 m : n 조인 테이블처럼 들립니다. 문제는 항상 " 이 특정 사례에 대해 일반적인 관계 방식으로 수행하지 않아야 하는 합당한 이유가 있습니까?"입니다.

— Craig Ringer

hstore더 이상 사용되지 않습니다. 사용하십시오 jsonb.

— danger89

@ danger89 사실, 공식적으로 더 이상 사용되지 않지만 jsonb를 선호하는 이유는 없다고 생각합니다. 어쨌든 ... 그것은 요점을 놓치고 있습니다. 문제는 관계형으로 모델링하거나 구조화 된 데이터 유형을 사용할지 여부에 관한 것입니다.

— Craig Ringer