[2023-07-25] Intro to Database Systems 4강 - Data Storage 2

CoodingPenguin commented 1 year ago

📌 개요

시간: 2023-07-25(화) 21:00
자료: 4강 Data Storage 2
참여자: 펭귄, 그루트, 렉사, 나강

✍️ 준비

아래 양식을 복사해 스터디 준비를 완료해주세요!

## 💬 생각

<!--강의를 듣고 생각한 내용을 3줄 내로 간단히 정리해주세요!-->

- ...

## ❓ 질문

<!--공부하면서 궁금한 점을 작성해주세요!-->

- ...

## 📚 참고 자료

<!--공부하면서 같이 공부한 자료를 첨부 및 공유해주세요!-->

- [...](...)

CoodingPenguin commented 1 year ago

💬 생각

컴퓨터구조를 잘 알고 있어야 더 수월하게 들을 수 있을 것 같다.
- 결국 한 권으로 읽은 컴퓨터 구조와 프로그래밍 책을 꺼내들었다.
들으면서 계속 머리 속을 맴돌았던 게, CDC 기술도 이와 관련이 있는 건지 궁금하긴 했다.
- 찾아봤는데 CDC는 DB 변경 사항을 계속해서 캡처하는 기술이고, Log-Structured Storage는 저장 방식 중 하나이다.
- 둘 다 로그를 본다는 점에서 공통점이 있지만, 전혀 다른 개념인 것으로 보인다.

❓ 질문

페이지 지향 저장 방식의 단점을 말할 때 "Useless Disk I/O"을 단점으로 꼽았는데, 그 이유가 디스크에 페이지를 저장해서 그런가? 그래서 읽을 때마다 메모리에 올려야되서?
- 맞음
만약에 값이 Overflow Page보다 큰 경우 데이터 일부를 저장과 동시에 다른 일부를 저장한 다른 Overflow Page의 포인터도 가지게 되는 게 맞는가?
- 찾아봐야 됨
아직 External Value Storage 방식과 S3와 같은 별도 Storage를 둬서 실제 데이터는 거기서 저장하고 DB에는 이와 관련한 링크를 두는 방식의 차이 설명한 걸 명확히 이해하지 못했다.
- 찾아봐야 됨

📚 참고 자료

개발자를 위한 SSD (Coding for SSD) – Part 3 : 페이지 & 블록 & FTL(Flash Translation Layer) | kakao tech

Nagunt commented 1 year ago

💬 생각

