in-memory DB와 디스크기반(traditional) 데이터베이스

인메모리 데이터베이스와 디스크기반, 즉 전통적인 데이터베이스의 차이점과

데이터를 저장하는 장소인 RAM / SSD / HDD 의 특징과 차이점을 알아보자.

https://medium.com/@denisanikin/when-and-why-i-use-an-in-memory-database-or-a-traditional-database-management-system-5737f6d406b5

데이터베이스 관리 시스템을 선택하는 큰 틀

1. 데이터를 어디(RAM or SSD or HDD)에 저장할 것인가?

2. 그 저장소에 어떤 데이터베이스 시스템을 설치할 것인가?

각각의 데이터 저장소에는 고유한 접근 시간과 속도, 가격 차이가 있다.

 An IMDB stores a copy of data in RAM and persists this data on an SSD or HDD. An RDBMS uses RAM for caches, write-back buffers and other optimizations, and also persists data on an SSD or HDD.

                          (왼쪽) In-Memory Database                                      (오른쪽) on-Disk Database

RAM (Random Access Memory)

임의의 영역에 접근하고 읽고 쓰기가 가능한 주기억 장치. 램은 어느 위치에 저장된 데이터든지 접근(읽기 및 쓰기)하는 데 동일한 시간이 걸리는 메모리이기에 '랜덤'이라는 명칭이 주어졌다. 하드 디스크는 저장된 위치에 따라 접근하는 데 걸리는 시간이 다르다.

RAM은 초당 100MB의 읽기/쓰기를 수행한다. 순차적 읽기/쓰기는 초당 1GB 이상으로 더욱 빠르다. 

In-Memory DataBase

Q. RAM은 휘발성 메모리인데 만약 재부팅하거나 정전이 되었을 때 데이터가 다 사라지지 않을까? 저장은 어떻게?

You may ask: how can in-memory storage be persistent? The trick here is that you still keep everything in memory, but additionally you persist each operation on disk in a transaction log. Look at the picture:

메모리 내 저장이 어떻게 지속될 수 있습니까? 트릭은 여전히 ​​모든 것을 메모리에 유지하지만 트랜잭션 로그에 디스크의 각 작업을 지속시키는 것입니다. 사진을 봐:

The first thing that you may notice is that even though your fast and nice in-memory database has got persistence now, queries don’t slow down, because they still hit only the main memory like they did with just an in-memory database. Good news! :-) But what about updates? Each update (or let’s name it a transaction) should

not only be applied to memory but also persisted on disk. A slow disk. Is it a problem? Let’s look at the picture:

가장 먼저 기억해야 할 점은 빠르고 좋은 메모리 내장 데이터베이스가 지속성을 유지하더라도 쿼리가 느려지지는 않습니다. 메모리 내 데이터베이스 만 사용한 것처럼 주 메모리 만 사용하기 때문입니다. 좋은 소식! :-) 그러나 업데이트는 어떨까요? 각 업데이트 (또는 트랜잭션 이름 지정)는 메모리에 적용될뿐만 아니라 디스크에 유지되어야합니다. 느린 디스크. 이게 문제가 되나요? 그림을 보자.

Transactions are applied to the transaction log in an append-only way. What is so good about that? When addressed in this append-only manner, disks are pretty fast. If we’re talking about spinning magnetic hard disk drives (HDD), they can write to the end of a file as fast as 100 Mbytes per second.

트랜잭션은 추가로 트랜잭션 로그에 적용됩니다 . 그것에 대해 얼마나 좋은가? 이 추가 전용 방식으로 처리 될 때 디스크는 매우 빠릅니다. 마그네틱 하드 디스크 드라이브 (HDD)를 돌리는 것에 대해 이야기하는 중이라면 초당 100MB의 빠른 파일 끝에 쓸 수 있습니다. 

(트랜잭션 로깅 아래 참고)

https://www.mssqltips.com/sqlservertutorial/3302/what-is-the-transaction-log/

HDD의 순차적 읽기/쓰기 처리 속도 : 100MB/초

100MB = 100,000,000byte

ex) 트랜잭션 크기가 100byte 라면 In-Memory DB에서 초당 1000,000건의 트랜잭션을 처리할 수 있다. 

