맨위로가기

컬럼 지향 DBMS

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

컬럼 지향 DBMS는 데이터를 열 단위로 저장하는 데이터베이스 관리 시스템으로, 행 단위로 저장하는 기존 방식과 차이를 보인다. 열 지향 방식은 동일한 열의 값들을 묶어 저장하여, 대량의 행에 대한 소수의 열 집약 처리 및 전체 행에 대한 소수의 열 일괄 갱신에 효율적이다. 이러한 특성으로 인해 데이터 웨어하우스와 같은 OLAP 환경에 적합하며, 압축 효율이 높고 SIMD 명령어를 활용한 빠른 분석 작업이 가능하다. 반면, 행 삽입 및 임의 접근 성능은 상대적으로 떨어진다. 컬럼 지향 DBMS는 SAP HANA, Vertica, Infobright 등이 있으며, NoSQL 컬럼 지향 데이터 모델과는 다른 개념이다.

더 읽어볼만한 페이지

  • 데이터베이스 유형 - 병렬 데이터베이스
    병렬 데이터베이스는 데이터베이스 시스템 성능 향상을 위해 여러 프로세서나 디스크를 활용하여 작업을 병렬로 처리하는 시스템으로, 쿼리 간 병렬 처리와 질의 내 병렬 처리 방식으로 나뉘며, 대용량 데이터 처리 및 복잡한 쿼리 실행 시간을 단축시켜 효율성을 높인다.
  • 데이터베이스 유형 - 문서 지향 데이터베이스
    문서 지향 데이터베이스는 데이터를 문서 형태로 저장하고 관리하며, XML, JSON 등의 형식으로 캡슐화하고 고유 키로 접근하며, 스키마를 강제하지 않는 NoSQL 데이터베이스의 한 종류이다.
  • 데이터베이스 모델 - 플랫 파일 데이터베이스
    플랫 파일 데이터베이스는 각 줄에 레코드를 기록하고 구분자로 필드를 구분하는 단순한 형태이지만, 데이터 중복, 대용량 처리의 어려움, 보안 취약성 등의 한계로 특정 용도로만 활용된다.
  • 데이터베이스 모델 - 네트워크 모델
    네트워크 모델은 찰스 바크만이 발명하고 CODASYL 컨소시엄에 의해 표준 사양으로 개발된 데이터베이스 모델이며, 바흐만 다이어그램으로 표현되고 IDS, IDMS, IMAGE 등 다양한 시스템에서 구현되었다.
  • 데이터베이스 관리 시스템 - 트랜잭션 처리
    트랜잭션 처리는 데이터베이스 시스템에서 데이터의 일관성과 무결성을 보장하기 위한 기술이며, ACID 속성을 통해 데이터 정확성을 유지하고 롤백, 데드락 처리 등의 기술을 활용한다.
  • 데이터베이스 관리 시스템 - 저장 프로시저
    저장 프로시저는 데이터베이스 관리 시스템에서 SQL 문들을 미리 컴파일하여 저장하고, 모듈화, 보안성, 성능 향상, 유지보수 용이성과 같은 특징을 가지며, 데이터베이스 시스템마다 구현 방식과 지원하는 언어가 다를 수 있는 코드 묶음이다.
컬럼 지향 DBMS
기본 정보
이름데이터 방향
유형데이터 저장 방법
설명데이터가 메모리에 저장되는 방식
열 방향 데이터베이스 관리 시스템
정의데이터 열을 기반으로 데이터를 저장하는 데이터베이스 관리 시스템
특징분석 쿼리에 적합
높은 압축률
선택된 열만 읽어 디스크 I/O 감소
컬럼 지향 DBMS (열 지향 데이터베이스 관리 시스템)
개요데이터를 디스크에 저장할 때 행이 아닌 열 단위로 저장하는 데이터베이스 시스템
장점압축률 향상
I/O 효율성 증가
분석 쿼리 성능 향상
활용 분야데이터 웨어하우징
비즈니스 인텔리전스
빅데이터 분석
관련 기술
파일 형식Apache ORC
Apache Parquet
Apache Arrow
Apache Avro

2. 설명

표 형식 데이터는 본질적으로 2차원적이며 행과 열로 표현된다. 그러나 현대 운영 체제는 디스크와 메모리 모두에서 데이터를 선형 메모리 모델로 논리적으로 표현한다.[7][8][9] 따라서 선형 메모리 모델의 테이블은 2차원 항목을 1차원 공간으로 투영해야 한다. 데이터 방향은 이러한 투영에서 결정되는 사항을 의미하며, 행 중심 및 열 중심 두 가지 주요 선택 사항이 있다.[1][2]

