Data Storage Structures - 편집 역사

Pinkgo: /* Storage Organization in Main-Memory Databases */

2025-05-26T14:13:51Z

Storage Organization in Main-Memory Databases

← 이전 판		2025년 5월 26일 (월) 14:13 판
172번째 줄:		172번째 줄:
	===Columnar File Representation===		===Columnar File Representation===
	[[파일:Columnar data representation in the ORC file format.png\|섬네일\|295x295픽셀\|Figure 15. Columnar data representation in the ORC file format]]ORC와 Parquet는 빅데이터 처리에서 널리 사용되는 column-oriented storage 방식을 기반으로 하는 파일 형식이다. Figure 15는 ORC 파일 형식의 세부사항을 보여준다. 각 stripe는 인덱스 데이터(index data)와 행 데이터(row data)로 구성된다. 인덱스 영역은 각 속성마다 10,000개 값 단위로 압축 시작 위치를 저장하며, 이를 통해 원하는 튜플이나 튜플 시퀀스에 빠르게 접근할 수 있다.		[[파일:Columnar data representation in the ORC file format.png\|섬네일\|295x295픽셀\|Figure 15. Columnar data representation in the ORC file format]]ORC와 Parquet는 빅데이터 처리에서 널리 사용되는 column-oriented storage 방식을 기반으로 하는 파일 형식이다. Figure 15는 ORC 파일 형식의 세부사항을 보여준다. 각 stripe는 인덱스 데이터(index data)와 행 데이터(row data)로 구성된다. 인덱스 영역은 각 속성마다 10,000개 값 단위로 압축 시작 위치를 저장하며, 이를 통해 원하는 튜플이나 튜플 시퀀스에 빠르게 접근할 수 있다.
			[[파일:In-memory columnar data representation.png\|섬네일\|318x318픽셀\|Figure 16. In-memory columnar data representation]]

	==Storage Organization in Main-Memory Databases==		==Storage Organization in Main-Memory Databases==
			오늘날에는 메인 메모리의 용량이 충분히 크고 가격도 저렴해져서, 데이터베이스 전체를 메모리 내에 저장할 수 있다. 이는 사실상 데이터베이스 전체를 버퍼에 적재하여 데이터를 읽기 위한 디스크 I/O 작업을 피할 수 있다.

			이때 데이터베이스 전체가 메모리에 들어가는 경우, 저장 구조와 데이터베이스 자료구조를 메모리 내에 존재하는 데이터의 특성을 활용해 최적화하여 성능을 크게 향상시킬 수 있다. 메인 메모리 데이터베이스(main-memory database)란 모든 데이터가 메모리에 존재하는 데이터베이스를 의미한다. 이러한 메인 메모리 데이터베이스 시스템은 이러한 특성을 활용하여 성능을 최적화하도록 설계되어, 버퍼 매니저(buffer manager)를 필요로 하지 않는다.

			만약 column-oriented storage 방식이 메인 메모리 데이터베이스 시스템에서 사용된다면, 하나의 열에 있는 모든 값들을 연속된 메모리 위치에 저장할 수 있다. 이는 대규모 데이터에 대해 집계/통계/분석을 할 때 매우 큰 성능 향상을 보여줄 수 있다. 또한 압축(conpression)을 통해 메모리 사용량을 감소시킬 수 있으며, 특히 column-oriented storage 방식은 유사한 데이터가 인접해 있어 그 효율이 높다.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Columnar File Representation */

2025-05-26T14:06:10Z

Columnar File Representation

