컬럼 지향 DBMS

Column-oriented DBMS

컬럼 지향 DBMS 또는 컬럼형 DBMS는 데이터 테이블을 행이 아닌 컬럼별로 저장하는 데이터베이스 관리 시스템(DBMS)입니다.(관련성이 없는 열을 읽을 필요가 없어짐으로써) 열의 하위 집합만 쿼리할 때 데이터에 보다 효율적으로 액세스할 수 있고 데이터 압축 옵션을 더 많이 사용할 수 있다는 이점이 있습니다.그러나 일반적으로 새 데이터를 삽입하는 데 효율이 떨어집니다.

열 저장소와 행 저장소의 실제 사용은 관계형 DBMS 세계에서 거의 차이가 없습니다.컬럼 데이터베이스와 행 데이터베이스 모두 SQL과 같은 기존 데이터베이스 쿼리 언어를 사용하여 데이터를 로드하고 쿼리를 수행할 수 있습니다.행 및 컬럼 데이터베이스 모두 시스템의 백본이 되어 공통 추출, 변환, 로드(ETL) 및 도구에 대한 데이터를 제공할 수 있습니다.

묘사

배경

릴레이셔널 데이터베이스 관리 시스템은 열과 행의 2차원 테이블을 나타내는 데이터를 제공한다.예를 들어 데이터베이스에 다음 테이블이 있을 수 있습니다.

행 ID EmpId 성 이름 급여
001 10 스미스 조. 60000
002 12 존스 메리 80000
003 11 존슨 캐시 94000
004 22 존스 밥. 55000

이 간단한 테이블에는 직원 식별자(EmpId), 이름 필드(성 및 이름) 및 급여(월급)가 포함됩니다.이 2차원 형식은 추상화입니다.실제 구현에서는 스토리지 하드웨어에서 데이터를 어떤 형태로든 직렬화해야 합니다.

하드 디스크와 관련된 가장 비용이 많이 드는 작업이 요구됩니다.전체적인 성능을 향상시키기 위해서는 검색 횟수를 최소화하는 방식으로 관련 데이터를 저장해야 합니다.이를 참조 인접성이라고 하며, 기본 개념은 여러 가지 다른 컨텍스트에서 나타납니다.하드 디스크는 고정 크기의 일련의 블록으로 구성되어 있으며, 일반적으로 테이블의 여러 행을 저장할 수 있습니다.행이 이러한 블록 내에 적합하도록 테이블의 데이터를 구성하고 관련 행을 순차적 블록으로 그룹화함으로써 대부분의 경우 읽거나 검색해야 하는 블록 수와 함께 최소화할 수 있습니다.

Pinnecke [1]et al.의 조사는 2017년 현재 기둥/줄 교배 기술을 다루고 있습니다.

행 지향 시스템

테이블을 저장하는 일반적인 방법은 다음과 같이 각 데이터 행을 직렬화하는 것입니다.

001:10, Smith, Joe,60000; 002:12, Jones, Mary,80000; 003:11, Johnson, Cathy, 94000; 004:22, Jones, Bob,55000;

데이터가 테이블에 삽입되면 내부 ID가 할당됩니다.rowid데이터를 참조하기 위해 시스템에서 내부적으로 사용됩니다.이 경우 레코드는 순차적으로rowid사용자 정의와는 무관합니다.empid이 예에서는 DBMS는 짧은 정수를 사용하여 저장합니다.rowids. 실제로는 보통 64비트 또는 128비트의 큰 숫자가 사용됩니다.

행 지향 시스템은 행 전체의 데이터를 효율적으로 반환하거나 가능한 한 적은 작업으로 기록하도록 설계되었습니다.이는 시스템이 특정 객체에 대한 정보, 예를 들어 Rollodex 시스템의 사용자 연락처 정보 또는 온라인 쇼핑 시스템의 제품 정보를 가져오려고 하는 일반적인 사용 사례와 일치합니다.레코드의 데이터를 관련 레코드와 함께 디스크의 단일 블록에 저장함으로써 시스템은 최소한의 디스크 작업으로 레코드를 빠르게 검색할 수 있습니다.

