CS/DB

개념Isolation Level 은 데이터베이스의 트랜잭션 격리 수준을 얘기합니다.이는 여러 트랜잭션이 동시에 실행되고 있을 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나, 조회하는 데이터를 볼 수 있게 허용하는 여부를 결정하는 것입니다.Serializable가장 엄격한 격리 수준입니다. 이름 그대로 트랜잭션을 순차적으로 진행시킵니다.여러 트랜잭션이 동시에 진행 될 일이 없어서 데이터 부정합 문제가 발생되지 않지만, 트랜잭션을 순차적으로 진행하기 때문에 동시 처리 속도가 현저히 떨어지게 됩니다.Repeatable ReadRepeatable Read 는 언두 로그를 활용하는 트랜잭션 격리 수준입니다.📢 언두 로그가 뭘까요?일반적인 RDBMS 는 변경 전의 레코드를 언두 공간에다가 백업합니다. 이렇게 되..

특정 오프셋 까지 데이터를 모두 조회하고 버린다.오프셋의 동작 방식은 0번 오프셋 부터 지정된 오프셋까지 데이터 조회를 모두 수행합니다.그래서 Disk 인풋, 아웃풋이 오프셋 만큼 일어나게 되어 O(n)의 선형적인 구조를 띄어 느립니다.스트리밍 처리가 아닌 버퍼링 처리를 거칩니다. (완벽한 이유는 아님)쿼리문에 ORDER BY 나 GROUP BY 를 추가되면 버퍼링 방식으로 처리가 됩니다.왜냐하면 결과를 모아두고 정렬 및 그룹핑을 해야하기 때문입니다.개선할 수 있는 방법이 존재합니다.Index Sort 이용하기정렬 조건을 제한하고, 정렬 조건에 따른 인덱스를 생성하여 FileSort 를 사용하지 않게 합니다.

깃허브를 돌아다니다 보면 PK로 Auto Increment 나 UUID 를 사용하는 것을 자주 볼 수 있다. Auto increment를 사용하여 HTTP Method 의 인자로 사용하면 어떤 문제가 일어날 수 있을까? Auto increment - 예측 가능한 모델이 된다.Auto increment 로 생성 된 PK를 URL 같은 공개된 장소에 노출시키면이는 데이터 크롤링이나 인젝션 공격에 조금 더 취약해질 수 있게 된다. 그래서Public 공간 - 예측 불가능하고 Random 한 Index 체계 사용Private 공간 - Auto Increment PK 값으로 데이터 접근으로 하는 것이 적절하다. 그러면 오케이 !! UUID 로 값 조회하면 되겠다! 하는데 일반적인 방법으로 UUID 를 조회 기준으로..

관계데이터베이스에 테이블은 하나만 있는 것이 아니다. 여러 개의 테이블이 있고 이러한 테이블은 서로의 관계가 정의되어 있다. 이러한 관계를 관계화살표로 나타낸다.1:1 관계예를 들어 유저당 유저 이메일은 한 개씩 있다고 가정하면 이 경우 1:1 관계가 된다.1:1 관계는 테이블을 두 개의 테이블로 나눠 테이블의 구조를 더 이해하기 쉽게 만들어 준다.1:N 관계예를 들어 쇼핑물을 운영한다고 가정했을때, 한 유저당 여러 개의 상품을 장바구니에 넣을 수 있겠지? 이 경우 1:N 관계가 된다. 물론 하나도 넣지 않는 0개의 경우도 있으니 0도 포함되는 화살표를 통해 표현해야 한다.이렇게 한 개체가 다른 많은 개체를 포함하는 관계를 말한다.N:M 관계학생과 강의의 관계를 정의하면 어떻게 될까? 학생도 강의를 많이..

필드와 레코드앞에서 설명한 것들을 기반으로 데이터베이스에서 필드와 레코드로 구성된 테이블을 만들 수 있다.회원이란 엔티티는 member 라는 테이블로 속성인 이름, 아이디 등을 가지고 있으며 name, ID, address 등의 필드를 가진다. 그리고 이 테이블에 쌓이는 행(row) 단위의 데이터를 레코드라고 한다. 또한 레코드를 튜플이라고도 한다행 = 레코드 = 튜플예를 들어 ‘책’이나는 엔티티를 정의하고 이를 기반으로 테이블을 만들어본다.어떠한 속성이 있을까?제목저자의 아이디출판년도장르생성 일시업데이트 일시등이 있다.이를 데이터베이스에 넣어 테이블로 만들면 어떻게 해야할까?우선 타입을 정의해야 한다. MySQL 기준으로 설명책의 아이디: INT책의 제목: VARCHAR(255)책의 저자 아이디: IN..

도메인의 개념도메인(domain) 은 릴레이션에 포함된 각각의 속성들이 가질 수 있는 값의 집합을 말한다.예를 들어 성별이라는 속성이 있다면 가질 수 있는 값은 [남, 여] 라는 집합이 된다. 앞의 그림처럼 회원이라는 릴레이션에 이름, 아이디, 성별이라는 속성이 있고 성별은 [남, 여] 라는 도메인을 가질 수 있다.

속성의 개념속성(attribute)는 릴레이션에서 관리하는 구체적이며 고유한 이름을 갖는 정보다.예를 들어 ‘차’라는 엔티티가 있을 때 속성을 뽑아보자.차 번호, 바퀴 수, 차 색깔, 차종 등이 있다.이 중에서 서비스 요구 사항을 기반으로 관리해야 할 필요가 있는 속성들만 엔티티의 속성이 된다. 밑과 같이 식물이 있다면 다음과 같이 속성을 정의 할 수 있다

릴레이션 개념릴레이션(relation)은 데이터베이스에서 정보를 구분하여 저장하는 기본 단위다.엔티티에 관한 데이터를 데이터베이스는 릴레이션 하나에 담아서 관리한다. 릴레이션은 관계형 데이터베이스에서 ‘테이블’ 이라고 하며NoSQL 데이터베이스에서는 ‘컬렉션’이라고 한다. 테이블과 컬렉션데이터베이스의 종류는 크게 관계형 데이터베이스와 NoSQL 데이터베이스로 나눌 수 있다.이 중 대표적인 관계형 데이터베이스인 MySQL 과 대표적인 NoSQL 데이터베이스인 MongoDB를 예로 들면MySQL: 레코드 - 테이블 - 데이터베이스MongoDB: 도큐먼트 - 컬렉션 - 데이터베이스로 이루어져있다. 레코드가 쌓여서 테이블이 되고 테이블이 쌓여서 데이터베이스가 되는 것이다.

엔티티의 개념엔티티는 사람, 장소, 물건, 사건, 개념 등 여러 개의 속성을 지닌 명사를 의미한다.예를 들어 회원이라는 엔티티가 있다고 했을 때, 회원은 이름, 아이디, 주소, 전화번호등의 속성을 가질 수 있다. 물론 이보다 많은 속성이 있지만, 서비스의 요구사항마다 달라지는 거니까 .. ㅎㅎ예를 들어 주소라는 속성이 서비스의 요구 사항과 무관한 속성이라면 주소라는 속성은 없애는 게 맞다. 약한 엔티티와 강한 엔티티엔티티는 약한 엔티티와 강한 엔티티라는 개념이 있다.예를 들어 A 와 B가 있을 때 A가 혼자서는 존재하지 못하고 B의 존재 여부에 따라 종속적이라면 A는 약한 엔티티고 B는 강한 엔티티가 된다.예를 들어 방은 건물 안에만 존재하기 때문에 방은 약한 엔티티 건물은 강한 엔티티라고 할 수 있다.