상관 서브 쿼리(Correlated subquery) 서브쿼리 외부에서 정의된 테이블 칼럼을 참조해서 수행하는 쿼리 상관 서브 쿼리는 독립적으로 실행되지 못하고, 항상 외부 쿼리가 실행된 후 서브쿼리가 실행된다. 일반적으로 상관 서브 쿼리를 포함하는 비교 조건은 범위 제한 조건이 아니라 체크 조건으로 사용된다 독립 서브 쿼리(Self-Contained subquery) 외부 쿼리의 칼럼을 사용하지 않고, 서브 쿼리에서 정의된 칼럼만 참조 외부의 쿼리와 상관없이 항상 같은 결과를 반환함으로 외부 쿼리보다 먼저 실행되어 외부 쿼리 검색을 위한 상수로 사용되는 것이 일반적 서브 쿼리의 제약사항 FROM절에는 상관 서브 쿼리 형태로 사용할 수 없다. 사용할 경우 Unknown column 에러 발생 서브 쿼리를 이용해 하나의 테이블에 대해 읽고 쓰기를 동시에 할 수 없다. SELCET 절에 사용

인덱스란? 인덱스는 지정한 컬럼들을 기준으로 메모리 영역에 일종의 목차를 생성하는 것이다. 삽입,삭제,갱신의 성능을 희생하고 조회의 성능을 향상시킨다. 인덱스 종류에 따라 물리적인 공간을 요구하며, 옵티마이저는 생성한 인덱스 중 어느 인덱스를 선택해야 하는지에 대한 계산비용도 들어가게 된다. 인덱스를 통해 읽는 레코드 한건 한건이 I/O다. 때문에 인덱스를 통해 읽어야 할 데이터 레코드가 20~25%를 넘으면 인덱스보다 테이블 데이터를 직접 읽는 것이 효율적이다. > 단 갱신과 삭제를 하기위한 레코드를 찾는데는 빠르다. 때문에 인덱스가 있는 컬럼을 기준으로 갱신과 삭제를 하는것이 좋다 자료구조 인덱스의 자료구조는 SortedList로 저장되는 값을 항상 정렬된 상태로 유지한다. 정렬되어 있음으로 SELECT 쿼리 속도가 빠르나, INSERT, UPDATE, DELETE 쿼리는 정렬을 해야하기 때문에 쿼리 수행시간이 늘어난다. 인덱스 컬럼 주의사항

Transaction Transaction 이란 DB의 상태를 변환시키는 하나의 논리적인 작업 단위를 구성하는 연산들의 집합이다. 예를 들어, A계좌에서 B계좌로 일정 금액을 이체한다고 가정하자. 이러한 과정은 다음과 같다 ​ a. A계좌의 잔액 확인 ​ b. A계좌의 금액에서 이체할 금액을 빼고 다시 저장 ​ c. B계좌의 잔액을 확인 ​ d. B계좌의 금액에서 이체할 금액을 더하고 다시 저장 a~d의 과정들은 모두 합쳐저 계좌이체라는 하나의 작업단위(트랜잭션)을 구성, 트랜잭션은 항상 all or nothing 원칙을 만족해야 한다. 즉 완료를 하던가(commit) 다시 원래의 상태로 돌아가던가(rollback) 둘중 하나는 만족해야 한다. 절대 partoally Done 형태로 끝나서는 안된다. 트랜잭션의 성질(ACID) **Atomicity(원자성) ,

Partitioning 이번에 D2 Fest mini 프로젝트를 진행하면서, 대용량 아키텍처에 대해 처음으로 생각해보게 되었다. 서비스가 사용자가 많아지고 관리해야 될 데이터의 양이 많아 질 수록, 개발자는 보다 많은 짐을 얻게 된다. 어느 정도 몸짓이 커지면 어플리케이션단을 넘어서, 시스템 아키텍처를 고민하고 설계해야한다. 학부생때야 직접 서비스를 운영(그것도 아주 잘 나가는 서비스)해보지 않고서는 이런 고민을 할 일이 없다. 때문에 이번 공모전을 계기로 대용량 아키텍처를 공부하고 관련 내용을 기록으로 남겨보고자 한다. 개인적으로 회원 테이블에 대해, 휴면계정과 활성계정으로 파티셔닝을 적용해보면 하는 생각이 들었다. > 휴면계정과 활성계정은 서로 간의 전환이 필요하다. 파티셔닝은 각 파티션 사이에 서로 이동이 없는 경우에 적합하다. 아래의 내용은 Mysql 기준이다. Partitioning 이란 **VLDB(Very Large DBM

Database 선택 가이드 이번 포스팅에서는 RDB 부터 여러 DB들의 강점과 약점을 알아보고, 어떠한 경우에 각 DB들을 적용하면 좋을지 정리해 보자. RDB (Relation Database) 관계형 데이터베이스로, 가장 오래되고 많이 알려져있다. Mysql, Oracle, PostgreSql등이 속해 있다. 여기서 관계(Relation)란 key와 value의 관계를 말하며 RDB에서는 이러한 관계들을 Shcema를 가지는 Table로 표현하여. 데이터들은 이 Schema를 통해 여러 개의 테이블에 분산되어진다. RDB는 아래와 같은 특징을 가진다. 강점 데이터 타입과 Constraint를 통해 데이터 무결성을 보장함으로 데이터 품질을 향샹시킴 정형화된 데이터 처리에 적합하며 ACID 트랜잭션을 지원한다. 대부분의 생태계를 장악하고 있어, 엔진 지원 및 참고 자료들이 풍부하다. 정규화, 튜닝등 성능향샹을