서울대학교 데이터사이언스대학원 정형수 교수님의 "데이터사이언스 응용을 위한 빅데이터 및 지식 관리 시스템" 강의를 필기한 내용입니다.
속기록
- 날것의 필기록이라 좀 설명이 부실합니다.
Database, DBMS
- Database: Data + structure + real-world aspect - 현실의 특정 측면을 나타내는 구조화된 데이터들의 모음
- Structure definition class: Data Model
- 그 data model 에 따라 정의한 data 의 structure: Schema
- Schema 에 따라 구조화된 data: Database
- DBMS: DB 를 manage 하는 system
- System: 여러개의 component 로 구성 + 이것이 외부와 소통하는 일련의 계
- Three-piece Architecture
- File 형태의 database
- 그리고 이것을 관리하는 DBMS
- DBMS 와 송신하는 lang (interface): SQL
Layered Architecture
- Query Parsing: token화, 아마도 static analysis, syntax checking 등
- Query Plan, Optimization: query 를 relational algebra 로 바꿈에 추가적으로 DB 가 수행하기 편한 순서로 바꾼다.
- 어떻게 하는 것이 동일한 결과가 나오면서도 가장 실행시간이 짧을 것인지 optimizer 가 판단하여 query plan (plan tree) 을 짠다.
- 근데 이것을 완벽하게 estimation 할 수는 없다: N-P problem
- 그리고 이런 query plan 을 미리 구워놓을 수도 있다더라.
- Plan Tree: 어떤 데이터를 가져와서 어떻게 처리할지에 대해 step 별로 tree 의 leaf 에 두고 차곡차곡 올라오면서 처리
- Relational Operator: 그리고 이 plan tree 의 각 node 를 처리하는 놈
- Relational operator 아래에 Query Executor (QE) 가 있어서 여기서 BFS (와 유사… volcano model) 식으로 query plan node 를 처리함
- Index Management (Access Methods): PK 와 같은 abstraction 으로는 데이터의 실제 physical location 을 알 수 없기 때문에 이 간극을 메우기 위해 index 가 필요함
- Index 는 key 와 location 을 연결지어주는 놈
- B+tree 나 hash 등의 방법으로 lookup 을 도와줌
- 다만 index 가 없어도 correctness 에는 문제가 없다: full scan 을 하면 되기 때문
- 하지만 당연히 느리다
- Buffer Manager: 매 read, write 마다 io 를 할수는 없기 때문에 buffer (cache) management 가 필요
- Write 의 경우에 잠깐 갖고 있다가 한꺼번에: buffer (write buffering)
- Read 의 경우에 갖고 와서 다음 read 에 대응: cache (read cache)
- 물론 이쪽도 없어도 된다; 매번 io 하면 되니까
- Disk Space Manager (Storage Manager): 그리고 마지막 layer 에 실제로 io 를 하는 disk space management 가 있다.
- Index, buffer, disk mgmt 에 concurrency, recovery control 이 들어가게 되고 저 concurrency + recovery 가 transaction manager 이다.
- Client 혼자 사용하고 있는 것처럼 느끼게 하기 위해 concurrency 가 필요하다.
- 여기서 Relational operator (+ QE) 윗부분이 Frontend Engine, 그 아래가 Backend Engine
- 위의 Frontend Engine 이 있으면 SQL, 없으면 No-SQL
- 데이터를 다루는 모든 시스템에는 저 Backend Engine 이 들어가있다.
여기부터는
2024-09-04강의
DB from Scratch: Problems with the CSV Approach
- Data Integrity: 데이터의 무결성을 어떻게 보존하지?
- 가령 존재하지 않는 artist 의 album 을 추가하는 것을 어떻게 막을 수 있지?
- Implementation: 어떻게 빠르게 작업을 처리하지?
- Linear search 는 너무 느리다. 이걸 어떻게 빠르게 할 수 있을까?
- Data race 는 어떻게 해결하지?
- Durability:
- DR (Disaster Recovery) 는 어떻게 하지? 어떻게 복구하지?
- 이러한 문제들을 이미 해결해놓고 적절한 API 를 제공해 사용자가 사용할 수 있게 해주는 것이 DBMS 이다.
Relational Data Model, RDM
- Edgar ted codd 선생이 제안
- DB 가 real-world 의 한 측면을 캡쳐한 구조화된 데이터인데, 이 real-world 를 어떻게 data 의 형태로 abstract 할 지가 Data Model 이다.
- 이 data model 에는 relational , NoSQL 등등이 있다.
- RDM 은 (1) 대상과 (2) 대상간의 관계 를 모델링하는 방법이다.
- Real world 에서 우리가 describe 하고자 하는 대상을 Entity 라고 한다.
- 그리고 이 entity 간의 Relation 도 describe 할 필요가 있을거고
- Relation 에서는 어떤 놈들이 관계가 있는지 그 대상들을 명확하게 특정할 수 있어야 한다.
- 그래서 entity 의 어떤 tuple 을 고유하게 특정하기 위한 PK 와
- 그것을 참고 (reference) 하고 있는 FK 가 필요한거고
- 이런 참조관계가 모순 없이 지켜져야 한다는 것이 Referential Integrity (FK Constraint) 이다.
- 이러한 Entity 와 Relation 은 Table 의 형태로 구현이 된다.
- 러프하게는 Entity, Relation, Table 을 같은 의미로 받아들여도 된다.
- 그리고 이 대상에 대해 기술하고자 하는 여러 특징들을 Attribute 라고 한다.
- 즉, column
- 이때 어떤 attribute 들이 있고 어떤 자료형을 가지고 있는지를 “구체적”으로 기술해놓은 spec 문서같은 이놈이 Relational Schema 이다.
Data independence
- 이건 data 의 schema change 가 다른 계층에는 영향을 주지 않도록 해야 한다는 원칙이다.
- 가령 어떤 데이터가 어떤 파일에 저장되어있는지 (즉, Physical Schema) 가 바뀌어도 그 위의 SQL (즉, Logical Schema) 를 바꾸지 않아도 되게끔 한다는 것.
- 이것이 Physical Data Independence (Physical DI) 다.
- Logical DI 는 external schema 인 “view” 와 SQL 을 분리:
- 즉, SQL 을 바꿔도 view 를 바꾸지는 않아도 된다는 것.
- 참고) Indirection: logical address 와 physical address 를 분리해서 physical 이 변경되어도 logical address 는 변경하지 않아도 되게 하는 기법
- 이 mapping 을 Indirection Mapping Table 이라고 한다.
- DBMS 에서는 storage manager 가 관리한다
RDM
- table, relation, tuple, record, attribute 뭔지 다 알테니 패스
NULL은 “undefined” 의 의미이다.- Tuple 을 unique 하게 특정하는 attribute 를 PK 로 한다.
- Relationship 을 위해 다른 entity 의 PK 를 가리키는데 사용되는 놈이 FK
- 이 FK 는 어떤 PK 를 당연히 가리키고 있어야 된다: 그래야 하나를 특정할 수 있으므로.
- 또한 update 시 FK constraint violation checking 을 위해서도 필요하다.