콩콩이의 블로그

1. 테이블과 인덱스가 디스크에 어떻게 저장되는지테이블은 행기반 / 열기반에 따라 저장 형태가 달라짐(행기반일 경우) 각 행별로 저장되며 페이지 단위로 저장됨-> 읽어올 때 한 행만 읽어오는 것이 아닌, 페이지 단위로 읽어온다페이지들은 '힙'이라는 자료구조에 저장되는데, 여기에 접근해서 데이터를 읽어오는 것은 큰 비용이 드는 일임-> 인덱스를 사용하면 비용을 줄일 수 있음- 인덱스 : 힙을 가리키는 포인터를 모아둔 자료구조 2. 행 기반 vs 열 기반 데이터베이스행 기반 데이터베이스열 기반 데이터 베이스읽기/쓰기에 최적화쓰기가 느림OLTP ( '운영'계 데이터 처리)OLAP ( '분석'계 데이터 처리)압축에 유용하지 않음압축에 좋음집계에 유용하지 않음집계에 좋음다중 컬럼에 유용한 쿼리다중 컬럼에 비효율적..

Durabiltity지속성은 고객이 데이터베이스에 만든 권한을 비휘발성 시스템 저장소에 지속시키는 과정입니다. 하지만 지속성을 위해서는 디스크에 저장해야 하므로 '느리다'고 말하곤 합니다.그래서 Postgre 데이터베이스는 메모리에 저장한 후 스냅샷을 찍어 디스크에 백업하므로 '빠르다'라는 점을 강조하기도 합니다. 다시 돌아와, 커밋된 트랜잭션에 의해 변경된 것들은 SSD, 하드드라이브같은 비휘발성 저장소에 저장되어야 합니다.지속성을 보장하기 위해서는 어떤 과정을 거칠까요? 디스크에 실제로 기록하고 지속성을 갖기 위해서는 시간이 걸리기 때문에 사용되는 몇가지 기술이 있습니다. 1. WAL그래서 데이터베이스에서는 변경 사항의 버전인 '델타'만 적용합니다.그리고 쓰기 전용 로그인 write ahead log..

Consistency일관성이란, 실제로 디스크에 있는 것과 데이터 모델이 일치해야한다는 원칙입니다.데이터가 디스크에서 일관성을 유지할 수 있지만, 데이터의 읽기는 여러 인스턴스가 동기화되지 않아 일관성이 없어질 수 있습니다. 참조무결성에 의한 불일치가 발생할 수 있습니다.예를 들어, 다음과 같은 데이터베이스가 있습니다.PICTURE_ID  (PK)BLOBLIKES1xx52xx1USER (PK)PICTURE_ID (PK) (FK)Jon1Edmond1Jon2Edmond4 1번 사진에 대한 좋아요는 5개이지만, 실제 2명의 유저만 좋아요를 누른 상태입니다.이는 좋아요를 눌렀다 취소하는 이벤트를 LIKES에 반영하지 않아 일관성이 깨진 경우입니다. 또한, Edmond는 4번 사진에 좋아요를 누른 기록이 있지만,..

Atomicity원자성이란, 한 트랜잭션의 모든 쿼리는 성공해야 한다는 원칙입니다.즉 한 트랜잭션이 데이터베이스의 작업 단위이며, 분할될 수 없습니다.모종의 원인으로 실패한 쿼리가 있을 경우 해당 트랜잭션은 롤백되어야 합니다.만약 데이터 베이스가 다운되어 롤백할 수 없다면,데이터베이스가 다시 실행된 후 쿼리들이 성공했더라도 실패했다고 인지해야 합니다.해당 트랜잭션이 최종적으로 커밋되지 않았기 때문입니다.하지만 이러한 처리 방식은 데이터베이스의 종류에 따라 다릅니다. 예를들어, 다음과 같은 장부가 있습니다. ACCOUNT_IDBALANCE1$10002$500 Account 1에서 Account 2로 100$를 보낸다면 1. Account 1에서 -$1002. Account 2에서 +$100두 개의 쿼리가 ..

Isolation 고립성고립성은 동시에 발생하는 다른 트랜잭션과 완전히 고립된 상태에서 트랜잭션이 실행되는 결과입니다. 현재 진행 중인 내 트랜잭션이 다른 진행 중인 트랜잭션에서 발생한 변경 사항을 볼 수 있을까요?정답는 상황에 따라 다르다! 입니다.그래서 다양한 읽기 현상에 대해서 알아야 하는데요,  디버깅하기 어렵게 만드는 읽기 현상들을 해결하기 위한 고립수준까지 이어서 알아보겠습니다. Read Phenomena 읽기 현상들1. Dirty reads 더티 읽기다른 트랜잭션이 쓴 내용을 읽지만 실제로는 아직 커밋되지 않은 것을 읽는 현상트랜잭션 1트랜잭션 2상품 1의 판매량 15를 읽어옴  상품 1의 판매량에 5를 더해 20을 만듦판매량 20에 가격 10을 곱해 매출을 계산 커밋롤백=> 원래 매출 집계..