컬럼 지향 방식에서, 테이블의 요소들은 다음과 같이 선형적으로 저장된다.

열 1열 2열 3
항목 11항목 12항목 13
항목 21항목 22항목 23



위의 표는 다음과 같이 선형적으로 저장된다.

항목 11항목 21항목 12항목 22항목 13항목 23



즉, 테이블의 각 열이 서로 인접하게 위치한다. 이러한 방식으로 동일 열의 값들은 공간적으로 가깝게 위치한다(예: 어드레싱 가능한 공간에서 유사한 주소). 일반적인 DBMS 시스템은 한 행을 구성하는 열 데이터를 묶어 저장하는 반면, 컬럼 지향 DBMS는 열의 값을 묶어 파일 시스템의 가까운 위치에 (또는 하나의 논리 구조로) 배치하는 접근 방식을 취한다.

3. 행 지향 방식

표 형식 데이터는 본질적으로 2차원이다. 즉, 데이터는 행과 열로 표현된다. 그러나 현대 운영 체제는 디스크 및 메모리 내에서 데이터를 선형 메모리 모델로 논리적으로 표현한다.[7][8][9] 따라서 선형 메모리 모델의 테이블은 2차원 항목을 1차원 공간으로 투영해야 한다. 데이터 방향은 이러한 투영에서 결정되는 사항을 의미한다. 데이터 방향에는 행 중심 및 열 중심의 두 가지 주요 선택 사항이 있다.[1][2]

행 지향형 방식에서는 테이블의 각 행의 데이터들이 연속적으로 저장된다.

열 1열 2열 3
항목 11항목 12항목 13
항목 21항목 22항목 23


3. 1. 예시

행 지향 데이터베이스에서 테이블의 요소들은 다음과 같이 선형적으로 저장된다.

항목 11항목 12항목 13항목 21항목 22항목 23



즉, 테이블의 각 행이 서로 연속적으로 위치한다. 이러한 방식에서는 동일한 행에 있는 값들이 공간적으로 가깝게 위치한다. 행 지향형 방식의 예시는 다음과 같다.

4. 열 지향 방식

표 형식 데이터는 행과 열로 표현되는 2차원적인 특성을 가진다. 그러나 현대 운영 체제는 디스크 및 메모리 내에서 데이터를 선형 메모리 모델로 표현한다.[7][8][9] 따라서 선형 메모리 모델의 테이블은 2차원 항목을 1차원 공간으로 투영해야 하며, 이때 데이터 방향(행 중심 또는 열 중심)이 결정된다.[1][2]

일반적인 DBMS는 한 행을 구성하는 열 데이터를 묶어 저장하지만, 컬럼 지향 DBMS는 각 열의 값을 묶어 파일 시스템의 가까운 위치에 (또는 하나의 논리 구조로) 배치한다.

4. 1. 예시

컬럼 지향 방식에서 테이블의 요소들은 다음과 같이 선형적으로 저장된다.

항목 11항목 21항목 12항목 22항목 13항목 23



즉, 테이블의 각 열이 서로 인접하게 위치한다. 이러한 방식으로 동일 열의 값들은 공간적으로 가깝게 위치한다(예: 어드레싱 가능한 공간에서 유사한 주소).


  • 빅쿼리의 메모리 및 스토리지 형식
  • 아파치 파케이
  • 아파치 ORC
  • 아파치 애로우
  • 덕DB의 메모리 형식
  • 판다스의 메모리 형식


자세한 예시는 컬럼 지향 DBMS 목록을 참고하면 된다.

5. 장단점 비교

표 형식 데이터는 행과 열로 표현되는 2차원적이지만, 현대 운영 체제는 데이터를 선형 메모리 모델로 표현한다.[7][8][9] 따라서 2차원 데이터를 1차원 공간에 저장하기 위한 두 가지 주요 방식인 행 중심(row-oriented) 방식과 열 중심(column-oriented) 방식이 있다.[1][2]

데이터 방향성은 시스템 아키텍처 결정에 중요한 요소이며, 컴퓨터 성능과 컴퓨터 데이터 저장소에 큰 영향을 미친다.[8] 특히, 하드 디스크 접근 효율성에서 큰 차이를 보이는데, 처리 시간 중 디스크 시크 시간은 CPU 성능 향상에 비해 개선 속도가 느리다.