기존의 Page 저장 방식과 다른 Log-Structured Storage에 대한 내용을 이야기했다.
- Log 방식은 데이터 자체가 저장되는 Page 방식과 달리, 특정 공간에 대한 변경점을 Log 방식으로 추적한다.
- 그 공간에 대한 데이터를 가져올 때, 가장 마지막에 수정된 Log를 참조하여 값을 가져오고, 그것을 위해 별도의 추적 Table이 필요하다.
- Log는 무한 증식하기 때문에, 이를 요약/압축하는 기능이 존재하며, 강의에서는 Universal Compaction과 Level Compaction 두 가지 방법에 대해서 이야기했다.
데이터 표현방식에 대해서 이야기했다.
- Int나 Float, Double, Decimal 등의 자료형이 있으며, 실수형을 표현할 때 속도를 중요시하면 Float나 Double을, 정확성을 중요시하면 Numeric이나 Decimal을 사용한다.
- 속도가 느린 Numeric/Decimal의 연산 속도를 향상시키기 위해 LibFixeyPointy라는 라이브러리를 사용할 수 있다? 보니까 CMU DB에서 자체적으로 개발한 라이브러리 인 듯. (링크 : https://github.com/cmu-db/libfixeypointy)
- 대부분의 DBMS에서는 tuple이 단일 page보다 크기가 커지는 것을 허용하지 않으며, 이를 위해 pointer를 사용해 참조할 수 있는 overflow 페이지를 지원한다. 또한, 매우 큰 자료형에 대해서는 외부 파일을 참조할 수 있는 BLOB Type을 지원하며, DBMS에서는 이 외부 파일에 대해 오직 참조만 가능하다.
System Catalog는 DB가 어떤 식으로 표현되는지 정의한 Meta-File로 이해했다.

❓ 질문

Log-Structured Compaction을 설명할 때 영상에서는 DBMS does not need to maintain...이라고 해놓고 제공한 ppt에서는 DBMS does need to maintain....이라고 적어놨다. 강의 내용 상 사용하지 않는 공간에 대해서는 추적할 필요가 없다, 등장하지 않아도 된다 이런 내용의 질문/답변이 오간 것으로 보아 does not need to... 가 옳아 보이는데 여러분 생각은 어떠신지?
- ppt가 잘못되었다. does not이 맞다.
Compaction을 설명할 때 압축된 Sorted Log File이 기존 Log File을 overwrite 하지 않는다 라고 강의 내용에서 이야기했는데, compaction의 효과를 보기 위해서는 (저장 공간의 압축?) overwrite해야 하는 것이 맞지 않을까? (29:10~ 내용 참조) 아니면 단지 빠른 search를 위해서 요약본만을 새롭게 만들어 놓는다는 것일까.
- 기존 것을 수정하지 않는다. 반드시 새롭게 작성한다.
id - log와 매칭되는 datamap에 대해서 이야기할 때, tree로 사용하는 이유가 hashtable로는 rangescan이 불가능해서 tree로 사용한다고 하는데, hashtable로는 왜 rangescan이 불가능하다고 하는걸까?
- hashtable은 1대1 매칭이기 때문에 rangescan이 불가능하다고 한다. (자료구조에 대한 이해..?)

jonyejin commented 1 year ago

💬 생각

📝 Log-Structed Storage: 튜플 대신 로그를 저장한다.

put과 delete밖에 없다.
빠르게 쓰고 천천히 읽는다. (쓸 때는 순서대로 쓰면 되기 때문에 빠르다)
디스크에 순서대로 기록하기 때문에, random disk I/O보다 빠르다.
index로 log의 특정 위치로 이동할 수 있다.
record를 읽기 위해서는 최근것부터 읽어서 튜플을 재생산한다.

📝SSTable: Sorted String Tables

log를 compact해서 id기준으로 정렬 후 테이블로 만든다.
tuple search 가 빠르다.

📝Compaction

Universal Compaction
Level Compaction

📝Data Representation

❓ 질문

그러면 log-structured일 때 정의되지 않은 값을 찾으려면 끝까지 위로 가서 봐야된다는건가?
M-Map
압축하고 기존 로그 데이터를 버리나요?
압축 할 때 동기화 이슈가 발생하나요?

IamGroooooot commented 1 year ago

💬 생각

크게 두 가지를 배웠다. Log Structured Storage와 Data Representation

저번 시간에 얘기한 page-oriented architecture의 Slotted Page 디자인의 문제점을 해결하기 위해 Log Structered Storage를 제시했다. 컨셉은 AWS S3처럼 데이터를 덮어씌울 수는 없고 항상 새로운 페이지를 생성하도록 하는 것이다.

Log Structured DB

db를 overwrite가 안 되는 append만 할 수 있는 로그 파일로 취급
튜플 대신 log 저장
read가 느릴 수 있다
시간 정보가 필요 없기 때문에 로그를 id로 정렬된 테이블로 압축할 수 있다
단점은
- write amplification: 같은 데이터를 반복적으로 rewrite
- 압축이 무거움

Data Representation

실제 postgres랑 mysql의 numeric 구현체를 보여주는데 너무 달라서 놀랐다. postgres는 digit으로 unsigned char를 쓰고 mysql은 buf(postgres의 digits 변수 역할) int32를 썼다.

❓ 질문

다들 외부 값, 파일을 어떻게 저장하는지 궁금하다.

외부 파일시스템에 저장하고 slug를 저장하는지 등

team-mabub / mabub-study