왜 Column-Oriented DBMS이 등장하게 되었을까?
- 기존의 Relational DBMS는 Row형으로 데이터를 저장한다.
Row-Oriented DBMS는 데이터를 어떻게 저장할까?
- 주로 Row-Value 데이터를 연속적으로 저장한다.
실제로 테이블의 데이터파일 모습은?
- 일렬로 저장된 모습을 확인할 수 있다.
- Row-Value의 오프셋은 Value의 자료구조에 의존적이다.
32bit의 Integer,64bit의 Integer,String등 자료구조의 크기의 총 합산 크기에 따라 오프셋을 결정한다.
위 형태의 데이터 파일을 쉽고 빠르게 읽기 위해선?
- 데이터 파일의 크기를 결정하고 이를 통해 쉽게 Position을 구할 수 있다.
- 구해진 Position을 통해 쉽게 접근이 가능할까?
현실세계에서는 그리 쉽지 않다.
varchars라는 타입을 생각해보면 매우 다양한 value의 크기를 확인할 수 있다.- 이는 곧 Position을 계산하기 어렵게 만들며 빠르게 Record를 읽을 수 없게 만든다.
위 방법을 조금 개선해보면?
value를 저장할 수 있는 여분의 저장소를 추가하고 저장 주소를 values에 담는 형식이다.- 위 방법으로 Position을 쉽게 구할 수 있지만 여분의 저장소가 필요한 단점이 있다.
Row-Oriented를 정리하면
- 장점
- 하나의 Row 데이터를 추가/삭제할때 하나의 페이지만 사용하기에 좋다.
- 하나의 Row의 대부분의 컬럼을 읽어야 하거나 변경하는 경우 하나의 Read/Write로 가능하다.
- 단점
- 모든 Row를 읽는 경우 불필요한 Column값을 다 읽어야 한다.
- Page의 사용하지 않는 공간까지 읽어야 한다.
Example
c1이라는 컬럼의 값을 조회하고 싶은 경우- 우리는 2번째 페이지까지 읽어야 모든 데이터를 얻을 수 있다.
아래의 그림처럼 우리는 1 Read로 모든 데이터를 가져오고 싶다.
이러한 문제를 해결하기 위해 Column Oriented DBMS가 등장했다.
Column Oriented DBMS란?
Row형으로 저장하는 대신Column으로 저장하는 방식이다.- 모든
Column들은 개별적으로 다뤄지며Column별로 연속적으로 저장된다. Column별로 데이터가 저장되기때문에 압축에도 높은 효율을 얻을 수 있다.
Row Oriented vs Column Oriented
- 우리가 평균 가격을 알고 싶다면?
Row Oriented는 모든 Row를 조회해야만 결과를 얻을 수 있다.- 하지만
Column Oriented는 Price 컬럼만 조회해도 결과를 얻을 수 있다.
항상 Column Oriented가 좋을까?
- 다수의 컬럼을 조회하는 상황이라면 쓸모가 없어보인다.
- 오히려 결과를 합치는 작업 비용이 더 커져서 느릴 경우가 발생할 거 같다.