일반적으로 행 지향 데이터베이스는 적은 수의 행에 대해 많은 열을 처리하는 데 효율적인 반면, 열 지향 데이터베이스는 많은 수의 행에 대해 적은 열을 처리하는 데 효율적이다.

구분행 지향 데이터베이스열 지향 데이터베이스
장점
단점



컬럼 지향 DBMS는 동일한 데이터 형식을 가진 열 데이터를 압축하여 저장 효율성을 높일 수 있다. LZW와 같은 압축 기술을 적용하여 반복되는 값을 효율적으로 압축하며, 특히 동일한 값이 많거나 값이 없는 필드가 많은 경우 압축 효율이 매우 높아진다.

실제 사용 환경을 고려하면, 행 지향 아키텍처는 OLTP와 같이 상호작용이 많은 트랜잭션 처리에 적합하고, 열 지향 아키텍처는 데이터 웨어하우스나 OLAP처럼 복잡한 쿼리를 적게 실행하는 환경에 적합하다.

5. 1. 임의 접근

행 지향형 데이터베이스는 행에 대한 빠른 임의 접근의 이점을 가지며, 컬럼 지향형 데이터베이스는 열에 대한 빠른 임의 접근의 이점을 가진다. 이는 데이터 접근 시 더 적은 페이지 또는 캐시 미스 발생의 결과이다.[8]

행 지향 데이터베이스와 열 지향 데이터베이스를 비교할 때, 주어진 처리를 위한 하드 디스크 접근 효율성에 주목해야 한다. 처리 시간 중 디스크의 시크 시간은 큰 비중을 차지하며, CPU 성능 향상에 비해 시크 시간 개선은 더디다.

실제 사용 환경을 고려하면, 행 지향 방식은 상호작용이 많은 트랜잭션 OLTP에 적합하고, 열 지향 방식은 데이터 웨어하우스와 같은 OLAP 용도, 즉 복잡한 쿼리를 적게 실행하는 환경에 적합하다.

하지만 임의 접근 성능은 서로 반대되는 관계를 가진다. 특정 행의 모든 열을 가져올 때는 행 지향 데이터베이스가 효율적이다. 반면, 컬럼 지향 데이터베이스에서 연속된 값을 압축하면 읽을 때마다 압축 해제 과정이 필요하여 임의 접근이 특히 더 어렵다. 그래서 컬럼 지향 데이터베이스는 압축된 데이터 접근 필요성을 줄이는 기능을 추가하기도 한다.[11]

5. 2. 삽입

행 지향형 데이터베이스는 새로운 행을 빠르게 삽입할 수 있다는 장점이 있다. 반면, 컬럼 지향형 데이터베이스는 새로운 열을 빠르게 삽입할 수 있다.[2]

이러한 차이 때문에 행 지향형 형식이 온라인 트랜잭션 처리(OLTP)에서 더 일반적으로 사용되며, 컬럼 지향형에 비해 더 빠른 트랜잭션을 처리할 수 있다.[2]

행 지향 아키텍처는 인터랙티브한 트랜잭션이 많은 OLTP적인 용도에 적합하며, 열 지향 아키텍처는 소수의 복잡한 쿼리를 실행하는 데이터 웨어하우스와 같은 OLAP적인 용도에 적합하다.

5. 3. 조건부 접근

행 지향 데이터베이스는 필터링 시 빠른 접근의 이점을 가지며, 컬럼 지향 데이터베이스는 프로젝션 시 빠른 접근의 이점을 가진다.[4][3] 데이터베이스 처리 시 하드 디스크 접근 효율성에 주목할 필요가 있는데, 처리 시간 중 디스크의 시크 시간은 큰 비중을 차지하며, CPU의 계산 능력 향상에 비해 시크 시간은 완만한 속도로밖에 개선되지 않는다.