← 이전 판		2025년 5월 26일 (월) 14:06 판
172번째 줄:		172번째 줄:
	===Columnar File Representation===		===Columnar File Representation===
	[[파일:Columnar data representation in the ORC file format.png\|섬네일\|295x295픽셀\|Figure 15. Columnar data representation in the ORC file format]]ORC와 Parquet는 빅데이터 처리에서 널리 사용되는 column-oriented storage 방식을 기반으로 하는 파일 형식이다. Figure 15는 ORC 파일 형식의 세부사항을 보여준다. 각 stripe는 인덱스 데이터(index data)와 행 데이터(row data)로 구성된다. 인덱스 영역은 각 속성마다 10,000개 값 단위로 압축 시작 위치를 저장하며, 이를 통해 원하는 튜플이나 튜플 시퀀스에 빠르게 접근할 수 있다.		[[파일:Columnar data representation in the ORC file format.png\|섬네일\|295x295픽셀\|Figure 15. Columnar data representation in the ORC file format]]ORC와 Parquet는 빅데이터 처리에서 널리 사용되는 column-oriented storage 방식을 기반으로 하는 파일 형식이다. Figure 15는 ORC 파일 형식의 세부사항을 보여준다. 각 stripe는 인덱스 데이터(index data)와 행 데이터(row data)로 구성된다. 인덱스 영역은 각 속성마다 10,000개 값 단위로 압축 시작 위치를 저장하며, 이를 통해 원하는 튜플이나 튜플 시퀀스에 빠르게 접근할 수 있다.

			==Storage Organization in Main-Memory Databases==

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Column-Oriented Storage */

2025-05-26T14:04:49Z

Column-Oriented Storage

← 이전 판		2025년 5월 26일 (월) 14:04 판
166번째 줄:		166번째 줄:
	아래는 해당 방식의 단점이다:		아래는 해당 방식의 단점이다:
	# 튜플 재구성 비용: 각 열로부터 튜플을 재조립하는 것은 비용이 크다.		# 튜플 재구성 비용: 각 열로부터 튜플을 재조립하는 것은 비용이 크다.
	# ~~[[파일:Columnar data representation in the ORC file format.png\|섬네일\|295x295픽셀\|Figure 15. Columnar data representation in the ORC file format]]~~튜플 삭제 및 갱신 비용: 튜플을 삭제/갱신/삽입할 때에는 튜플이 여러 열에 분산되어 있어 비효율적이다.		# 튜플 삭제 및 갱신 비용: 튜플을 삭제/갱신/삽입할 때에는 튜플이 여러 열에 분산되어 있어 비효율적이다.
	# 압축 해제 비용: 데이터를 사용할 때 압축을 풀어야 하므로 오버헤드가 발생한다.		# 압축 해제 비용: 데이터를 사용할 때 압축을 풀어야 하므로 오버헤드가 발생한다.
	이러한 장단점을 고려할 때, column-oriented storage 방식은 대규모 데이터에 대해 집계/통계/분석을 할 때 유리하다. 반면, row-oriented storage 방식은 삽입/삭제/갱신 등의 트랜잭션 작업을 할 때 유리하다. 따라서, 일부 DBMS는 두 방식을 모두 사용하는 hybrid row/column stores 방식을 사용하여 두 장점을 모두 취한다.		이러한 장단점을 고려할 때, column-oriented storage 방식은 대규모 데이터에 대해 집계/통계/분석을 할 때 유리하다. 반면, row-oriented storage 방식은 삽입/삭제/갱신 등의 트랜잭션 작업을 할 때 유리하다. 따라서, 일부 DBMS는 두 방식을 모두 사용하는 hybrid row/column stores 방식을 사용하여 두 장점을 모두 취한다.

	===Columnar File Representation===		===Columnar File Representation===
	ORC와 Parquet는 빅데이터 처리에서 널리 사용되는 column-oriented storage 방식을 기반으로 하는 파일 형식이다. Figure 15는 ORC 파일 형식의 세부사항을 보여준다. 각 stripe는 인덱스 데이터(index data)와 행 데이터(row data)로 구성된다. 인덱스 영역은 각 속성마다 10,000개 값 단위로 압축 시작 위치를 저장하며, 이를 통해 원하는 튜플이나 튜플 시퀀스에 빠르게 접근할 수 있다.		[[파일:Columnar data representation in the ORC file format.png\|섬네일\|295x295픽셀\|Figure 15. Columnar data representation in the ORC file format]]ORC와 Parquet는 빅데이터 처리에서 널리 사용되는 column-oriented storage 방식을 기반으로 하는 파일 형식이다. Figure 15는 ORC 파일 형식의 세부사항을 보여준다. 각 stripe는 인덱스 데이터(index data)와 행 데이터(row data)로 구성된다. 인덱스 영역은 각 속성마다 10,000개 값 단위로 압축 시작 위치를 저장하며, 이를 통해 원하는 튜플이나 튜플 시퀀스에 빠르게 접근할 수 있다.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Column-Oriented Storage */

