일단 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..
[Kubernetes] CNI, Flannel, 그리고 Service의 차이 완벽 정리쿠버네티스를 공부하다 보면 네트워크 부분에서 머리가 아파옵니다. CNI, Flannel, Service... 다 통신을 하게 해주는 것 같은데, 도대체 무슨 차이가 있을까요?이번 글에서는 쿠버네티스 네트워크의 핵심 개념들을 **"도로"와 "내비게이션"**에 비유하여 아주 쉽게 정리해 보겠습니다.1. CNI (Container Network Interface)란?한 줄 요약: 쿠버네티스 네트워크의 "표준 규격(인터페이스)"쿠버네티스는 직접 네트워크 기능을 만들지 않았습니다. 대신 **"IP는 이렇게 주고, 연결은 이렇게 하라"**는 규칙(Interface)만 정해두었습니다. 이 규칙이 바로 CNI입니다.CNI의 역할: 파..
[Kubernetes] Kind로 실습하며 정리한 핵심 개념 요약 (노드, 컨트롤러, 서비스)로컬 쿠버네티스 학습 도구인 **Kind(Kubernetes in Docker)**를 사용하여 실습하면서 알게 된, 초심자가 헷갈리기 쉬운 핵심 개념들을 정리해 보았다.1. 인프라: Kind 노드의 정체 (가면무도회)kind create cluster로 노드 3개를 띄웠을 때, 내 컴퓨터에서는 무슨 일이 일어난 걸까?실체: VM(가상머신) 3대가 아니라, 도커 컨테이너 3개가 생성된 것이다. (docker ps로 확인 가능)속임수: 이 컨테이너들은 내부에서 systemd 등이 돌아가며 실제 OS처럼 행동한다. 쿠버네티스 마스터는 이들을 "진짜 컴퓨터(Node)"라고 인식한다.장점: 진짜 VM 3대를 띄우는 것보다..
스프링 컨텍스트 계층은 크게 나누면 자식 컨텍스트인 Servlet-WebApplicationContext가 있고 그의 부모인 Root-WebApplicationContext가 있다. Servlet-WebApplicationContext엔 주로 웹과 관련된 컨트롤러-뷰-헨들러가 있으며Root-WebApplicationContext엔 비즈니스 계층, DB 커넥터와 같은 공통적으로 사용하는 리소스에 대한 빈을 관리한다. 그래서 빈을 조회하면 먼저 자식 컨텍스트에서 조회를 하고 자식에게 빈이 없으면 부모 컨텍스트에서 조회를 하고 빈을 찾으면 자식 컨텍스트에게 주입하여 사용한다. http 요청시 동작방식(GPT 참고)HTTP 요청 → DispatcherServlet클라이언트가 /foo 같은 URL로 요청을 보내면..
Postgrsql에서 라인 포인터의 역할
DB에서 데이터는 책의 페이지처럼 쪽으로 나눠져서 관리되고 있다.그래서 데이터를 저장할때는 페이지마다 저장되고 있으며 페이지에서는 레코드(로우)들로 저장되며 해당 페이지 상단에는 레코드마다 위치를 가리키는 라인포인터 영역이 있다. 쉽게 이야기하면 페이지 마다 상단에 헤더영역이 있는데 그중에 라인포인터는 데이터의 위치를 가리켜서 데이터를 조회하거나 입력할때 사용된다. 데이터가 입력되면 페이지의 빈공간에서 하단에서 상단으로 채워진다.만약 데이터가 삭제되면 라인포인터는 해당 로우에 대한 데이터가 비어있다고 저장하며 추후 재사용된다.
Oracle, Postgresql, Mysql(InnoDB)
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 ..