데이터를 행 지향 또는 열 지향으로 배치할 경우의 장단점은 다음과 같다.

  • 열 지향 데이터베이스는 대량의 행에 대한 소수의 열 집약 처리가 효율적이다. 열 수가 적을수록 읽어 들일 데이터 양을 줄일 수 있다.
  • 열 지향 데이터베이스는 전체 행에 대한 소수의 열 일괄 갱신이 효율적이다. 새로운 열 데이터를 생성하고 이전 데이터와 대체함으로써 다른 열에 대한 접근을 피할 수 있다.
  • 행 지향 데이터베이스는 소수의 행에 대한 많은 열의 취득이 효율적이다. 행당 크기가 작은 경우에는 행 전체를 한 번의 디스크 시크로 읽을 수 있다.
  • 행 지향 데이터베이스는 소수의 행에 대한 많은 열의 갱신이 효율적이다. 1행 전체의 쓰기를 한 번의 디스크 시크로 수행할 수 있다.


실제 용도를 고려하면, 행 지향 아키텍처는 인터랙티브한 트랜잭션이 많은 OLTP적인 용도에 적합하며, 열 지향 아키텍처는 소수의 복잡한 쿼리를 실행하는 데이터 웨어하우스와 같은 OLAP적인 용도에 적합하다.

5. 4. 계산 성능

컬럼 지향형 데이터베이스는 빠른 분석 작업의 이점을 누릴 수 있는데, 이는 SIMD 명령어를 활용할 수 있기 때문이다.[5] 행 지향 데이터베이스와 열 지향 데이터베이스를 비교할 때는 주어진 처리를 수행하기 위한 하드 디스크 접근의 효율성에 주목할 필요가 있다. 처리 시간 중 디스크의 시크 시간은 큰 비율을 차지하며, CPU의 계산 능력 향상에 비해 시크 시간은 완만한 속도로밖에 개선되지 않는다.

데이터를 행 지향 또는 열 지향으로 배치할 경우의 장단점은 다음과 같다.

  • 열 지향 데이터베이스는 대량의 행에 대한 소수의 열 집약 처리가 효율적이다. 열 수가 적을수록 읽어 들일 데이터 양을 줄일 수 있다.
  • 열 지향 데이터베이스는 전체 행에 대한 소수의 열 일괄 갱신이 효율적이다. 새로운 열 데이터를 생성하고 이전 데이터와 대체함으로써 다른 열에 대한 접근을 피할 수 있다.
  • 행 지향 데이터베이스는 소수의 행에 대한 많은 열의 취득이 효율적이다. 행당 크기가 작은 경우에는 행 전체를 한 번의 디스크 시크로 읽을 수 있다.
  • 행 지향 데이터베이스는 소수의 행에 대한 많은 열의 갱신이 효율적이다. 1행 전체의 쓰기를 한 번의 디스크 시크로 수행할 수 있다.


실제 용도를 고려하면, 행 지향 아키텍처는 인터랙티브한 트랜잭션이 많은 OLTP적인 용도에 적합하며, 열 지향 아키텍처는 소수의 복잡한 쿼리를 실행하는 데이터 웨어하우스와 같은 OLAP적인 용도에 적합하다.

5. 5. 압축되지 않은 크기

컬럼 지향 방식은 압축되지 않은 크기가 작다는 이점이 있다. 이는 이 방식이 특정 데이터 유형을 전용 인코딩으로 표현할 수 있다는 가능성에서 비롯된다.[4][3]

예를 들어, 부울 열이 있는 128개의 행으로 구성된 테이블은 행 지향적 형식에서는 128바이트가 필요하지만(부울당 1바이트), 컬럼 지향적 형식에서는 128비트(16바이트)가 필요하다(비트맵을 통해). 또 다른 예는 런 렝스 인코딩을 사용하여 열을 인코딩하는 것이다. 컬럼 지향 DBMS는 한 컬럼에 포함된 데이터 형식이 일치하기 때문에, 행 지향 데이터베이스에서는 어려운 스토리지 효율 최적화를 채용할 수 있다. 유사한 값이 가까운 위치에 배치되기 때문에, 반복을 효율적으로 압축할 수 있는 LZW 등의 데이터 압축을 적용할 여지가 있다. 이러한 압축을 행 지향 데이터베이스에 적용해도, 컬럼 지향과 비교하여 효율은 떨어진다. 특히 컬럼 방향으로 동일한 값이 다수 있거나, 희소 행렬처럼 값이 할당되지 않은 필드의 비율이 높은 경우에는 압축 효율이 비약적으로 높아진다.

5. 6. 압축된 크기

