2014-12-30 3 views
7

PostgreSQL의 jsonb 열 유형을 주로 REST-ful JSON API로 사용되는 새로운 백엔드 프로젝트에 사용하려고합니다. PostgreSQL의 jsonb은 백엔드에서 변환 할 필요없이 JSON 객체를 제공하므로이 프로젝트에 적합 할 것입니다.jsonb 및 기본/외래 키 : PostgreSQL에서 성능이 더 좋습니까?

그러나 키가 추가 될 때 jsonb 데이터 형식이 느려지고 내 스키마에 기본 키와 외래 키 참조가 필요할 것이라고 읽었습니다.

기본 키/외래 키를 표준 관계형 데이터베이스 방식으로 자신의 열에 넣은 다음 나머지 데이터에 대해 jsonb 열을 사용하면 유익한 지 궁금 해서요. 또는 아래로)? 한마디로

, 것 : 자주 외래 키를 찾는 특히

table car(data jsonb) 

:

table car(id int, manufacturer_id int, data jsonb) 

보다 더 좋거나 더 나쁜 수행?
퍼포먼스 또는 스키마 관점에서 첫 번째 단점이 있습니까? PRIMARY KEY 또는 FOREIGN KEY 제약 해야에 참여

+0

왜 'jsonb'를 사용하고 싶습니까? 당신이 다소 고정 된 스키마를 가지고 있고 JSON으로 행을 변환하는 것이 당신이 그것에 대해 걱정할 필요가 없을만큼 빠르다고 생각됩니다. –

+0

좋은 질문 : 필자의 스키마가 필요로하는 관계에 대해 잘 알고 있지만이 시점에서는 각 테이블에 필요한 정보를 구체적으로 이해하지 못하고 매번 데이터베이스 마이그레이션을 수행 할 수 있습니다 나는 jsonb를 사용하여 좋은 성능과 물건을 빠르게 추가하는 쉬운 방법을 결합 할 수 있다고 생각합니다. 나중에 언젠가는 데이터를 더 구체적으로 이해하고 나면 좋은 관계형 설정으로 돌아갈 수 있습니다. 그러나 그것은 질문의 요점 옆에 있습니다. 즉, 한 사람이 다른 사람보다 더 잘 수행 할 수 있습니까? –

+1

하지만 JSON을 다시 작성하기 위해서는 어쨌든 많은 마이그레이션 작업을해야 할 것입니다. 몇 가지 ALTER TABLE을 여기 저기에 두어 두려워해서는 안되며, 끊임없이 변화하는 스키마를 추적하기 위해 모든 데이터와 코드를 다시 작성해야합니다. 더 무섭다. 질문에 대한 답변을 얻으려면 먼저 올바른 질문을해야합니다. 나는 당신이 데이터를 훔치기 시작하기 전에 당신의 데이터가 어떻게 생겼는지 알아낼 필요가 있다고 생각한다. 만약 당신이 그것을 생각하고 다시 돌아가서 당신이 거의 틀린 데이터베이스를 재 설계한다면, 그것은 일어나지 않을 것입니다. –

답변

12

모든 값은 (정규화 된 형태로 최고) 전용 열로 저장 될 수있다. 제약 조건 및 참조는 json/jsonb 열 안에 중첩 된 값에 대해서는 작동하지 않습니다.

나머지 데이터는 다음과 같습니다. 입니다. jsonb (바람직하게) 값 내부에 이들을 갖는 것은 구조화되지 않은 문서 유형 데이터를 저장하는 잘 알려진 장점과 단점을 가지고 있습니다.

전체 또는 대부분의 행에 나타나는 속성의 경우 별도의 열로 저장하는 것이 더 빠를 수 있습니다 (더 빠르고 깨끗하며 작은 저장 공간). 더 쉬운 색인 생성 및 간단한 쿼리. 새로운 jsonbamazing index capabilities이 있더라도 전용 열의 인덱싱은 여전히 ​​더 간단하거나 빠릅니다.

