개발자 뚱별 블로그

인덱스 순차 파일 구조의 가장 큰 단점은 파일이 커질수록 인덱스를 찾아내는 성능과 데이터를 연속적으로 스캔하는 성능이 감소한다는 점이다. 이러한 성능 감소는 파일을 재구성하면 제거할 수 있지만 빈번한 재구성은 바람직하지 않다. 데이터의 삽입과 삭제가 이뤄져도 성능을 유지하는 몇몇 인덱스 구조 중에서 B+ Tree 인덱스(B+ Tree index) 구조를 가장 널리 사용하고 있다. B+ Tree 인덱스(B+ Tree index)는 트리의 루트 ⇒ 단말노드(리프노드) 모든 경로의 길이가 동일한 균형 트리(balanced tree)이다. 루트 노드를 제외한 비 단말 노드는 [n/2] ~ n개의 자식을 갖고 있고 이때 n은 특정한 트리에 대해 고정된 값이다. 루트는 2 ~ n개의 자식을 갖고 있다. B+ Tre..

여러 개의 순서 인덱스 방식을 살펴볼 것이다. 각각의 기술은 DB 응용 프로그램에 맞게 사용하면 된다. 각각의 방식들은 다음과 같은요소에 기초해서 평가된다. 접근 유형(Access Type) : 효율적으로 지원되는 접근 유형. 접근 유형은 특정 속성의 값을 가진 레코드나 특정 범위에 들어가는 속성의 값을 가진 레코드를 찾는 것을 포함한다. 접근 시간(Access Time) : 특정 데이터 항목이나 항목의 집합을 찾는데 걸리는 시간 삽입 시간(Insertion Time) : 새로운 데이터 항목을 삽입하는데 걸리는 시간. 여기에는 새로운 데이터 항목을 삽입하기 위한 정확한 위치를 찾는데 걸리는 시간과 인덱스 구조를 갱신하는데 걸리는 시간이 포함된다. 삭제 시간(Deletion Time) : 데이터 항목을 삭..

대부분의 쿼리(query)는 파일 내의 레코드 중에서 극히 일부분만 참조한다. ex. 물리학과에 속한 모든 교수를 찾아라 ⇒ instructor 의 레코드들만 참조한다. ex. ID가 2201인 학생이 취득한 총 학점을 계산해라 ⇒ student의 레코드들만 참조한다. 물리학과인지 알아내기 위해서 instructor 릴레이션의 모든 레코드들 살펴보는 건 비효율적이다. 마찬가지로 ID = 2201인지 알아내기 위해서 student 릴레이션의 모든 레코드를 살펴보는 것 역시 비효율적이다. 이상적인 방법은 시스템이 원하는 값을 가진 record를 직접 찾는 것이다. 이를 구현하기 위해서 파일과 관련된 부가적인 구조를 설계한다. 1. 기본 개념 ex) 교재의 인덱스 교재에 특정 내용을 알고싶다면... 1) 교재..

오늘날의 main memory는 크기가 충분히 크고 가격도 저렴해서 많은 곳의 전체 DB가 메모리에 들어갈 수 있다. 이렇게 큰 main memory는 DB 버퍼에 많은 양의 메모리를 할당해서 사용할 수 있다. 그러면, 전체 DB를 버퍼에 적재할 수 있게 되면서 데이터를 읽기 위한 디스크 I/O 연산을 피할 수 있다. (다만, 블록을 갱신했다면 그 블록을 디스크에 작성(write)하는 작업은 필요하다) 따라서, 이와 같이 main memory가 큰 환경은 DB 일부만 버퍼에 저장되어 있는 환경보다 훨씬 더 좋은 성능을 제공할 수 있다. 메인 메모리 DB는 모든 데이터가 메모리에 존재하는 DB다. 메인 메모리 DB 시스템은 일반적으로 이 사실을 활용하여 성능을 최적화하도록 설계되었다. 특히, 버퍼 관리자를..

전통적으로 DB는 하나의 record 안에 모든 속성에 대한 값을 저장한 튜플을 저장하고 그 튜플은 지금까지 봐왔던 file에 저장된다. 이러한 저장 방식을 row-oriented storage라고 한다. 반면, Column-Oriented Storage에서는 relation의 각 속성(attribute)이 속성의 값과 함께 별도로 저장된다. 이때, 연속된 튜플의 해당 속성 값들은 파일 내에서 연속된 위치에 저장된다. 그림 : instructor relation이 column-oriented storage 방식으로 어떻게 저장되는지 보여준다. Column-Oriented Storage의 가장 간단한 형태에서 각각의 속성(attribute)은 별도의 파일에 저장된다. 게다가, 각각의 파일은 크기를 줄이기 ..

