VIRGIL ABLOH

일단 shared buffer 영역이 존재하는 이유는 매번 쿼리를 날릴때마다 DB는 디스크에 접근해서 데이터를 가져오기엔 비용과 부하가 발생한다.이걸 해결하려면 메모리에 데이터를 미리 캐싱해서 올려두면 매번 디스크 IO를 발생시키지않고 응답속도와 비용절감을 가능케할 수 있다. 일단 책을 읽어보면서 buffer descrioptor는 무슨 역할을 하는지 궁금하게 했다.순수하게 텍스트로 보면 그냥 버퍼 설명하는 주체?라고 생각하게 된다.책에서는 Lock이라는 설명이 들어있었다 그래서 내가 아는 비관적/낙관적 락을 관리하는 주체인가? 해서 제미나이한테 물어보니 내가 아는 락이 아니라 shared pin이라고 shared buffer영역에서 사용되는 개념이였다. 말그대로 쿼리로 인해서 해당 테이블 데이터를 사용..

create table tab_OID(id integer); --테이블생성-- 위에서 생성한 테이블의 oid 조회select OID, relname from pg_class where relname ='tab_oid'; --16426,tab_oidselect 'tab_oid'::regclass::oid; --16426생성한 테이블의 OID 조회 가능 main fork에 대해서데이터를 저장하는 파일의 용량이 1GB를 넘기게 되면 DB는 해당 파일을 세그먼트로 나눠서 관리하게 된다 이때 relfilenode이라고 명칭한다.예들을어 oid=111인 객체 즉 테이블(relfilenode=16000으로 테이블 생성시 선언되는 값)이 1GB를 넘기게 되면 새로운 파일의 relfilenode은 16000.1, 160..

PostgreSQL은 시스템 메모리가 1GB 이상일 경우 전체 메모리의 약 25%를 shared_buffers로 설정하는 것이 일반적이다.PostgreSQL은 DB 내부 버퍼(shared_buffers)와 OS의 페이지 캐시를 함께 활용하는 구조이기 때문에, shared buffer를 과도하게 크게 설정하지 않는다.데이터 조회 시 ① shared buffer → ② OS page cache → ③ 디스크 순으로 접근하여 최대한 디스크 I/O를 줄인다.반면 Oracle은 DB 내부 메모리를 크게 사용하는 구조이며, PostgreSQL은 OS 캐시와 협력하는 방식으로 전체 시스템 메모리 효율을 높이는 전략을 사용한다. 공유 메모리shared buffer: 일반적인 데이터베이스의 버퍼영역과 동일하며 디스크 I..

여기서 볼수 있는 포인트는 인덱스도 페이지로 관리된다.세컨더리 인덱스도 별도의 페이지로 추가됨을 확인할 수 있다.클러스터링 인덱스는 데이터가 증가함에 따라 2개의 페이지(leaf page)로 분리되고 기존의 인덱스(root page)는 새로 분리된 2개의 페이지에 대한 주소값을 갖는다.

DB에서 데이터는 책의 페이지처럼 쪽으로 나눠져서 관리되고 있다.그래서 데이터를 저장할때는 페이지마다 저장되고 있으며 페이지에서는 레코드(로우)들로 저장되며 해당 페이지 상단에는 레코드마다 위치를 가리키는 라인포인터 영역이 있다. 쉽게 이야기하면 페이지 마다 상단에 헤더영역이 있는데 그중에 라인포인터는 데이터의 위치를 가리켜서 데이터를 조회하거나 입력할때 사용된다. 데이터가 입력되면 페이지의 빈공간에서 하단에서 상단으로 채워진다.만약 데이터가 삭제되면 라인포인터는 해당 로우에 대한 데이터가 비어있다고 저장하며 추후 재사용된다.

Oracle오라클에서 트랜잭션이 커밋되면 트랜잭션 테이블의 undo 세그먼트 헤더의 state 값을 10(active) -> 9(committed) 처리scn(system change number)에는 현재 커밋시점의 scn으로 업데이트그 외 ITL(interested transcation list)의 항목들중 일부 컬럼들을 commit시점의 데이터로 정리하는데 이를 블록 클린 아웃만약 클린아웃할 항목들이 많으면 일단 메모리에 있는 일부만 우선 클린아웃을 하고 나머지들은 해당 데이터를 select할때 동작한다. 이를 dealay block cleanout이라고 한다. 해당 기능은 디비에 과부하를 줄이기 위해 동작한다.Postgresql레코드마다 튜플헤더가 존재하는데 이중에 infomask컬럼의 첫번째 b..

트랜잭션과 함께 데이터 변경이 발생하면 해당 데이터 로우의 trx_id는 최신 트랜잭션 id를 저장롤백 세그먼트 영역이 별도로 존재하는데 거기에는 undo 세그먼트가 그 하위에 undo 로그로 변경 전의 데이터를 저장roll_ptr은 해당 데이터 로우에 존재하며 해당 영역에는 undo 로그의 위치를 저장아직 커밋이 안된상태에서 select 쿼리가 오면 roll_ptr를 통해 undo 로그에 저장된 변경전의 데이터를 반환커밋이 되면 해당 undo 로그는 필요하지 않으므로 가비지 콜랙터에 들어가게되어 삭제롤백이 되면 해당 데이터 로우의 roll_ptr의 undo 로그에 있는 변경전 데이터를 다시 입력하여 데이터 원복 동작 시각화(생성: GPT)CREATE TABLE test_table ( id INT ..

예시의 데이터로 tmin=1, value="one"데이터가 트랜잭션으로 수정이 발생하면물리적으로 새 로우가 생성되고 tmin=2, tmax=null, value="two" 상태로 생성변경전의 로우에는 tmax=2로 변경이 된다.(현재 value="one"인 데이터의 tmin=1, tmax=2)이때 만약 select 쿼리가 오면 해당 시점의 데이터는 아직 반영이 안되어서 value="one"을 리턴하게 된다.여기서 커밋이 되면 two가 반영이 되고 vaccum이 동작하면 tmax에 값이 있는 로우를 dead tuple로 판단하여 물리적 삭제여기서 롤백이 되면 물리적으로 새로 생성된 로우는 삭제되고 이전데이터의 tmax=null 처리되어 유효한 데이터로 판단 동작 시각화(생성: GPT)-- 1. 테이블 생성..

트랜잭션이 시작되면서 데이터 변경이 발생, 변경이 발생한 데이터의 로우의 헤더영역에 ITL(interested trasaction list) 에 해당 트랜잭션 id와 UBA(undo block address) 에는 undo block에 대한 주소값을 저장undo block에는 old version(이전 데이터)를 저장만약 이 시점에 select 쿼리가 날라오면 consistent read(일관성 읽기)로 인해 old version의 데이터를 CR 캐시에 저장되고 해당 데이터를 리턴(트랜잭션이 끝나더라도 CR 캐시는 데이터가 변경되더라도 일정시간 저장)만약 커밋이 되면 데이터 변경 완료만약 롤백이 되면 해당 데이터 로우에 저장된 ITL영역의 UBA를 이용해서 old version 데이터를 가져와서 원복..