행 지향 시스템은 특정 레코드의 수가 적은 것과 달리 테이블 전체에 대해 설정 전체 작업을 수행하는 데 효율적이지 않습니다.예를 들어 급여가 40,000 ~50,000인 샘플테이블 내의 모든 레코드를 검색하려면 DBMS는 테이블 전체를 스캔하여 일치하는 레코드를 찾아야 합니다.위의 예제 테이블은 단일 디스크 블록에 들어갈 가능성이 높지만, 수백 개의 행이 있는 테이블은 그렇지 않습니다.데이터를 취득하여 조사하려면 여러 개의 디스크 조작이 필요합니다.

이러한 종류의 작업(매우 일반적이며 일반적으로 DBMS를 사용하는 포인트)의 성능을 향상시키기 위해 대부분의 DBMS는 일련의 컬럼에서 값을 모두 저장하는 데이터베이스 인덱스의 사용을 지원합니다.rowid포인터를 원래 테이블로 되돌립니다.급여 열의 지수는 다음과 같습니다.

55000:004;  60000:001; 80000:002; 94000:003;

인덱스는 전체 행이 아닌 단일 데이터만 저장하므로 일반적으로 주 테이블 저장소보다 크기가 훨씬 작습니다.이 작은 데이터 세트를 스캔하면 디스크 작업 수가 줄어듭니다.인덱스를 많이 사용하면 일반적인 작업에 소요되는 시간을 크게 단축할 수 있습니다.그러나 인덱스를 유지 관리하면 특히 데이터베이스에 새 데이터가 기록될 때 시스템에 오버헤드가 추가됩니다.메인 테이블에 레코드를 저장해야 할 뿐만 아니라 첨부된 인덱스도 업데이트해야 합니다.

인덱스가 대규모 데이터셋에서 성능을 크게 향상시키는 주된 이유는 하나 이상의 열에 있는 데이터베이스 인덱스가 일반적으로 값별로 정렬되기 때문에 범위 쿼리 작업(위의 "급여가 40,000에서 50,000 사이인 모든 레코드 찾기" 예와 같이)이 매우 빠르기 때문입니다(시간 복잡성이 감소).

많은 행 지향 데이터베이스가 메모리 내 데이터베이스인 RAM에 완전히 맞도록 설계되어 있습니다.이러한 시스템은 Disk 작업에 의존하지 않으며 전체 데이터 세트에 동일한 시간 동안 액세스할 수 있습니다.따라서 일반적인 집계 목적으로 원본 데이터를 전체 인덱스와 동일한 양의 작업이 필요하므로 인덱스의 필요성이 줄어듭니다.따라서 이러한 시스템은 더 단순하고 작을 수 있지만 메모리에 맞는 데이터베이스만 관리할 수 있습니다.

컬럼 지향 시스템

열 지향 데이터베이스는 열의 모든 값을 함께 직렬화한 후 다음 열의 값을 직렬화하는 방식으로 수행됩니다.이 예제의 표에서는 데이터는 다음과 같이 저장됩니다.

10:001, 12:002, 11:003, 22:004, Smith:001, Jones:002, Johnson:003, Jones:004, Joe:001, Mary:002, Cathy:003, Bob:004, 600001,80000:002,9400:003,554;

이 레이아웃에서 열 중 하나는 행 지향 시스템에서 인덱스의 구조와 더 밀접하게 일치합니다.이로 인해 혼란이 발생하여 열 지향 저장소가 모든 열에 인덱스가 있는 행 저장소로 "정확히" 잘못 인식될 수 있습니다.그러나 데이터의 매핑은 크게 다릅니다.행 지향 시스템에서는 인덱스가 열 값을 행 ID에 매핑하는 반면, 열 지향 시스템에서는 열이 열 ID를 열 [2]값에 매핑합니다.이것은 미묘하게 보일 수 있지만, 위의 두 "Jones" 항목이 두 개의 행 ID를 가진 단일 항목으로 압축된 동일한 저장소에 대한 일반적인 수정에서 차이를 알 수 있습니다.

…;스미스:001;존스:002,004;Johnson:003;…

