차근차근 기록장

[DB] Sharding

대용량 트래픽을 처리하는 개발자라면 고려해 볼 DB Sharding 에 대해 정리하고자 한다. 1. 개념- 데이터를 논리적으로 나누는 작업으로, 각 분할된 데이터는 독립적으로 관리됨 2. 장점- 성능 향상  > 읽기 및 쓰기 작업이 여러 샤드로 분산되어 병렬 처리 가능- 확장성  > 필요에 따라 샤드와 서버를 추가하여 수평적 확장 가능- 고가용성  > 특정 샤드에 장애가 발생해도 나머지 샤드가 동작 유지 가능 3. 단점- 운영 복잡성- 쿼리 복잡성  > 분산된 샤드에 걸친 데이터를 조회하기 위해 추가 로직(ex. 애플리케이션에서 집계 쿼리) 필요- 데이터 재분배 비용  > 샤드 키가 잘못 설계되었거나 데이터 불균형 시 샤드 간 데이터 재분배가 필요한데 이는 많은 자원과 시간 소모 4. 기타- 적절한 키 ..

생각을 많이 하여 GROUP BY 개념을 사용하게 되는 케이스가 생겨 정리에 대한 필요성이 생겨 포스팅하고자 한다. > 어느 회사에서, 개인별로 자신과 동일한 부서에 일하는 직원 수가 몇 명인지 조회하는 쿼리가 필요하다. EMPLOYEES 테이블에서 ID, 이름(NAME), 부서(DEPARTMENT) 정보가 주어질 때 쿼리를 작성해보자. > SELECT e.ID, e.NAME, COUNT(c.ID) AS COUNT_COWORKER FROM EMPLOYEES e JOIN EMPLOYEES c ON e.DEPARTMENT = c.DEPARTMENT AND e.ID c.ID GROUP BY e.ID, e.NAME ORDER BY e.ID ASC ; 즉, 자체 테이블을 자가 결합하는 방법을 사용한다.

기존 회사에선 Oracle 을 사용하다가, 최근에 이직한 회사에서 MySQL 을 사용하며 새로운 점들을 익히고 있다. 그러던 와중에 JSON Type 의 데이터를 파싱 등의 처리하는 작업을 맡게 되어 진행하게 되었다. 그 중 기록해 두었다가 추후에 계속 활용할 수 있도록 하기 위해 포스팅을 하려고 한다. -- 자세한 내용은 다음과 같다. -- JSON Type 의 데이터가 [{"id": 1, "item": "apple"}, {"id": 2, "item": "grape"} ... ] 등의 형태로 되어 있다고 가정한다. 이 때 아래와 같이 테이블 형태를 변경하고자 한다. (As-Is) fruit_no fruit_items ------------------------------------------------..

* 순환 관계 모델 - 한 테이블 내 레코드끼리 관계를 갖는 데이터 모델 - 순환 관계 테이블은 셀프 조인을 통해 부모 노드나 자식 노드를 조회할 수 있음 * 계층 쿼리 - START WITH 절과 CONNECT BY 절로 구성됨 WHERE 절 다음에 기술하지만, 실제 실행 순서는 WHERE 절보다 앞섬 START WITH 조건을 만족하는 데이터를 시작으로 CONNECT BY 조건을 만족하는 데이터를 찾은 후 최종적으로 WHERE 조건으로 필터링함 - START WITH 절은 생략 가능함 / PRIOR 연산자는 직전 상위 노드의 값을 반환함 - CONNECT BY 절의 조건은 계층 전개 시 평가되므로 선택되는 하위 노드에 영향을 미침 - CTE (Common Table Expression) 은 WITH ..

* 카티션 곱: - 조인 조건이 누락되면 카티션 곱 집합이 생성됨 - 의도적으로 카티션 곱 집합을 만들기도 하지만, 실수로 조인 조건을 누락하는 경우도 있으므로 주의 필요 * INNER JOIN 절 - ON 절에 조인 조건을 기술하며, 일반 조건은 WHERE 절에 기술할 수 있음 조인 조건과 일반 조건을 분리하여 가독성을 향상시킬 수 있음 * NATURAL JOIN 절 - 이름이 같은 열로 테이블을 등가 조인함 * USING 절 - [USING 절에 지정한 칼럼 기준]으로 테이블을 등가 조인 함 - 지정한 열을 조인할 테이블에 동일한 이름으로 존재해야 함 - USING 절에 지정한 칼럼을 ALIAS 등으로 한정할 수 없음 - USING 절의 열 부분은 식별자를 가질 수 없음 * OUTER JOIN 절 -..

* 관계를 고려한 트랜잭션 구현 1) 자식 테이블 기준으로 부모 테이블이 필수 관계라면, 부모 레코드를 먼저 입력해야 함 자식 레코드 입력시, 외래 키에 부모의 식별자 값을 반드시 입력해야 하기 때문 2) 부모 엔터티 기준으로 자식 엔터티도 필수 관계라면, 부모와 자식 레코드 입력을 한 트랜잭션으로 묶어서 처리해야 함 부모 레코드 입력은 성공했는데 자식 레코드 입력은 실패하면 안 되기 때문 3) 부모 레코드와 함께 첫번째 자식 레코드를 입력한 이후, 두 번째 자식 레코드부터는 개별적으로 입력할 수도 있는데 이는 업무적인 트랜잭션 정의에 의해 결정됨 > 여러 행을 읽어 값을 집계할 때는 NULL값을 연산 대상에서 제외함 > 식별자: 엔터티에서 데이터를 유일하게 식별할 수 있는 속성 (식별자를 통해 엔터티의..

# SQLD 시험에 나오는 내용을 정리해나가려고 한다. 1. 모델링의 3대 특징: 단순화, 명확화, 추상화 * 모델: 일정한 표기법에 따라 표현한 모형, 축소형 * 모델링: 모델을 만들어가는 일 자체 2. 데이터 모델 유형 1) 개념: 추상화 수준이 제일 높고 업무 중심적이고 포괄적인 수준의 모델링 * 주로 핵심 엔터티와 그들간의 관계를 정의함 2) 논리: 업무에 대한 키, 속성, 관계 등을 정확하게 표현 * 업무에 필요한 모든 엔터티와 속성, 관계를 도출함 3) 물리: 데이터베이스 이식을 위해 성능, 저장 등 물리 요소를 고려하여 설계 3. 엔터티: 인스턴스의 집합 - 변별할 수 있는 사물 - 데이터베이스 내에서 변별 가능한 객체 - 정보를 저장할 수 있는 어떤 것 * 속성: 각 인스턴스의 성격을 구체..