행 기반

행 기반은 데이터베이스에서 테이블의 한 줄을 의미하는 기본적인 데이터 구성 단위이다. 이는 수평 방향으로 연속된 데이터 값들의 집합으로, 하나의 완전한 개체나 항목에 대한 정보를 담고 있다. 관계형 데이터베이스에서 행은 흔히 레코드 또는 튜플이라고도 불린다.

각 행은 테이블을 정의하는 열의 구조에 따라, 각 열에 해당하는 특정 데이터 값을 포함한다. 예를 들어, '고객' 테이블에서 하나의 행은 한 명의 고객에 대한 아이디, 이름, 주소 등의 모든 속성 값을 가지게 된다. 이러한 행 기반 저장 방식은 온라인 트랜잭션 처리 환경에서 개별 레코드의 추가, 수정, 삭제 작업에 최적화되어 있다.

행 기반 저장의 대응 개념은 열 기반 저장 방식이다. 행 기반은 하나의 개체에 대한 모든 데이터를 연속적으로 저장하는 반면, 열 기반은 모든 행에 걸친 단일 속성의 데이터를 모아서 저장한다. 이 차이는 데이터 조회 및 처리 패턴에 따라 각각 다른 성능 특성을 보이게 한다.

행 기반 접근법은 은행 거래, 항공편 예약, 쇼핑몰 주문 처리와 같이 빠른 트랜잭션 처리가 요구되는 온라인 트랜잭션 처리 시스템의 핵심을 이룬다.

행 기반은 데이터를 저장하고 접근하는 방식에서 열 기반과 대비되는 핵심적인 특징을 가진다. 이 방식은 데이터베이스의 한 테이블에서 각각의 개별적인 항목, 즉 하나의 레코드 또는 튜플에 해당하는 모든 데이터를 물리적으로 연속된 공간에 함께 저장한다. 예를 들어, 고객 정보 테이블에서 한 명의 고객에 대한 아이디, 이름, 주소, 전화번호 등의 모든 속성값이 디스크 상에서 나란히 위치하게 된다.

이러한 물리적 배치 특성 때문에 행 기반 저장 방식은 온라인 트랜잭션 처리에 매우 적합하다. 시스템은 특정 고객의 레코드를 한 번의 디스크 읽기 작업으로 효율적으로 가져오거나, 새로운 고객 정보를 추가하거나 기존 정보를 수정하는 작업을 수행할 수 있다. 이는 개별 실체에 대한 완전한 정보를 빠르게 처리해야 하는 업무 환경에서 중요한 장점으로 작용한다.

반면, 테이블 전체를 대상으로 특정 열만을 집계하거나 분석하는 쿼리에는 비효율적일 수 있다. 예를 들어, 전체 고객의 평균 나이만을 계산하려면 각 행의 모든 데이터를 디스크에서 읽어야 하기 때문에 불필요한 입출력 오버헤드가 발생할 수 있다. 이러한 특성은 행 기반과 열 기반의 주요 차이점을 이루며, 각각의 사용 사례를 결정하는 핵심 요인이 된다.

행 기반 데이터베이스의 구현 방식은 주로 온라인 트랜잭션 처리에 최적화되어 있다. 데이터는 테이블에서 하나의 레코드 또는 튜플로 구성되며, 이는 각 속성의 값들이 하나의 행으로 연속적으로 저장되는 구조를 가진다. 이 방식에서는 새로운 레코드가 추가될 때마다 테이블의 끝에 연속적인 공간에 기록되는 것이 일반적이다.

구체적인 저장 방식은 데이터베이스 관리 시스템에 따라 다르지만, 대부분의 관계형 데이터베이스는 행 단위로 데이터를 디스크의 페이지에 저장한다. 즉, 하나의 행에 속한 모든 열의 데이터가 물리적으로 인접해 있어, 특정 사용자나 거래에 관한 모든 정보를 한 번의 입출력 연산으로 효율적으로 읽거나 쓸 수 있다. 이는 개별 레코드의 삽입, 갱신, 삭제 작업이 빈번한 환경에 매우 적합하다.

이러한 구현 구조 덕분에, 특정 키 값을 기준으로 한 레코드의 빠른 검색을 지원하는 인덱스 역시 주로 행 기반으로 구성된다. B-트리 인덱스는 특정 행의 위치를 가리키는 포인터를 저장하며, 이를 통해 전체 행 데이터에 신속하게 접근할 수 있도록 한다. 결과적으로, 행 기반 구현은 소수의 레코드에 대한 전체 컬럼 집합을 자주 조회하는 트랜잭션 중심 워크로드의 핵심이 된다.

행 기반 저장 방식은 온라인 트랜잭션 처리 환경에서 데이터를 추가, 수정, 삭제하는 작업에 매우 효율적이다. 새로운 레코드를 추가할 때는 테이블의 끝에 모든 열의 값을 한 줄로 연속해서 기록하면 되므로 빠르게 처리할 수 있다. 또한 특정 레코드 하나를 수정하거나 삭제할 때도 해당 행의 위치를 찾아 그 주소에서 모든 데이터를 한꺼번에 접근할 수 있어 유리하다. 이 방식은 은행 거래나 항공권 예약과 같이 실시간으로 데이터가 갱신되는 시스템에 적합하다.