컬럼 지향 시스템의 운용 효율화 여부는 자동화되는 워크로드에 크게 좌우됩니다.지정된 개체(행 전체)의 모든 데이터를 검색하는 작업은 더 느립니다.행 지향 시스템은 단일 디스크 판독으로 행을 검색할 수 있지만, 여러 열에서 데이터를 수집하기 위한 수많은 디스크 조작이 컬럼 데이터베이스에서 필요합니다.그러나 이러한 전체 행 작업은 일반적으로 거의 없습니다.대부분의 경우 데이터의 제한된 부분 집합만 검색됩니다.예를 들어 Rolodex 어플리케이션에서는 연락처 목록을 작성하기 위해 여러 행에서 이름과 성을 수집하는 것이 단일 주소의 모든 데이터를 읽는 것보다 훨씬 일반적입니다.이는 특히 데이터가 많은 옵션 열로 "희소"되는 경향이 있는 경우 데이터베이스에 데이터를 쓸 때 더욱 그러합니다.이 때문에 칼럼스토어는 이론적으로 많은 [3]단점에도 불구하고 실제 환경에서 우수한 성능을 발휘하고 있습니다.

파티셔닝, 인덱싱, 캐시, 뷰, OLAP 큐브 및 미리 쓰기 로깅이나 다중 버전 동시성 제어와 같은 트랜잭션시스템은 어느 시스템의 물리적 조직에나 큰 영향을 미칩니다.즉, 온라인 트랜잭션 처리(OLTP) 중심의 RDBMS 시스템은 행 지향적인 반면 온라인 분석 처리(OLAP) 중심의 시스템은 행 지향적인 시스템과 열 지향적인 시스템의 균형입니다.

혜택들

접속 시간

행 지향 데이터베이스와 열 지향 데이터베이스 간의 비교는 일반적으로 특정 워크로드에 대한 하드 디스크 액세스의 효율성에 관한 것입니다.이는 컴퓨터의 다른 병목 현상에 비해 시크 시간이 매우 길기 때문입니다.예를 들어, 일반적인 시리얼 ATA(SATA) 하드 드라이브의 평균 시크 시간은 16 ~22 밀리초인 반면, 인텔 Core i7 프로세서의 DRAM 액세스에는 평균 60 나노초가 걸립니다.이는 거의 400,000배의 [5]속도입니다.디스크 액세스는 빅 데이터를 처리하는 데 있어 주요 병목 현상입니다.컬럼 데이터베이스는 유사한 컬럼 데이터를 효율적으로 압축하고 쿼리에 응답하는 데 필요한 데이터만 읽음으로써 디스크에서 읽어야 하는 데이터 양을 줄임으로써 성능을 향상시킵니다.

실제로 컬럼형 데이터베이스는 일반적으로 모든 데이터에 대해 매우 복잡한 쿼리(페타바이트 단위일 수 있음)를 수반하는 OLAP와 유사한 워크로드(예: 데이터 웨어하우스)에 적합합니다.그러나 데이터를 기둥형 데이터베이스에 쓰려면 몇 가지 작업을 수행해야 합니다.트랜잭션(INSERT)은 저장 시 열로 분리하여 압축해야 하므로 OLTP 워크로드에 적합하지 않습니다.행 지향 데이터베이스는 인터랙티브 트랜잭션 부하가 높은 OLTP와 같은 워크로드에 적합합니다.예를 들어, 행 지향 아키텍처에서와 같이 데이터가 단일 위치에 있는 경우(디스크 검색 최소화) 단일 행에서 모든 데이터를 검색하는 것이 더 효율적입니다.그러나 칼럼 지향 시스템은 OLTP와 OLAP 작업을 모두 수행할 수 있는 하이브리드로 개발되었습니다.이러한 열 지향 시스템이 직면한 OLTP 제약 조건 중 일부는 메모리 내 [6]데이터 스토리지를 사용하여 조정됩니다.OLAP 및 OLTP 역할 모두에 적합한 열 지향 시스템은 별도의 [7]시스템을 필요로 하지 않으므로 총 데이터 설치 공간을 효과적으로 줄일 수 있습니다.

압축

열 데이터는 균일한 유형이기 때문에 행 지향 데이터에서는 사용할 수 없는 열 지향 데이터에서는 스토리지 크기를 최적화할 수 있습니다.예를 들어, LZW나 런렝스 부호화 등 널리 사용되는 많은 최신 압축 방식에서는 인접 데이터의 유사성을 이용하여 압축합니다.결측값과 반복값은 임상 데이터에서 일반적으로 2비트 [8]마커로 나타낼 수 있습니다.행 중심의 데이터에도 동일한 기술을 사용할 수 있지만, 일반적인 구현에서는 효과적인 [9][10]결과를 얻을 수 없습니다.