2025-05-26T14:04:27Z

Column-Oriented Storage

@@ 158번째 줄: / 158번째 줄: @@
 ==Column-Oriented Storage==
 ==각주==
 [[분류:데이터베이스 시스템]]

2025년 5월 26일 (월) 12:58에 Pinkgo님의 편집

2025-05-26T12:58:04Z

← 이전 판		2025년 5월 26일 (월) 12:58 판
156번째 줄:		156번째 줄:
	===[[Buffer Manager]]===		===[[Buffer Manager]]===
	자세한 내용은 [[Buffer Manager]] 문서를 참조해 주십시오.		자세한 내용은 [[Buffer Manager]] 문서를 참조해 주십시오.

			==Column-Oriented Storage==

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Buffer Manager */

2025-05-21T17:10:22Z

Buffer Manager

← 이전 판		2025년 5월 21일 (수) 17:10 판
154번째 줄:		154번째 줄:
	오늘날의 대부분의 데이터베이스에서 데이터는 주로 디스크에 저장되어 있으며, 이를 읽거나 갱신하기 위해 메모리로 가져와야 한다. 또한 갱신된 데이터 블록은 이후 다시 디스크에 기록되어야 한다. 하지만 디스크에서의 데이터 접근은 메모리 내 접근보다 훨씬 느리기 때문에, 데이터베이스 시스템은 디스크와 메모리 간의 블록 전송 수를 최소화하고자 한다. 디스크 접근 횟수를 줄이는 한 가지 방법은 가능한 많은 블록을 메인 메모리에 유지하는 것이다. 이는 어떤 블록에 접근할 때 그 블록이 이미 메모리에 있을 확률을 높이는 것이고, 이 경우에는 디스크에 대한 접근이 필요 없기 때문이다. 그러나 모든 블록을 메모리에 유지하는 것은 불가능하므로 메모리에 할당된 블록 저장 공간의 관리가 필요하다. 이러한 상황에서 버퍼(buffer) 개념이 등장한다. 데이터베이스 시스템에서 버퍼(buffer)는 디스크 블록의 복사본을 저장하기 위해 메인 메모리에서 사용 가능한 부분을 의미한다. 이때 버퍼에 저장된 디스크 블록의 복사본에 어떤 갱신이나 삭제 작업이 가해진다면, 실제로 디스크에 저장된 블록은 업데이트되지 않고, out-of-date 상태가 될 수 있다.		오늘날의 대부분의 데이터베이스에서 데이터는 주로 디스크에 저장되어 있으며, 이를 읽거나 갱신하기 위해 메모리로 가져와야 한다. 또한 갱신된 데이터 블록은 이후 다시 디스크에 기록되어야 한다. 하지만 디스크에서의 데이터 접근은 메모리 내 접근보다 훨씬 느리기 때문에, 데이터베이스 시스템은 디스크와 메모리 간의 블록 전송 수를 최소화하고자 한다. 디스크 접근 횟수를 줄이는 한 가지 방법은 가능한 많은 블록을 메인 메모리에 유지하는 것이다. 이는 어떤 블록에 접근할 때 그 블록이 이미 메모리에 있을 확률을 높이는 것이고, 이 경우에는 디스크에 대한 접근이 필요 없기 때문이다. 그러나 모든 블록을 메모리에 유지하는 것은 불가능하므로 메모리에 할당된 블록 저장 공간의 관리가 필요하다. 이러한 상황에서 버퍼(buffer) 개념이 등장한다. 데이터베이스 시스템에서 버퍼(buffer)는 디스크 블록의 복사본을 저장하기 위해 메인 메모리에서 사용 가능한 부분을 의미한다. 이때 버퍼에 저장된 디스크 블록의 복사본에 어떤 갱신이나 삭제 작업이 가해진다면, 실제로 디스크에 저장된 블록은 업데이트되지 않고, out-of-date 상태가 될 수 있다.

	===Buffer Manager===		===[[Buffer Manager]]===
	자세한 내용은 [[Buffer Manager]] 문서를 참조해 주십시오.		자세한 내용은 [[Buffer Manager]] 문서를 참조해 주십시오.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Database Buffer */