거의 사용되지 않거나 동적으로 나타나는 속성의 경우 또는 DB 내에서 많이 처리하지 않고 JSON 값을 저장하고 검색하려는 경우 jsonb을 찾습니다.

주로 문자 데이터가있는 EAV structures의 경우 중첩하지 않고 JSON에 연결하지 않고 hstore을 고려합니다. xml (더 복잡하고 자세한 정보) 및 json 데이터 유형 (대부분이으로 대체되어 jsonb으로 대체 됨)이 손실 될 수 있습니다.

+1

넵 ... "그것은 다릅니다". 여기서 다루지 않은 한 가지 문제는 jsonb 값의 * * 모든 하위 필드를 업데이트 할 경우 * 전체 튜플 *을 다시 작성해야하며이를 가리키는 모든/모든 인덱스를 업데이트해야한다는 것입니다.pk/fk 관계가있는 엔티티로 데이터를 분해 한 경우에는 더 이상 그렇지 않습니다. 전체를 다시 작성하지 않고도 일부만 삽입/업데이트/삭제할 수 있습니다. –

+0

@CraigRinger 포스트 그레스 9.5에서도 여전히 그렇습니까? 나는이 섹션을 릴리스 문서에서 읽은 후에 물어 봅니다. https://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.5#JSONB-modifying_operators_and_functions – t1m0

+3

@ t1m0 예. TOAST 라인 외부 스토리지 및 MVCC에 내재되어 있습니다. PostgreSQL은 이제 jsonb 객체를 완전히 해체하고 재구성 할 필요없이 수정할 수 있습니다.하지만 메모리 내 수정입니다. 여전히 디스크에서 모든 것을 읽어야하고 새 수정 된 버전을 새 튜플에 다시 써야합니다. –

2

성능이 더 좋습니까? 사용법에 달려있다. SQL (관계형) 및 NoSQL (KeyValue 또는 Document) 데이터베이스를 비교할 때도 동일한 질문입니다. 일부 유스 케이스의 경우 NoSQL 데이터베이스는 다른 데이터베이스에 비해 성능이 뛰어납니다.

관계 개념 (정규화 된 스키마)은 일반 OLTP 사용법 (읽기/쓰기 30 %, 다중 사용자, 많은 업데이트, 보고서 계산, 일부 특별 쿼리)에 최적화되어 있습니다. 관계 개념은 비교적 광범위합니다.매우 광범위한 유용성 (증거, 회계, 프로세싱 지원, ...). 일반적으로 모든 곳에서 나쁘지 않습니다.

전문화 된 사용 사례에서 전문화 된 데이터베이스 (Document, KeyValue, Graph)가 훨씬 더 빠를 수 있습니다 (한 단계 빨라짐). 그러나 그 사용법은 상당히 좁습니다. 최적화 된 유스 케이스를 벗어나면 성능이 저하 될 수 있습니다.

기타 질문은 데이터베이스 크기 - 레코드 번호입니다. 프로덕션 데이터베이스의 성능 차이는 십만 행에서 상당 할 수 있습니다. 더 작은 데이터베이스의 경우 영향이 중요하지 않을 수 있습니다.

Postgres는 관계형 데이터베이스이며 데이터베이스의 모든 중요한 데이터에 정규화 된 스키마를 사용하는 것이 좋습니다. 잘 사용하면 끔찍합니다. 비 관계 유형은 일부 퍼지 데이터 (HStore, JSON, XML, Jsonb)에 완벽합니다. 이는 EAV 스키마보다 훨씬 뛰어납니다 (더 큰 데이터에서 성능이 저하됩니다).

중요한 결정이 필요한 경우 프로토 타입을 준비하고 예상 데이터 (3 년)를 채우고 시스템에 대한 중요한 쿼리 속도를 확인하십시오. 주의 :이 벤치 마크에 대한 강한 영향은 hw, 현재 부하, 현재 sw를 사용했습니다.

관련 문제