세상의 사건들을 이해하는 데에는 여러 가지 시각이 있을 수 있습니다.
이를테면 2011년 현재, 정치적 핫 이슈인 '한미FTA'라는 것도 '자유 무역을 증진시켜 경제 활성화에 이바지할 것이다'라는 주장과 '아직 성숙하지 않은 국내 제반 법제나 기타 공공 복지 정책에 심각한 피해를 줄 것이다'라는 주장이 맞섭니다(cf. FTA 논쟁). 단적인 또 다른 예로는, 컵에 물이 반이 있을 때 이걸 '반 밖에 안 남았네' 와 '반이나 남아 있네'라고 보는 시각차도 있을 것입니다.
이런 시각차의 존재는 전산 분야라고 예외는 아닙니다. 'GOTO 문을 절대 쓰면 안 된다'라는 주장과 'GOTO, 필요하면 쓸 수도 있지.'라는 주장이 있고(cf. GOTO), 'big-endian이 낫다'와 'little-endian이 낫다'라는 주장도 서로 맞섭니다(cf. endianness). 마치, '엄마가 좋아? 아빠가 좋아?'라는 물음처럼 답이 없는 문제들이죠(cf. 세상에서 가장 어려운 질문).
이 글에서 얘기하려는 'row-oriented 방식'과 'column-oriented 방식'도 어떻게 보면 데이터 저장 방식에 대한 서로 다른 시각차라고 할 수 있습니다.
위와 같은 테이블 형태의 데이터는 RDBMS에서 많이 사용하는 전통적인 예제인데, 이것을 저장하는 방식은 다음과 같이 두 가지로 나눌 수 있습니다.
방식 1. (학년, 반, 번호, 이름)을 하나의 레코드로 저장
방식 2. (학년) (반) (번호) (이름) 데이터들을 하나의 집합으로 보고, 별도 영역에 저장
보통 1번을 'row-oriented 저장 방식', 2번은 'column-oriented 저장 방식'이라고 부르는데, 각 저장 방식은 각각의 장단점이 있습니다. 이것의 장단점에 대해 이야기하려면 통상적인 DISK의 구조라든지 seek time, 데이터 페이지 구성 좀 더 로우레벨(low-level) 토픽들을 이야기해야 하는데 그렇게 되면 내용이 다소 길어지므로 각각의 장단점에 대해서는 다음 포스팅에서 다루도록 하겠습니다.
row-oriented 방식에서는 어떤 하나의 완결된 데이터 - 레코드를 꺼내 보고 싶을 때(SELECT), 또는 하나의 레코드를 갱신(UPDATE)해야 할 때, 바로 그 레코드 하나에 대해서만 접근해서 연산을 수행하면 됩니다. 이 방식의 장점은 단위 연산이 무척 빠르다는 것입니다. 하지만 전체 데이터 집합에서 '학년'에 해당하는 필드 값들만을 읽어 들이고 싶을 때는 불필요하게 '반', '번호', '이름' 필드들도 같이 읽어야 한다는 단점이 있습니다.
column-oriented 방식에서는 반대로 특정 필드 값 전체를 읽어 들여서 작업 수행을 하고자 할 때, 그 필드가 저장된 영역만을 한 번만 스캔하면 된다. 이 때문에 연산 효율이 상당히 높습니다. 또한, 레코드의 특정 필드 값을 업데이트하고자 할 때 다른 필드 값이 저장된 영역은 건드리지 않아도 되는 장점이 있습니다. 그러나 하나의 완결 레코드를 구성하기 위해서는 각 필드 값들이 저장된 영역을 다 뒤져서 일일이 가져와야 하는 단점이 있죠.
따라서 각 저장 방식에 적합한 응용 분야는 차이가 있습니다. 레코드에 대한 빠른 읽기/쓰기 작업이 필요한 OLTP(Online Transaction Processing) 환경에서는 보통 row-oriented 저장 방식을 선호하고, 모든 레코드 필드 값을 배치(batch)로 다 읽어 들여서 통계나 기타 분석 작업 수행이 필요한 OLAP(Online Analytical Processing) 환경에서는 column-oriented 저장 방식이 유리합니다. 그러나 반드시 OLTP면 row-oriented로, OLAP이면 column-oriented로 저장하는 것이 좋다는, 이분법 사고를 할 필요는 없습니다. row-oriented 방식으로도 수십~수백 테라 바이트의 데이터 분석 처리가 가능한 RDBMS들이 존재하니깐 말이죠(ex. Teradata). 반대의 경우도 마찬가지입니다. 두 개의 방식 중 어떤 것을 쓰더라도 잘(!) 만들면 불가능은 사실, 없습니다. 다만, 물리적으로 각 방식의 장/단점은 분명 있으므로 취사/선택해서 쓰면 그만인 것이죠.
코난테크놀로지의 주력 사업 분야 중 하나는 기업용 검색 엔진입니다. 검색엔진이 수행하는 주 작업 - 검색 - 이 보통 OLTP라고 볼 수 있기 때문에 과거에는 row-oriented 방식에 많이 의존하고 있었습니다. 하지만, 점점 대용량화되는 검색 데이터들에 대한 분석 작업이나 기타 실시간으로 변하는 특정 필드 값들에 대한 추적/변경 작업의 용이성을 위해 최근에는 앞서 얘기한 column 방식의 저장 구조도 도입하게 됐습니다. 아직 기본(그렇다고 이 기본을 만들기 위해 쏟아 부은 우리 팀원들의 열정은 결코 적지 않았다는...) 단계라 가야 할 길이 아직 남아있긴 하지만, 멀지 않은 시점에 우리 엔진을 쓰는 여러 고객들에게 조그만 기쁨(?)을 안겨줄 수 있게 되길 희망해 봅니다.
'코난 知(지) 이야기 > Trend & Tech' 카테고리의 다른 글
| [미디어] N스크린 콘텐츠의 통합관리 2부 (0) | 2012/01/17 |
|---|---|
| [검색] 기업검색 관점으로 살펴본 2012년 전략 기술 10가지 (0) | 2011/11/23 |
| [검색] row vs. column (2) | 2011/11/17 |
| [검색] 텍스트의 재발견, Hello, Text! (0) | 2011/11/09 |
| [미디어] N스크린 콘텐츠의 통합관리 1부 (0) | 2011/11/01 |
| [검색] 아이언맨의 자비스 시스템을 만들기 위한 고민들 (2) | 2011/11/01 |
댓글을 달아 주세요
8miles 2011/11/23 17:21 댓글주소 수정/삭제 댓글쓰기
흥미로운 글 잘 봤습니다.
비가 올 확률이 50%라고 하면 이건 비가 오는 것도 아니고 안 오는 것도 아니다라고 하시던 학교 교수님의 말씀이 생각나네요.
코난테크놀로지에 관심을 가져주셔서 진심으로 감사드립니다. 어떤 기술을 어떻게 적용할 것인지, 또 그를 통하여 얻을 수 있는 효과는 어떤 것인가에 대한 이야기는 결국 기술을 바라보는 관점을 통하여 구체화되는 것 같습니다.
더 나은 모습 보여드릴 수 있게 노력하겠습니다.
감사합니다.