2025-05-21T17:10:04Z

Database Buffer

← 이전 판		2025년 5월 21일 (수) 17:10 판
152번째 줄:		152번째 줄:

	==Database Buffer==		==Database Buffer==
			오늘날의 대부분의 데이터베이스에서 데이터는 주로 디스크에 저장되어 있으며, 이를 읽거나 갱신하기 위해 메모리로 가져와야 한다. 또한 갱신된 데이터 블록은 이후 다시 디스크에 기록되어야 한다. 하지만 디스크에서의 데이터 접근은 메모리 내 접근보다 훨씬 느리기 때문에, 데이터베이스 시스템은 디스크와 메모리 간의 블록 전송 수를 최소화하고자 한다. 디스크 접근 횟수를 줄이는 한 가지 방법은 가능한 많은 블록을 메인 메모리에 유지하는 것이다. 이는 어떤 블록에 접근할 때 그 블록이 이미 메모리에 있을 확률을 높이는 것이고, 이 경우에는 디스크에 대한 접근이 필요 없기 때문이다. 그러나 모든 블록을 메모리에 유지하는 것은 불가능하므로 메모리에 할당된 블록 저장 공간의 관리가 필요하다. 이러한 상황에서 버퍼(buffer) 개념이 등장한다. 데이터베이스 시스템에서 버퍼(buffer)는 디스크 블록의 복사본을 저장하기 위해 메인 메모리에서 사용 가능한 부분을 의미한다. 이때 버퍼에 저장된 디스크 블록의 복사본에 어떤 갱신이나 삭제 작업이 가해진다면, 실제로 디스크에 저장된 블록은 업데이트되지 않고, out-of-date 상태가 될 수 있다.

			===Buffer Manager===
			자세한 내용은 [[Buffer Manager]] 문서를 참조해 주십시오.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Data-Dictionary Storage */

2025-05-21T17:00:53Z

Data-Dictionary Storage