압축을 개선하기 위해 행을 정렬하는 것도 도움이 됩니다.예를 들어 비트맵 인덱스를 사용하여 정렬하면 압축을 [11]크기순으로 개선할 수 있습니다.실행 길이 인코딩과 관련하여 사전 편집 순서의 압축 이점을 최대화하려면 첫 번째 정렬 [12]키로 낮은 카디널리티 열을 사용하는 것이 좋습니다.예를 들어, 성별, 나이, 이름이 있는 표가 주어진다면, 먼저 성별 값(2진수), 나이(2진수 미만), 그 다음 이름을 정렬하는 것이 가장 좋다.

Columnar 압축은 검색 효율성을 희생하면서 디스크 공간을 줄입니다.인접 압축이 클수록 데이터를 읽기 위해 압축을 풀어야 하므로 랜덤 액세스가 더욱 어려워질 수 있습니다.따라서, 컬럼 지향 아키텍처는 압축 [13]데이터에 대한 접근의 필요성을 최소화하기 위한 추가 메커니즘에 의해 때때로 강화됩니다.

역사

DBMS 개발 초기부터 Column Store 또는 전치된 파일이 구현되어 왔습니다.1969년 TAXIR는 생물학에서 정보[14] 검색에 초점을 맞춘 컬럼 지향 데이터베이스 스토리지 시스템의 첫 번째 응용 프로그램이었다.분석할 수 있는 것보다 더 많은 속성을 가진 환자 기록의 임상 데이터는 1975년 이후 시간 지향 데이터베이스 시스템(TODS)[8]에 의해 처리되었다.캐나다 통계청은 1976년에 RAPID[15] 시스템을 구현하여 캐나다 인구주택총조사(Canadian Census of Population and Housing)의 처리 및 검색과 그 밖의 여러 통계 적용에 사용했다.RAPID는 전 세계의 다른 통계 기관과 공유되었고 1980년대에 널리 사용되었다.이것은 1990년대까지 캐나다 통계청에 의해 계속 사용되었다.

또 다른 컬럼 지향 데이터베이스는 SCSS입니다.[16][17][18]

최신 컬럼 지향 데이터베이스 패키지는 다음과 같습니다.

약 2004년 이후 오픈 소스 및 상용 구현이 추가되어 왔습니다.MoneDB는 2004년 [19]9월 30일 오픈 소스 라이선스로 출시되었으며, 현재는 사용되지 않는 C-Store가 [20]그 뒤를 바짝 따랐다.

C-store는 대학 프로젝트였고, 결국 팀원 Michael Stonebraker가 잔류하면서 Vertica를 설립하게 되었고,[21][22] 그는 2005년에 Vertica를 공동 설립했습니다.

MoneDB 관련 X100 프로젝트는 VectorWise로 [23][24]발전했습니다.Druid는 2012년 말에 오픈소싱된 컬럼 지향 데이터스토어이며 현재 많은 [25]조직에서 사용되고 있습니다.

