데이터아키텍처전문가 - 국가공인자격 테이블의 수직분할과 수평분할에 대한 이해

이병국의 개발자를 위한 DB 이야기: 성능(38회)

테이블의 수직분할과 수평분할에 대한 이해

성공과 실패의 경험을 나누자, 용기와 희망을 나누자

개발업무를 시작으로 IT계에 입문했던 필자가 10년 가까이 DB 엔지니어로서 활동하면서 얻은 경험과 지식을 나누고자 한다. DB를 자주 접하는 SW 개발자뿐 아니라, DB 전문가를 꿈꾸는 대학생에서 DB 분야에 입문한 지 1~2년 된 기 입문자가 쉽게 이해할 수 있도록 비유를 통해 쉽게 접근해볼 계획이다. 물론 전문가들이라도 다시 한번 개념을 정립하는 데 필요한 내용이 될 수 있다.

전체적으로 DB의 기본 원리와 개념을 이해하고 테이블, 인덱스, 쿼리, 튜닝, 플랜 등 개발자들이 알아야 하는 DB 전 분야에 대해 쉽게 이해하도록 설명하겠다. DB 기술서적이나 번역서보다는 조금 더 부드럽게 접근할 계획이다. 그렇다고 흔히 서점에서 만날 수 있는 개발자 위주의 SQL 소개서도 아니다. 이 연재는 시리즈로 나갈 것이다. 연재를 끝까지 읽는 독자라면 준전문가 수준의 DB 원리를 이해하는 것을 목표로 한다.

예전에는 배우자를 만나 결혼을 하면 그 생활이 대체로 유지되었다고 한다. 하지만 요즘은 시작보다 결혼 생활을 잘 유지함과 헤어짐이 더 중요한 시대가 된 것 같다. 누구나 상대를 만나서 결혼할 때는 많은 사람의 축복을 받으면서 행복한 가정을 꿈꾼다. 하지만 상대방에 대한 좁힐 수 없는 차이를 발견하고 현실의 벽 앞에서 많은 좌절을 하게 된다. 헤어지는 과정에서 자녀 양육에 대한 문제와 재산 분할에 대한 문제 등으로 힘든 과정을 겪는 것을 보게 된다. 그럼에도 이유가 반드시 있기에 서로 갈라서는 것이다. 

이번 연재는 테이블의 수직분할(Vertical Partitioning)과 수평분할(Horizontal Partitioning)에 관한 내용이다. 합치는 것보다는 나누는 것이 어렵다는 말이 있듯이 테이블의 분할에는 많은 어려움이 뒤따른다. 기존에 설계된 테이블 구조를 변경해야 하고, 이미 개발된 프로그램에 많은 변경을 해줘야 하기 때문이다. 그럼에도 성능의 문제를 해결하기 위해 테이블을 나누어야 하는 경우를 우리는 간혹 경험한다. 이러한 원인은 DB 설계 시 정규화에 소홀했거나 용량 산정을 잘못 계산했기 때문이다. 

이유 없는 무덤 없듯이 처음 설계 시에 그렇게 잘못된 설계를 할 수밖에 없는 이유가 반드시 있게 마련이다. 개발 일정상의 문제 혹은 기술인력 지원상의 문제 등으로 인하여 정규화 과정을 무시하거나 소홀히 하는 경우가 종종 발생한다. 그럼에도 정규화는 반드시 되어야 한다. 일부 소규모 회사나 1인 기업에서는 DB 설계 없이 소프트웨어를 개발하는 경우도 있다. 이는 말도 안 되는 일이다. 설계 없이 짓는 건축물이 얼마나 위험한 일인지 누구나 다 알듯이 DB 설계 없는 프로그램 개발은 아주 무모한 행동이다.

테이블의 수직분할과 수평분할

테이블의 수직분할은 컬럼을 기준으로 테이블을 분리하는 것을 의미하고 수평분할은 Row를 기준으로 테이블을 분리하는 것이다. 테이블을 분리하는 이유는 성능 개선을 위한 것이다. 기본적으로 테이블의 Row 수가 많을수록 Index에 대한 부하가 따르고, 테이블의 컬럼 수가 많을수록 I/O에 대한 부하가 걸린다. 그렇다고 모든 테이블이 분리를 통해 성능 개선의 효과를 보는 것은 아니다. 하지만 대용량이면서 성능 이슈가 있는 테이블은 분리를 통한 성능 개선을 검토해 볼 필요가 있다. 

테이블의 수직분할과 수평분할에 대해 정확히 이해하는 개발자는 그리 많지 않다. 뭔지 모르지만 특별한 것이 있을 것이라고 생각하거나 나와는 무관할 거라고 생각하는 경향이 있다. 하지만 [그림 1]을 보면, 테이블의 수직분할과 수평분할이 그리 특별한 게 아님을 알 수 있다.