인메모리 방식에서 쿼리가 들어오면 메모리안에서 데이터를 읽는다. 업데이트? or 트랜잭션이 발생하면 디스크에 순차적 읽기를 통해 빠르게 가져온다.

기존 디스크방식은 (쿼리 캐시는 잠시 제외.) 쿼리가 들어오면 디스크에서 읽어와야 한다. 근데 어떤 쿼리인지 모르기 때문에 랜덤으로 접근하기 때문에 순차적 접근보다 훨씬 더 느리다. 

Q. 인메모리 방식에서 트랜잭션이 발생인지 업데이트만인지?

Q. 디스크에 접근하는 방식이 랜덤 or 순차적 접근에 따라 속도차이가 나는데 인메모리 방식이 순차적 접근이 가능한것은 어떤 쿼리를 실행할지 알고 있기 때문?

순차적과 랜덤 액세스에 대한 이해가 필요함. 

순차 및 랜덤 액세스 작업의 구별점 중의 하나는 디스크 사용의 측면에서 응용 프로그램의 효율성을 평가하는 방법의 차이 입니다. 디스크 하드웨어 작업 원리에 근거하여 볼 때 순차적으로 데이터를 엑세스하는 것은 렌덤 엑세스 하는 것보다 빠릅니다. 디스크 헤드의 오른쪽 디스크 실린더에서 데이터를 엑세스할 때는 I/O 프로 세스의 다른 부분에서 보다 더 많은 시간이 걸립니다.  랜덤 읽기는 순차 읽기보다 많은 찾기 조작(seek operations )이 필요하고 또한 낮은 데이터 처리량을 전송합니다.  랜덤 쓰기는 랜덤 읽기와 비슷한 과정을 거칩니다.  

https://kb-ko.sandisk.com/app/answers/detail/a_id/9735/related/1

