게시글-파일 테이블을 설계하는 과정에 고민했던 부분이 많아 기록으로 남기게 되었습니다.우선 설계를 하기 앞서, 요구사항에 대한 2개의 기본적인 전제를 밝힙니다. 1) 하나의 게시글에 여러 개의 파일을 등록할 수 있다.- 일반적으로 요구되는 사항으로, 만약 하나의 파일만 등록하는 요구사항이라고 하더라도 이후에 쉽게 확장될 수 있는 요구사항입니다. 2) 하나의 파일 테이블로 파일들을 모두 관리한다.- 구체적인 예시는 다음과 같습니다.'자유 게시판, 비밀 게시판, 홍보 게시판 ...' , '공지사항, 일대일 문의' 와 같이 여러 게시판이 있는 경우가 있습니다.각 게시판의 성격에 따라 스키마가 달라져 이를 각각의 게시판 테이블로 설계를 해야되는 경우가 있지만, 파일의 경우는 정의되는 스키마가 동일해 하나의 파..

view 테이블을 활용한 업무 중 문득 아래와 같은 의문이 들었다. 가정. view 쿼리 결과가 1000만 건일 경우1) view 쿼리가 실행될 때 where 절도 함께 실행되어 단일 쿼리처럼 동작할까?2) 1000만 건을 모두 조회한 후 where 절이 추가로 실행될까? 1번처럼 동작한다면 문제가 없겠지만, 2번처럼 동작한다면 조회 시 바라생하는 비용이 클 것이고, view를 사용하기 위한 명확한 이유가 필요할 것이다. 그럼 아래에서 이 문제에 대해 "view는 어떤 식으로 동작하는지?"와 "view를 사용하는 것이 정말 효율적인지?"에 대한 답을 찾아보며, "나는 view를 올바르게 사용하고 있을까?"에 대해서 생각해보는 시간을 가져보자.  우선 MySQL에서 뷰를 생성할 때 사용할 수 있는 `ME..

파티셔닝을 적용할 때, 가장 중요한 점이 필요한 파티션만 적절히 접근할 수 있어야 한다.이를 위해서 파티션 표현식을 잘 세워야 한다. 이번 포스트에서는 DATE / DATETIME 필드를 사용해서 월별로 파티셔닝을 진행할 때, 쿼리 실행 계획을 분석하여 파티션 프루닝이 정상적으로 잘 동작하는지 테스트하고 가장 적합한 파티션 표현식이 무엇인지 찾아보는 과정을 담았다.  1. PARTITION BY RANGE (year(GATH_DTM) * 100 + month(GATH_DTM))파티션 프루닝 테스트단건 조회는 파티션 프루닝이 잘 동작하나, 범위 조회는 파티션 프루닝이 전혀 동작하지 않으며 모든 파티션을 스캔하고 있다. 왜 안 될까?위 표현식을 통해서 파티션 생성은 잘 되는 것은 확인했지만, 전체 파티션을 ..

1. 파티션을 사용하는 이유1) 하나의 테이블이 너무 커서 인덱스의 크기가 물리적인 메모리보다 훨씬 큰 경우 (=  큰 테이블을 작은 크기의 파티션으로 분리)- 테이블의 데이터가 MySQL의 물리 메모리보다 큰 것이 일반적이지만, 인덱스의 Working Set이 실질적인 물리 메모리보다 크면 쿼리 처리가 현저히 떨어지게 된다. 파티셔닝을 통해 여러 작은 파티션으로 나누면. 각 파티션에 대한 로컬 인덱스로 인덱스 크기를 줄일 수 있어 인덱스 탐색 속도가 빨라지게 된다. 2) 필요한 파티션만 접근하는 경우(read & write)- 전체 테이블을 스캔하지 않고 특정 파티션을 read / write 하는 것이 훨씬 빠르고 효율적이다.예를 들어 로그와 같은 이력 데이터들에 대한 주기적인 삭제 작업이 필요하거나 ..

인턴 중 데이터 수집 테이블의 '월별 파티셔닝 자동화 프로시저' 개발 업무를 담당하게 됐다.파티션을 하는 작업이 처음이기도 하였고, 프로시저를 작성하는 문법이 달라 관련해서 래퍼런스를 찾아보던 중 "현재 기업의 운영 환경에 적용된 파티셔닝과 현업에서 일반적으로 사용하는 파티셔닝" 개념에 차이가 있다는 것을 알게 되었다. 간단히 MySQL에서 지원하는 파티셔닝은 1개의 논리테이블에서 N개의 물리테이블을 갖도록 하는 기능이다. 하지만 현재 업무에서 적용하고 있는 파티셔닝은 "N개의 논리테이블에서 각자 1개의 물리테이블을 갖도록 설계됐었다. 이는 아래와 같이 각 월별로 테이블이 관리하도록 되었는데, 시간이 흐를수록 테이블이 늘어나 데이터베이스를 관리하기 매우 불편한 설계가 됐다. 그래도 일단은 기존의 플로우대..

기존 데이터베이스 테이블에 있는 데이터를 활용한 테스트를 진행하고자, 테이블 복사에 대한 방법을 찾아보고 정리했다.  1. 테이블 구조 복사기존 테이블의 생성 구문을 확인한다.SHOW CREATE TABLE existing_table;  2. 새 테이블 생성위에서 확인한 생성 구문에서 테이블명만 바꾸고 실행한다.  3. 데이터 복사INSERT INTO new_table SELECT * FROM existing_table;   번외.테이블 복사에 관해 찾아보던 중, 평소 즐겨보던 블로그에서 `LIKE`를 활용한 테이블 구조 복사는 'PK', 'Auto increment'와 같은 설정은 복사할 수 없다는 글을 보게 되었다. "왜 `LIKE`는 위 설정을 복사할 수 없을까?" 하는 물음에 `LIKE`에 대한 ..