Classic Relational DBMS는 행 지향 테이블과 열 지향 테이블을 혼합하여 열 지향 전략을 사용할 수 있습니다.DBMS의 복잡함에도 불구하고, 이 접근법은 2010년부터 현재까지 유용한 것으로 입증되었습니다.예를 들어 2014년 Citusdata는 Postgre를 위한 컬럼 지향 테이블을 도입했습니다.SQL[26] 및 McObject는 eXtreme 릴리즈에서 컬럼 스토리지 지원을 추가했습니다.2012년 DB[27] Financial Edition은 독립적으로 감사된 STAC-M3 [28]벤치마크의 새로운 성능 표준을 수립하는 데 사용되었습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Marcus Pinnecke; David Broneske; Gabriel Campero Durand; Gunter Saake (2017). Are Databases Fit for Hybrid Workloads on GPUs? A Storage Engine's Perspective (PDF). IEEE 33rd International Conference on Data Engineering (ICDE). doi:10.1109/ICDE.2017.237.
  2. ^ Daniel Abadi; Samuel Madden (31 July 2008). "Debunking Another Myth: Column-Stores vs. Vertical Partitioning". The Database Column. Archived from the original on December 4, 2008.
  3. ^ Stavros Harizopoulos; Daniel Abadi; Peter Boncz. "Column-Oriented Database Systems" (PDF). VLDB 2009 Tutorial. p. 5.
  4. ^ Masiero, Manuel (January 8, 2013). "Western Digital's 4 TB WD4001FAEX Review: Back In Black". Tom's Hardware.
  5. ^ Levinthal, Dr David (2009). "Performance Analysis Guide for Intel® Core™ i7 Processor and Intel® Xeon™ 5500 processors" (PDF). Intel. p. 22. Retrieved 2017-11-10.
  6. ^ "Compacting Transactional Data in Hybrid OLTP&OLAP Databases" (PDF). Retrieved August 1, 2017.
  7. ^ "A Common Database Approach for OLTP and OLAP Using an In-Memory Column Database" (PDF). Retrieved August 1, 2017.
  8. ^ a b Stephen Weyl; James F. Fries; Gio Wiederhold; Frank Germano (1975). "A Modular Self-describing Clinical Database System". Computers and Biomedical Research. 8 (3): 279–293. doi:10.1016/0010-4809(75)90045-2. PMID 1157469.
  9. ^ D. J. Abadi; S. R. Madden; N. Hachem (2008). Column-stores vs. row-stores: how different are they really?. SIGMOD’08. pp. 967–980.
  10. ^ Bruno, N (2009). "Teaching an old elephant new tricks". arXiv:0909.1758 [cs.DB].
  11. ^ Daniel Lemire, Owen Kaser, Kamel Aouiche, "소팅으로 워드 정렬 비트맵 인덱스가 향상됩니다", Data & Knowledge Engineering, Volume 69, Issue 1 (2010), 페이지 3-28.
  12. ^ Daniel Lemire와 Owen Kaser, Information Sciences 181 (12), 2011년
  13. ^ Dominik Ślęzak; Jakub Wróblewski; Victoria Eastwood; Piotr Synak (2008). Brighthouse: an analytic data warehouse for ad hoc queries (PDF). Proceedings of the 34th VLDB Conference. Auckland, New Zealand. Archived from the original (PDF) on 2016-05-07. Retrieved 2009-05-04.
  14. ^ George F. Estabrook; Robert C. Brill (November 1969). "The theory of the TAXIR accessioner". Mathematical Biosciences. 5 (3–4): 327–340. doi:10.1016/0025-5564(69)90050-9.
  15. ^ "A DBMS for large statistical databases". acm.org. Vldb '79. 1979. pp. 319–327.
  16. ^ 1977년 9월까지 이미 시장에 나와 있다
  17. ^ Nie, Norman H. (1980). SCSS: A User's Guide to the SPSS Conversational Statistical System. ISBN 978-0070465336.
  18. ^ "SCSS from SPSS, Inc". ComputerWorld. September 26, 1977. p. 28.
  19. ^ "A short history about us". monetdb.org.
  20. ^ "C-Store". mit.edu. Archived from the original on 2012-03-05. Retrieved 2008-01-22.
  21. ^ "The Vertica Analytic Database: C-Store 7 Years Later" (PDF)" (PDF). VLDB.org. August 28, 2012.
  22. ^ Charles Babcock (February 21, 2008). "Database Pioneer Rethinks The Best Way To Organize Data". InformationWeek. Retrieved 2018-12-08.
  23. ^ Marcin Zukowski; Peter Boncz (May 20, 2012). From x100 to vectorwise: opportunities, challenges and things most researchers do not think about. Proceedings of the 2012 ACM SIGMOD International Conference on Management of Data. ACM. pp. 861–862. doi:10.1145/2213836.2213967. ISBN 978-1-4503-1247-9. S2CID 9187072.
  24. ^ D. Inkster; M. Zukowski; P.A. Boncz (September 20, 2011). "Integration of VectorWise with Ingres". ACM SIGMOD Record. 40 (3): 45. CiteSeerX 10.1.1.297.4985. doi:10.1145/2070736.2070747. S2CID 6372175.
  25. ^ "Druid". druid.io.
  26. ^ "Citusdata". github.com.
  27. ^ Saujani, Sandeep (19 June 2012). "McObject eXtremeDB Financial Edition In-Memory DBMS Breaks Through Capital Markets' Data Management Bottleneck". bobs guide.
  28. ^ STAC Benchmark Council, Leadership (3 November 2012). "McObject eXtremeDB 5.0 Financial Edition with Kove XPD L2 Storage System, Dell PowerEdge R910 Server and Mellanox ConnectX-2 and MIS5025Q QDR InfiniBand Switch". STAC.

외부 링크