← 이전 판		2025년 5월 21일 (수) 17:00 판
149번째 줄:		149번째 줄:
	해당 메타데이터 표현 방식에서, relation_metadata 릴레이션의 index_attributes 속성이 하나 이상의 속성들로 구성된 목록을 포함한다고 가정하자. 이는 "dept_name, building"과 같은 문자열로 표현될 수 있다. 이러한 이유로 index_metadata 릴레이션은 [[Normal Forms#First Normal Form\|제1정규형(1NF)]]을 만족하지 않는다. 물론 이를 정규화할 수도 있지만, 위와 같은 표현 방식이 접근 효율성 측면에서 더 나을 수 있다. 사실 빠른 접근을 위해 데이터 사전은 종종 정규화되지 않은 형식으로 저장된다.		해당 메타데이터 표현 방식에서, relation_metadata 릴레이션의 index_attributes 속성이 하나 이상의 속성들로 구성된 목록을 포함한다고 가정하자. 이는 "dept_name, building"과 같은 문자열로 표현될 수 있다. 이러한 이유로 index_metadata 릴레이션은 [[Normal Forms#First Normal Form\|제1정규형(1NF)]]을 만족하지 않는다. 물론 이를 정규화할 수도 있지만, 위와 같은 표현 방식이 접근 효율성 측면에서 더 나을 수 있다. 사실 빠른 접근을 위해 데이터 사전은 종종 정규화되지 않은 형식으로 저장된다.

	데이터베이스 시스템이 릴레이션으로부터 레코드를 검색하기 위해서는 먼저 relation_metadata 릴레이션을 참조하여 그 릴레이션의 위치와 저장 조직 방식을 찾고, 그 정보를 이용하여 실제 레코드를 가져와야 한다. 하지만 relation_metadata 릴레이션 자체의 저장 방식과 위치는 다른 곳에 기록되어 있어야 한다.<ref>예를 들어 데이터베이스 코드 자체 안에 있거나, 데이터베이스 내의 고정 위치(fixed location)에 있는 방식이다.</ref> 왜냐하면, relation_metadata의 내용을 찾기 위해서는 그 위치 정보를 먼저 알아야 하기 때문이다.		데이터베이스 시스템이 릴레이션으로부터 레코드를 검색하기 위해서는 먼저 relation_metadata 릴레이션을 참조하여 그 릴레이션의 위치와 저장 조직 방식을 찾고, 그 정보를 이용하여 실제 레코드를 가져와야 한다. 하지만 relation_metadata 릴레이션 자체의 저장 방식과 위치는 다른 곳에 기록되어 있어야 한다.<ref>예를 들어 데이터베이스 코드 자체 안에 있거나, 데이터베이스 내의 고정 위치(fixed location)에 있는 방식이다.</ref> 왜냐하면, relation_metadata의 내용을 찾기 위해서는 그 위치 정보를 먼저 알아야 하기 때문이다.

			==Database Buffer==

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Data-Dictionary Storage */

2025-05-21T16:57:26Z

Data-Dictionary Storage

@@ 125번째 줄: / 125번째 줄: @@
 ==Data-Dictionary Storage==
 ==각주==
 [[분류:데이터베이스 시스템]]

Pinkgo: /* Partitioning */

2025-05-21T16:09:17Z

Partitioning

← 이전 판		2025년 5월 21일 (수) 16:09 판
124번째 줄:		124번째 줄:
	즉, transaction_2019 릴레이션에만 접근하며, 다른 릴레이션들은 무시한다. 하지만 연도에 대한 조건이 없는 쿼리는 모든 릴레이션을 읽는다. 레코드를 위한 여유 공간을 찾는 작업과 같은 일부 연산의 비용은 릴레이션의 크기가 커질수록 증가하는데, 파티셔닝은 릴레이션 크기를 줄이기 때문에 이러한 오버헤드를 줄이는 데 도움이 된다. 또한 파티셔닝은 릴레이션의 서로 다른 부분을 서로 다른 저장 장치에 저장하는 데도 사용될 수 있다. 예를 들어, 2019년에는 transaction_2018와 같이 자주 접근되지 않는 데이터는 하드 디스크에, transaction_2019처럼 빠른 접근이 필요한 데이터는 SSD에 저장할 수 있다.		즉, transaction_2019 릴레이션에만 접근하며, 다른 릴레이션들은 무시한다. 하지만 연도에 대한 조건이 없는 쿼리는 모든 릴레이션을 읽는다. 레코드를 위한 여유 공간을 찾는 작업과 같은 일부 연산의 비용은 릴레이션의 크기가 커질수록 증가하는데, 파티셔닝은 릴레이션 크기를 줄이기 때문에 이러한 오버헤드를 줄이는 데 도움이 된다. 또한 파티셔닝은 릴레이션의 서로 다른 부분을 서로 다른 저장 장치에 저장하는 데도 사용될 수 있다. 예를 들어, 2019년에는 transaction_2018와 같이 자주 접근되지 않는 데이터는 하드 디스크에, transaction_2019처럼 빠른 접근이 필요한 데이터는 SSD에 저장할 수 있다.

			==Data-Dictionary Storage==

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]