[그림 1] 테이블의 수직분할과 수평분할

[그림 1]과 같이 테이블을 수직으로 나누면 수직분할이 되고 수평으로 나누면 수평분할이 된다. 이보다 더 쉬울 수는 없다. 우리는 이 그림에서 컬럼을 기준으로 나누는 것이 수직분할이고, Row를 기준으로 나누는 것이 수평분할이라는 사실을 쉽게 알 수 있다.

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com

테이블의 수직분할

수직분할(Vertical Partitioning)은 컬럼을 기준으로 테이블을 분리 한다는 것을 이미 언급했다. 만약 한 테이블에 수많은 컬럼이 존재한다면 디스크의 여러 블록에 데이터가 저장되므로 I/O 성능 저하를 불러올 수 있다. 이렇게 컬럼이 많아지면 로우 체이닝과 로우 마이그레이션이 많아져서 성능이 저하된다.

로우 체이닝(Row Chaining)
길이가 너무 커서 하나의 블록에 저장되지 못하고 다수의 블록에 나누어져 저장

로우 마이그레이션(Row Migration)
수정된 데이터를 해당 데이터 블록에 저장하지 못하고 다른 블록의 빈 공간에 저장

로우 체이닝과 로우 마이그레이션이 발생하여 많은 블록을 사용하게 되면, 불필요한 I/O가 발생하여 성능이 저하된다. 많은 I/O 발생은 성능에 직접적인 영향을 주므로 매우 중요한 문제다. 또한 데이터에 대한 범위 검색을 할 경우 더 많은 I/O를 유발하므로 성능 저하를 일으킨다. 수많은 컬럼을 동시에 조회하는 경우는 드물다. 각각의 조회 조건에 맞게 이용되는 컬럼들로 그룹을 묶어서 테이블 분할을 검토할 수 있다. 조회나 처리에 대한 분산을 가능하게 하는 칼럼들을 기준으로 테이블을 분리한다면 성능 개선에 큰 도움이 될 수 있다. 



[그림 2] 수직분할의 예시

테이블의 수평분할

수평분할(Horizontal Partitioning)은 Row를 기준으로 테이블을 분리한다는 것을 앞서 언급했다. 만약 한 테이블에 대량의 데이터가 존재하고 트랜잭션이 몰린다면 성능 저하를 피하기 어렵다. 대량의 데이터가 하나의 테이블에 있으면 인덱스 정보 생성 시 부하가 커진다. 인덱스를 찾아가는 깊이(Depth)가 깊어지게 되고 인덱스의 크기가 커질수록 더 많은 성능 저하를 불러온다. 조회하는 성능보다는 데이터를 처리하는 성능에 더 큰 영향을 미치게 된다. 이런 경우 트랜잭션이 분산 처리될 수 있도록 테이블 수평분할을 검토해야 한다. 

데이터 건수가 수천만 건을 넘고 처리가 많이 일어난다면 성능을 제대로 발휘할 수 없다. 이때 논리적으로는 같은 테이블이지만 물리적으로 서로 다른 여러 개의 테이블 스페이스에 나누어서 저장하는 파티션 방법을 이용하면 성능 개선에 큰 도움이 된다. 

파티션 종류로는 Range, Hash, List, Composite 파티션이 있다. 가장 널리 이용하는 Range 파티션은 주로 날짜를 기준으로 하는 경우가 많다. 이 경우 데이터가 균등하게 나누어져서 비슷한 성능 개선을 보장한다. 또한 보관 주기에 따라서 필요치 않는 데이터도 쉽게 지우고 관리할 수 있다. [그림 2]와 같이 분류가 가능한 PK 컬럼을 이용한 List 파티션도 많이 사용한다. 



[그림 3] 수평분할()의 예시

수직분할과 수평분할의 결정

테이블의 컬럼 개수와 데이터 양을 종합적으로 판단하여 양에 따른 대용량 테이블인지한다. 만약 컬럼 개수에 따른 것이라면, 트랜잭션의 특성에 따라 테이블을 1:1 형태로 분리하는 수직분할을 하면 된다. 반면 데이터 양에 따른 것이라면, 적절한 파티션을 선택하고 여러 개의 물리적 스페이스로 저장하는 수평분할을 하면 된다. 결론은 컬럼 단위의 트랜잭션인지 로우 단위의 트랜잭션인지 판단하면 된다. 

이번 연재의 내용은 테이블 분할에 따른 성능 개선에 관한 내용으로서 테이블의 수직분할은 컬럼을 기준으로 하고, 테이블의 수평분할은 Row를 기준으로 한다는 것이 핵심이다. (다음 회에 계속)

출처 : 한국데이터진흥원

제공 : 데이터 전문가 지식포털 DBguide.net

[출처] http://www.dbguide.net/knowledge.db?cmd=view&boardUid=196125&boardConfigUid=19&boardStep=&categoryUid=$categoryUid