Main Memory의 크기가 시간이 지나면서 커지면서 중간 사이즈(medium-sized) DB들이 메모리에 들어갈 수 있게 됐다. 하지만, 서버는 memory에 많은 것을 요구(demand)하기 때문에 DB에게 줄 수 있는 메모리의 공간은 DB의 크기보다 훨씬 작을 수 있다. 그래서, DB의 데이터들은 주로 Disk에 저장되고 데이터를 읽거나 수정할 때 메모리로 가져온다. 물론, 수정된 데이터 블록은 다시 디스크에 반영이되야 한다. 디스크에 접근하는 건 in-memory에 있는 데이터에 접근하는 속도보다 느리기 때문에 DB 시스템의 주요 목적은 디스크와 메모리 사이의 블록을 전송하는 횟수를 최소화하는데 있다. 이를 위한 방법 중 하나로 최대한 많은 블록을 main memory에 저장하는 방법이 있다...

지금까지 우리는 relation 그 자체의 표현에 대해서만 다뤄왔다. Relation DataBase System은 relation에 대한 정보를 갖고 있어야 한다. (ex. relation의 스키마) 일반적으로 데이터에 대한 데이터를 metadata라고 한다. Relational 스키마와 relation에 대한 메타데이터는 data dictionary 또는 system catalog라고 부르는 곳에 저장되어 있다. data dictionary에 저장되어 있어야 할 데이터들은 다음과 같다. - relation의 이름 - 각 relation의 속성의 이름 - 속성의 특징(domain), 길이 - 데이터베이스에서 정의된 view의 이름과 view의 정의 - 무결성 제약조건(Integrity constrain..

지금까지 record가 어떻게 파일 구조로 표현되는지 공부했다. relation = set of records다. 그렇다면, 레코드의 모음에서 레코드들을 어떻게 구성할지에 대한 질문이 따라온다. 이에 대한 방법이 여러 가지가 있는데 각각에 대해서 하나씩 살펴볼 것이다. - Heap file organization : 모든 record들이 공간이 있는 파일의 모든 곳에 저장될 수 있어서 record의 순서가 보장되지 않는다. - Sequential file organziation : 각 record가 "search key"를 통해 순서대로 저장된다. - Multitable clustering file organization : 몇몇 다른 relation들의 record를 같은 파일에 저장해서 join 연산..

DB는 OS에 저장되어 있는 수많은 여러 파일들과 매핑되어 있다. 이 파일은 영구적으로 디스크에 저장된다. 파일은 논리적으로 레코드의 연속으로 구성되어 있다. 각각의 레코드들은 디스크 블록과 매핑되어 있다. 파일은 OS에서 기본적인 구성으로써 제공되기 때문에 파일 시스템이 있다고 추정할 수 있다. 여기서 우리는 파일을 논리적인 데이터 모델로 표현하기 위한 방법으로 생각할 필요가 있다. 각각의 파일은 논리적으로 블록이라는 단위로 나뉜다. 블록이란 저장장치의 분할과 데이터 전송의 단위이다. 대부분은 블록 사이즈를 4~8KB 정도로 지정하고 상황에 따라 여러 크기를 가질 수 있다. 블록은 여러 개의 레코드들을 포함할 수 있다. 그래서 모든 레코드는 블록보다 작다라는 추정을 할 수 있다. (물론, 이미지와 같은..

이번 챕터에서는 저장 매체에 쌓이는 데이터의 구성과 데이터에 접근하는 방식에 대해서 살펴본다. 영구적인 데이터는 비휘발성 메모리에 저장되어야 한다. 대표적으로 자기식 디스크나 SSD가 있다. 자기식 디스크랑 SSD는 블록(block)으로 구조화된 기기이다. 즉, 블록 단위로 데이터를 읽고 쓴다. 반면에 데이터베이스는 레코드를 다루는데 이는 블록보다 훨씬 작은 개념이다. 대부분의 데이터베이스는 OS의 파일을 레코드 저장을 위해 중간 계층으로 사용한다. 이때, 블록의 자세한 내용을 추상화한다. 하지만, 효율적인 접근과 결함 복구를 지원하기 위해서 데이터베이스는 블록(block)을 지속적으로 알아야 한다. 그래서, 13.2에서 블록의 구조를 고려하면서 각각의 레코드가 어떻게 파일에 저장되는지 공부한다. 레코드..