빠른 탐색을 위한 innodb 스토리지엔진 테이블 설계 질문 드립니다.

Question

안녕하세요. 현재 테이블 설계를 하고 있는데, 몇 가지 궁금한 점이 있고 트레이드 오프를 고려하기 어려워 선배님들께 여쭤보고자 합니다.해당 테이블에 대한 설명은 다음과 같습니다.하나의 ROW를 식별하는 데에는 두 개의 키가 필요합니다. 이를 각각 key_a, key_b 라고 하겠습니다.식별을 위한 key_a와 key_b의 조합은 중복되는 경우가 없습니다.두 개의 키는 Range Scan 및 like operation 연산의 대상이 아닙니다. 오직 동등비교 연산만 수행합니다.식별된 하나의 ROW에 대해 단일 update가 굉장히 빈번하게 일어납니다.해당 테이블은 insert 및 update, select만 발생하며 delete는 발생하지 않습니다.해당 테이블의 속성은 매우 적으며, group by 혹은 order by의 연산 대상이 아닙니다.해당 테이블은 다른 테이블과 자주 조인이 이루어집니다. 조인의 경우에도 주로 key_a와 key_b를 이용합니다.JPA를 사용합니다.현재 고려하고 있는 구조 2가지는 다음과 같습니다.먼저, 첫 번째 구조입니다.primary key로 auto increment한 값을 가집니다. (사실상 PK로 조회되는 일은 거의 없을 겁니다.)key_a와 key_b를 복합 유니크 인덱스로 설정합니다.key_for_unique_idx 컬럼을 추가하고, 이 컬럼을 유니크 인덱스로 등록합니다. (hash index)애플리케이션에서의 조회 및 업데이트는 key_for_unique_idx로 수행합니다.id (primary key, auto increment)key_akey_bkey_for_unique_idxdata...1aaa-adata...2aba-bdata...두 번째 구조입니다.primary key로 key_a와 key_b를 복합키 (Primary Key)로 설정합니다.애플리케이션에서의 조회 및 업데이트는 PK (key_a와 key_b)를 이용하여 수행합니다.key_akey_bdata...etc...aadata...etc...abdata...etc...제 생각으로는 Innodb의 Primary Key 및 인덱스 동작 방식을 본다면 두 번째 구조가 훨씬 더 적합할 것 같으나,실무에서 복합키를 Primary Key로 두고 써본 경험이 없고, 아직까지 그런 사례를 접해보지 못하여 제가 아직 놓친 부분이 있을까 두려운 마음에 질문을 드리게 되었습니다.정말 기초적인 질문이라도, 많은 고견 주시면 정말 감사드리겠습니다. ( _ _ )

쿠잉 · Answer

두번째 구조로 대로 2개 컬럼 유니크 인덱스만들고 pk는 auto increment 쓰세요

캐티 · Answer

전체 데이터 rows는 면 행이나 되겠나요.적은 분량이라면 글케까지 영향을 받지 않을 것이빈다.숫자 타입에 기본키는 중요하여요. pk로 조회 하지 않더라도 db자체에서 마지막 엑세스 지점 캐싱 최적화 같은데서 사용할 것이어요.단순히 key-value 를 하려면 pk를 다른 데이터 타입과 여럿 칼럼으로 처리하빈다.

초무쿤 · Answer

1번을 대리키를 사용한다고 하고2번은 자연키를 사용한다고 하는데.보통 비지니스를 다루는 데이터모델 설계 가이드 등은특별한 경우가 아니라면 2)자연키를 사용하는 것을 권장하긴 합니다.(1처럼 대리키를 사용하는 경우는 보통 딱히 고유키값이 없는 누적데이터 등 적재)복합키 관련 JPA 는 그냥 &#64;IdClass 를 사용하면 되기 때문에 별 문제될거는 없어보여요.

빠른 탐색을 위한 innodb 스토리지엔진 테이블 설계 질문 드립니다.

3개의 답변

#innodb 목록