컬럼 지향 방식은 압축된 크기가 더 작다는 장점을 가진다. 이는 여러 행보다 단일 컬럼 내에서 동질성이 더 높기 때문이다.[4][3] 컬럼 지향 DBMS는 한 컬럼에 포함된 데이터 형식이 일치하기 때문에, 행 지향 데이터베이스에서는 어려운 스토리지 효율 최적화를 채용할 수 있다. 유사한 값이 가까운 위치에 배치되기 때문에, 반복을 효율적으로 압축할 수 있는 LZW 등의 데이터 압축을 적용할 여지가 있다. 이러한 압축을 행 지향 데이터베이스에 적용해도, 컬럼 지향과 비교하여 효율은 떨어진다. 특히 컬럼 방향으로 동일한 값이 다수 있거나, 희소 행렬처럼 값이 할당되지 않은 필드의 비율이 높은 경우에는 압축 효율이 비약적으로 높아진다.

한편, 임의 접근 성능은 상쇄 관계가 된다. 어떤 1행의 컬럼 전체를 취득하는 경우에는, 행 지향 데이터베이스처럼, 해당 행의 데이터를 한 곳에 모아 배치하는 편이 효율적이다. 컬럼 지향 데이터베이스에서 연속하는 값을 압축하고 있는 경우에는, 읽을 때마다 전개 처리가 필요하기 때문에, 임의 접근은 특히 어려워진다. 따라서 컬럼 지향 데이터베이스에서는 압축된 데이터에 접근할 필요성을 줄이는 기구가 추가되어 있는 경우도 있다.[11]

6. 변환 및 교환

두 방향 모두 동일한 데이터를 나타내기 때문에, 연산 비용을 들여 행 지향 데이터 세트를 열 지향 데이터 세트로, 또는 그 반대로 변환하는 것이 가능하다.[1] 특히, 고급 쿼리 엔진은 각 방향의 장점을 활용하여 실행 과정의 일부로 한 방향에서 다른 방향으로 변환하는 경우가 많다.[1] 예를 들어, 아파치 스파크 쿼리는 다음과 같은 과정을 거친다.[1]


  • 아파치 파케이(열 지향)에서 데이터를 읽는다.
  • 스파크 내부 메모리 형식(행 지향)으로 로드한다.
  • 특정 계산을 위해 아파치 애로우(열 지향)로 변환한다.
  • 스트리밍을 위해 아파치 아브로(행 지향)로 기록한다.

7. 구현

과거에는 Sybase IQ(현 SAP IQ)만이 컬럼 지향 데이터베이스 관리 시스템으로 널리 사용되었다. 그러나 시간이 지나면서 여러 오픈 소스 및 상용 구현이 등장했다. 2010년에는 SAP에서 컬럼 지향 인 메모리 데이터베이스인 "SAP HANA"를 출시하면서, 오라클 데이터베이스나 마이크로소프트 SQL 서버에서도 컬럼 지향 인 메모리 데이터베이스에 대응하는 유료 옵션을 선택할 수 있게 되었다.[12][13][14]

컬럼 지향 데이터베이스 관리 시스템은 다음과 같이 상용, 상용 오픈 소스, 오픈 소스 소프트웨어로 분류할 수 있다.

분류소프트웨어
상용 소프트웨어
상용 오픈 소스 소프트웨어
오픈 소스 소프트웨어