반면, 데이터베이스에서 특정 열만을 대상으로 한 집계나 분석 쿼리를 수행할 때는 비효율적일 수 있다. 예를 들어, '전체 고객의 평균 나이'를 계산하려면 모든 행을 디스크에서 읽어와야 하며, 각 행에는 필요 없는 다른 열들의 데이터도 포함되어 있다. 이는 불필요한 입출력을 발생시켜 쿼리 성능을 저하시키고, 특히 대규모 데이터 웨어하우스나 비즈니스 인텔리전스 분석 작업에는 적합하지 않을 수 있다.

따라서 행 기반 방식의 장단점은 사용 목적에 따라 뚜렷이 갈린다. 온라인 트랜잭션 처리와 같은 쓰기 중심의 작업에는 강점을 보이지만, 온라인 분석 처리와 같은 읽기 중심의 분석 작업에는 열 기반 저장 방식에 비해 상대적인 약점을 가진다. 데이터베이스 시스템을 설계할 때는 이러한 특성을 고려하여 업무 요구사항에 맞는 저장 방식을 선택해야 한다.

행 기반 데이터 모델은 온라인 트랜잭션 처리 시스템의 핵심 구조로 널리 사용된다. 이러한 시스템은 은행 거래, 항공기 예약, 전자 상거래 주문 처리와 같이 빠른 데이터 추가, 수정, 삭제가 빈번하게 발생하는 업무에 적합하다. 관계형 데이터베이스의 대표 제품들인 MySQL, PostgreSQL, 오라클 데이터베이스는 기본적으로 행 기반 스토리지를 채택하여, 하나의 레코드에 대한 모든 열 데이터를 물리적으로 인접하게 저장함으로써 단일 트랜잭션 처리 성능을 최적화한다.

또한, 행 기반 접근 방식은 온라인 분석 처리 쿼리 중에서도 특정 튜플의 모든 속성을 조회해야 하는 경우에 유리하다. 예를 들어, 한 고객의 전체 프로필 정보나 한 주문의 상세 내역을 가져올 때, 디스크에서 해당 행을 한 번에 읽어오면 효율적이다. 이는 전화번호부에서 한 사람의 이름, 주소, 전화번호를 한 줄에서 모두 찾아보는 것과 유사한 원리이다.

그러나 데이터 웨어하우스나 빅데이터 분석 환경에서는 주로 특정 열 전체에 대한 집계 연산이 수행되므로, 모든 행을 스캔해야 하는 행 기반 방식보다는 열 기반 데이터베이스가 더 효율적인 경우가 많다. 따라서 행 기반 모델은 실시간 트랜잭션과 개체 중심의 조회가 주를 이루는 기업 자원 관리 시스템, 고객 관계 관리 시스템, 컨텐츠 관리 시스템 등에서 그 강점을 발휘하는 전통적이면서도 여전히 중요한 저장 방식이다.

행 기반과 대비되는 개념으로는 열 기반 저장 방식이 있다. 행 기반은 하나의 레코드 또는 튜플에 속한 모든 속성 값을 연속적으로 저장하는 반면, 열 기반은 모든 레코드의 동일한 속성 값을 모아서 저장한다. 이는 데이터 접근 패턴과 최적화 목적에 따른 근본적인 차이를 만들어낸다.

행 기반 저장 방식은 온라인 트랜잭션 처리 환경에 적합하다. 특정 고객의 정보를 조회하거나 주문 내역을 추가, 수정, 삭제할 때와 같이, 하나의 개체에 대한 모든 데이터를 함께 처리하는 작업이 빈번한 경우에 효율적이다. 반면, 열 기반 방식은 데이터 웨어하우스나 온라인 분석 처리에서 특정 열만을 대상으로 한 집계나 분석 쿼리를 빠르게 실행하는 데 유리하다.

이러한 저장 방식의 선택은 사용되는 데이터베이스 관리 시스템의 종류와도 깊은 연관이 있다. 전통적인 관계형 데이터베이스인 MySQL이나 PostgreSQL은 주로 행 기반 저장을 기본으로 한다. 한편, 분석에 특화된 Apache Cassandra나 컬럼형 데이터베이스인 Google Bigtable의 후계 시스템들은 열 기반 또는 하이브리드 방식을 채택하여 대규모 데이터 분석 성능을 극대화한다.

행 기반 데이터베이스는 온라인 트랜잭션 처리 환경에서 레코드 단위의 빠른 읽기와 쓰기를 위해 설계되었다. 이는 관계형 데이터베이스의 전통적인 저장 방식으로, SQL을 통한 질의가 하나의 튜플 전체를 대상으로 하는 경우에 효율적이다.

이 방식과 대비되는 개념은 열 기반 저장 방식이다. 열 기반은 데이터 웨어하우스나 빅데이터 분석과 같이 특정 열만 집계하거나 스캔하는 작업에 유리한 반면, 행 기반은 은행 거래나 항공권 예약과 같이 트랜잭션의 무결성을 유지하며 전체 레코드를 자주 갱신하는 작업에 더 적합하다.

데이터베이스 관리 시스템의 발전으로 인해 하이브리드 형태의 저장 엔진이나 단일 시스템 내에서 두 방식을 모두 지원하는 경우도 등장하고 있다. 이는 온라인 트랜잭션 처리와 온라인 분석 처리의 요구사항을 동시에 만족시키기 위한 시도로 볼 수 있다.