해결된 질문
작성
·
175
·
수정됨
1
학습 관련 질문을 최대한 상세히 남겨주세요!
고민 과정도 같이 나열해주셔도 좋습니다.
먼저 유사한 질문이 있었는지 검색해보세요.
인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.
너무너무 흥미진진하게 보고 있었는데, 이 내용이 꼭 좀 있으면 좋겠습니다...!ㅠ
테이블을 분리한다면 테이블의 명칭은 각각 어떻게 네이밍 되는지.. 게시글이 1년 단위로 테이블이 분리된다고 했을떄, 테이블을 동적으로 생성하는 어떤 전략이 있는지.. (아니면 직접 1년 지날때마나 만드는 것인지) 등등.. 사소한 것부터 궁금한 것이 너무 많아서요...!
답변 1
3
흰머리오목눈이님, 안녕하세요!
앗, 해당 부분에 대해서 추가로 강의를 만들 계획 예정은 없습니다..!
다음 강의로는, "분산 데이터베이스 환경에서 데이터 모델 설계 전략"을 주제로 준비하고 있는데, 약간 결이 다르네요..
예시로 든 전략이 학습에 대한 궁금증을 자극했나보네요!
간단히 설명하고 넘어가서 당연히 아쉬울 수 있는거라, 아주 좋은 고민입니다.
일단 실무에 들어가면 정형화된 정답은 없고,
현 상황에서 최선이라고 팀 내 합의되고 문제될 요소가 안보인다면,
대체로 그걸 정답으로 채택하는 경우가 많습니다.
그리고 그것이 꼭 모든게 자동화되고 멋있어보이는 해결책은 아닐 수 있습니다.
또, 과거에는 최선이었더라도, 요구사항이나 상황이 변하면서 더 나은 해결책이 나올 수 있습니다.
그래서 아래 설명하는 내용은 예시일 뿐이고, 실제 이렇게 사용하기도 하나, 이것이 정형화된 정답은 아닙니다.
상황에 따라 다양한 방법이 가능하다는 점은 참고 부탁드립니다.
조금 구체화해서 예시를 드려보겠습니다.
만약 1년 단위로 분리한다면, 테이블 명칭은 my_table_yyyy(my_table_2025/my_table_2026) 이런 식으로 취할 수 있습니다.
1년 단위로 테이블 동적 생성하는 전략은, 어차피 연단위로 하기 때문에 담당자를 지정하여 수동으로 하는 것도 큰 비용은 없을 수 있습니다.
하지만 이러한 전략을 여러 테이블에 다 적용한다면 이 또한 큰 비용이 될 수 있기 때문에, 당연히 자동화도 고려해볼 수 있습니다. (따로 스크립트를 만들어서 연단위로 DDL을 수행할 수도 있고, 애플리케이션 코드에서 테이블이 없으면 생성하도록 DDL을 전송할 수도 있고, 방법은 다양하기 때문에 편한걸로 선택할 수 있습니다.)
아니면 차라리, 테이블 만들 때마다 미리 N년치 테이블을 당장 다 만들어둘 수도 있습니다. 이것도 N년치 테이블 DDL 생성하는 스크립트를 하나 만들어둘 수 있겠네요. (상황이 복잡해지기 전까지는, 저는 그냥 이게 제일 편할 것 같습니다.)
테이블은 연단위로 분리되기 때문에, 이러한 "연도 값" 또한 샤드 키로 활용할 수 있습니다.
따라서 각 테이블은 "연도 값"에 의해 여러 물리 샤드로 추가 분산할 수도 있고, 안할 수도 있습니다.
연도별 테이블을 단일 샤드에서만 분리해둘지, 아니면 실제 물리 저장소 분산 효과를 위해 여러 샤드로 분리해둘지에 대한 결정도 필요하다는 의미입니다.
전자라면, 단순히 게시글의 생성일자에서 연도 값만 뽑아내서 특정 테이블로 라우팅 해주면 됩니다.
하지만 후자라면, 연도 값을 기준으로 샤드를 찾아야하므로 훨씬 복잡해질 수 있습니다. 현재 연도를 기준으로 샤드를 결정하는 방법도 필요해지기 때문입니다.
연도별로 테이블을 분리하는 상황에는 새로운 쿼리 전략이 필요할 수도 있습니다.
예시로, articleId로 게시글을 조회하고 싶다고 해보겠습니다.
하지만 articleId만으로는 이 게시글이 어떤 연도별 테이블에 들어가있는지 모르는 상황입니다.
이를 해결하려면 articleId -> 연도 매핑 데이터를 따로 저장해두고 테이블에 찾아가는 과정이 필요합니다.
즉, 데이터의 분산 효과를 높이면서 놓쳐진 쿼리 요구사항을 만족하기 위해,
인덱스 데이터를 직접 만들어둘 수도 있는건데요,
이건 제 다음 강의에서 준비중인 내용과 연관되기도 하네요!
테이블 분산까지 데이터베이스 자체에서 지원하는 경우는 드물기 때문에, 직접 구축이 필요할 수 있습니다.
이를 위한건 스프링부트 애플리케이션에서 간단히 만들어볼 수도 있습니다.
게시글 생성/수정/삭제 - 게시글의 createdAt에서 연도를 뽑아내고, 이를 통해 어떤 테이블(및 샤드)에 데이터가 있는지 확인하여 쿼리 전송
게시글 조회 - articleId -> createdAt 매핑 데이터를 통해서 연도를 추출하여 데이터가 위치한 테이블을 확인하고, 게시글 테이블에서 데이터 조회
게시글 목록 조회(최신순) - 올해 연도 테이블에서 N번 페이지 조회하고, 계속 페이징 수행함. 연도별 테이블마다 게시글 개수를 관리하고 있는 상황(안전하게 만드는 방법은 좋아요 강의에서 살펴봄). offset이 해당 연도 테이블의 게시글 개수를 넘는다면, 해당 연도 테이블은 즉시 스킵하고, 다음 연도 테이블 살펴본다.
위 예시에 대해 더욱 구체화해보았는데, 궁금증이 많이 해소되었기를 바랍니다!
혹시 더 궁금한 점 있으시면 편히 문의 주세요!