7. 1. 상용 소프트웨어


  • SAP HANA[12][13][14]
  • SAP IQ[12][13][14]
  • Vertica
  • Valentina Database
  • [http://www.vectornova.com Vectornova/Vectorstar] High-speed Data Engine
  • kdb+
  • [http://www.sensage.com Sensage] Scalable Log Server (구 Addamark)
  • 1010data의 Tenbase database
  • [http://gov.thomsonhealthcare.com/Products/view/?id=76 DataProbe]
  • [http://www.exasol.com EXASolution]
  • [https://web.archive.org/web/20101122114232/http://www.skytide.com/ Skytide XOLAP Server]
  • [http://www.spacetimeresearch.com SuperSTAR from Space-Time Research]
  • ParAccel Analytic Database
  • Dr.Sum EA

7. 2. 상용 오픈 소스 소프트웨어


  • Infobright (구 Brighthouse) data engine (MySQL과 연결됨)[12][13][14]
  • RC21 상용 오픈 소스 소프트웨어 프로젝트[12][13][14]
  • Xplain Semantic Database (transposed files라고 함). "The latest release was version 5.8 (1999)"

7. 3. 오픈 소스 소프트웨어


  • C-Store 2006년 10월부터 신규 릴리스 없음[12][13][14]
  • [https://codeforge.lbl.gov/projects/fastbit/ FastBit] 오픈 소스
  • [http://www.infobright.org Infobright] Community Edition, 정기적으로 업데이트됨
  • [http://www.luciddb.org LucidDB] 오픈 소스
  • [https://mariadb.com/kb/ja/mariadb-columnstore/ MariaDB ColumnStore] InfiniDB에서 포크됨
  • MonetDB 학술용 오픈 소스 프로젝트
  • Metakit 오픈 소스
  • S 언어와 GNU R은 통계 분석을 위해 컬럼 지향 데이터 구조를 활용하고 있다.

8. NoSQL 컬럼 지향 데이터 모델과의 차이점

NoSQL형 DBMS 중에는 "컬럼 지향형"이라고 불리는 것이 있다. 하지만 여기서 말하는 컬럼 지향(열 지향)은 DBMS 이용자에게 보이는 데이터 모델을 나타내며, DBMS 내부의 데이터 저장 방식을 나타내는 것은 아니다. 이들은 본 항목에서 다루는 열 지향 DBMS와 장점이 전혀 다르므로 주의해야 한다.

NoSQL의 컬럼 지향 데이터 모델은 비정형의 대규모 데이터를 저장하는 것을 주된 목적으로 하며, 행마다 임의의 이름의 컬럼(열)을 무수히(때로는 1행에 수백만 컬럼) 저장할 수 있다. 각 컬럼은 행마다 컬럼명의 사전순으로 정렬되며, 한 번의 쿼리로 지정된 1행에 속하는 모든 컬럼을 가져오거나, 지정된 1행에 속하는 지정된 범위의 컬럼만 가져올 수 있다. 소수의 행에 대한 많은 열의 획득에 적합하며, 대량의 행에 대한 소수의 열의 집약 처리에는 적합하지 않다. 이러한 DBMS에는 Apache HBase, Apache Cassandra 등이 있다.

한편, NoSQL은 아니지만, 대규모 데이터를 대상으로 SQL 형식의 분산 쿼리를 실현하는 소프트웨어에서는 열 지향 DBMS와 동일한 데이터 저장 방식을 채택하고, 동일한 장점을 갖는다.[15] 이러한 소프트웨어는 분산 SQL 쿼리 엔진이라고 불리며, Google Dremel/BigQuery, Amazon Redshift, Apache Hadoop에서 동작하는 Cloudera Impala 등이 있다.

참조

[1] 서적 Proceedings of the 2008 ACM SIGMOD international conference on Management of data 2008
[2] 간행물 Compacting Transactional Data in Hybrid OLTP&OLAP Databases 2012
[3] 웹사이트 Apache ORC https://orc.apache.o[...] 2024-05-21
[4] 웹사이트 Apache Parquet https://parquet.apac[...] 2024-05-21
[5] 웹사이트 Apache Arrow https://arrow.apache[...] 2024-05-21
[6] 웹사이트 Apache Avro https://avro.apache.[...] 2024-05-21
[7] 간행물 In lieu of swap: Analyzing compressed RAM in Mac OS X and Linux 2014
[8] 서적 Principles of Computer System Design Morgan Kaufmann 2009
[9] 웹사이트 Chapter 4 Process Address Space (Linux kernel documentation) https://www.kernel.o[...] 2024-05-21
[10] 문서 C-Store: A column-oriented DBMS http://db.lcs.mit.ed[...] Proceedings of the 31st VLDB Conference, Trondheim, Norway 2005
[11] 문서 Brighthouse: an analytic data warehouse for ad-hoc queries http://www.vldb.org/[...] Proceedings of the 34th VLDB Conference, Auckland, New Zealand 2008
[12] 웹사이트 SAPが語るインメモリ--HANAとOracleの違いとは https://japan.zdnet.[...] 2015-06-15
[13] 웹사이트 【Oracle Database 12c 】オラクルのインメモリを3つのポイントから理解する https://www.oracle.c[...] 2019-10-10
[14] 웹사이트 インメモリデータベース、カラム型データベースは使い物になるのか? インメモリとカラム型データベースの可能性を調べる(その1) https://www.publicke[...] 2019-10-10
[15] 문서 Dremel: Interactive Analysis of Web-Scale Datasets http://research.goog[...] Proceedings of the 36th Int'l Conf on Very Large Data Bases 2010



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com