=> 랜덤 액세스가 뭐지? => 자료 (http://www.gurubee.net/lecture/2230) 

=> 인덱스가 뭐지? => 자료(http://choko11.tistory.com/entry/%EC%9D%B8%EB%8D%B1%EC%8A%A4-1-%EA%B0%9C%EB%85%90%EC%A2%85%EB%A5%98%EC%A3%BC%EC%9D%98%EC%82%AC%ED%95%AD)

=> 어떤 데이터가 어디에 있다는 위치 정보를 가진 주소록. 데이터들의 ROWID 정보를 별도의 세그먼트에 넣어 저장하고 관리

인덱스 생성 원리

전체 테이블 스캔 (Table Full Scan) -> PGA내의 Sort Area에서 정렬 (sort) -> Block 에 기록

- 정렬 작업을 하기 때문에 시간이 많이 걸림

- 인덱스는 데이터가 정렬되어 들어감

인덱스 구조와 작동원리 (B-Tree 인덱스 기준)

테이블과 인덱스 비교

- 테이블은 컬럼이 여러 개, 데이터가 정렬되어 있지 않고 입력된 순서대로 들어감

- 인덱스는 key와 ROWID 컬럼 두 개로 이루어져 있음 (오름/내림차순 정렬 가능)

* key : 인덱스를 생성하라고 지정한 컬럼의 값

=> ROWID 가 뭐지? => 자료(http://www.gurubee.net/lecture/2927)

ROWID 는 데이터베이스 내 데이터 공유 주소로 이를 통해 데이터에 접근할 수 있다. 

SQL문으로 데이터에 접근하기 위해서는 주소를 알아야 한다. 

데이터베이스에서 데이터마다의 주소를 의미하는 개념이 바로 ROWID다. ROWID는 각각의 데이터를 구분할 수 있는 유일한 ID이기도 하다. 데이터마다 유일하기 때문에 오라클 내부에서는 데이터를 가르키기 위한 주소로 쓰인다.

예컨대 이메일 주소는 사람마다 고유하다. 그렇게 때문에 특정 이메일을 보내면 해당 이메일 소유권자가 해당 메일을 받게 된다. 이처럼 하나의 ROWID를 안다는 것은 해당 데이터 한 건을 액세스할 수 있음을 의미한다.

위 그림은 ROWID 아키텍처로, 크게 다음과 같은 4개의 영역으로 구성돼 있다.

오브젝트 번호

해당 데이터가 속하는 오브젝트 번호다. 오브젝트별로 유일한 값을 가지고 있다.

상대 파일 번호

오라클의 테이블 스페이스는 여러 개의 DATA FILE를 생성할 수 있다. 오라클 8i부터는 파일 번호가 10비트이기 때문에 테이블 스페이스당 1023개의 DATA FILE을 추가할 수 있다. 여기서 DATA FILE은 해당 테이블 스페이스의 상대 파일 번호를 의미하며, 각 데이터별로 유일한 값을 가진다.

* 테이블 스페이스 : 테이블 스페이스는 세그먼트를 담는 컨테이너로 여러 데이터 파일로 구성된다. 보통 MySQL 같은 DBMS에서 워크벤치를 사용했을 때 보면 테이블 스페이스 안에다가 테이블을 만드는 것을 알 수 있다. 여러 테이블이 있는 공간을 나타낸다. 

* 데이터 파일(data file) : 디스크 영역(데이터 파일 + 임시 데이터 파일 + 로그 파일)의 한 부분

블록 번호

파일 안에 어느 블록인지를 의미한다.

데이터 번호

블록의 HEADER에서 해당 데이터의 위치값을 저장하고 있는 DATA DIRECTORY SLOT을 가르킨다. 오브젝트 번호, 파일번호, 블록 번호가 같으면 데이터 번호는 블록별로 데이터가 저장돼 있는 순서를 뜻한다. 이처럼 ROWID는 해당 데이터의 저장 위치를 가리키는 요소라고 할 수 있다.

<리스트 1>에서 EMP 테이블은 ROWID라는 컬럼이 없음에도 ROWID라는 컬럼이 존재하는 것처럼 보인다. 모든 테이블의 모든 데이터는 내부적으로 ROWID를 저장하고 있으므로 해당 ROWID는 언제든 추출 가능하다. 지금부터는 앞서 추출된 ROWID를 분석해 보자.

ROWID의 처음 6자리

AAAMfP는 오브젝트 번호다. 이는 오브젝트별로 유일한 값이므로 EMP 테이블의 모든 데이터의 ROWID는 AAAMfP로 시작한다.

-> 테이블 번호?

7~9자리까지

EMP 테이블이 저장돼 있는 테이블 스페이스 상대 파일 번호다. EMP 테이블의 데이터일지라도 테이블의 익스텐트(EXTENT)가 다른 데이터 파일에 할당될 수 있다. 이 경우 해당 값은 서로 다르게 할당된다.

*익스텐트(EXTENT)

익스텐트는 여러 개의 연속된 블록집합이다. I/O단위는 블록이지만 테이블 스페이스로부터 공간을 할당하는 단위는 익스텐트이다. 

10~15자리까지

블록 번호로 해당 데이터가 저장돼 있는 블록을 뜻한다. <리스트 1>의 데이터블은 AAAAAg로 같은 블록에 저장돼 있는 것을 알 수 있다. 이 부분은 클러스터 팩터(Cluster Factor)와 많은 관계를 가지고 있다.

액세스하고자 하는 데이터들이 같은 블록안에 저장돼 있으면 성능이 많이 향상된다. 이 부분은 클러스터 팩터 최적화 단원에서 좀 더 깊이 다뤄보도록 하겠다.

16~18자리까지

오브젝트 번호, 파일 번호, 블록 번호가 같다면 해당 데이터 번호는 해당 데이터의 저장 순서를 의미한다.

<리스트 1>에서 SMITH는 AAAAAg 블록의 첫 번째 데이터로, 데이터 번호는 AAA다. ALLEN은 동일 블록에서 데이터 블록에 AAB를 가지므로 이를 통해 추후에 저장됐다는 것을 알 수 있다.

동일한 오브젝트 번호, 파일 번호 및 블록 번호를 가진다면 데이터 번호는 해당 데이터의 저장 순서를 의미한다.

위의 예제에서 ‘SMITH’은 AAAAAg 블록에 첫 번째 저장된 데이터로 데이터 번호가 AAA 값을 가지며 ‘ALLEN’는 동일한 AAAAAg 블록에, 테이블 번호가 AAB이므로 SMITH이 저장된 이후에 저장된 값이다.

이처럼 ROWID를 통해 데이터의 많은 정보들을 알 수 있다. ROWID가 사용되는 부분과 해당 ROWID를 튜닝하는 방법 등은 다음 시간에 살펴보도록 하겠다.

Q.