불필요한 연산 VS 불필요한 저장

불필요한 연산 VS 불필요한 저장

오늘 페이지를 짜다가 사소한것이지만, 논의를 하였다. ( https://s3-file-url/ idea/images/1000001/. 파일이름.jpg )

1. idea/images/1000001/파일이름.jpg (DB에 저장 => URL + DB저장한 데이터)

vs 

2. 파일이름.jpg (DB에 저장 => URL + idea/image/ + id + DB저장한 데이터)

토의 였다. 현재 로직에서는 아래 처럼 구성되어 있고 여기서 파싱하는 작업을 어떻게 할것인가에 대한 논의 였다.

    @Override
    public Optional<IdeaOneResponse> findIdeaOne(Long ideaId) {
        return Optional.ofNullable(queryFactory.select(Projections.constructor(IdeaOneResponse.class,
                        qUsers.nickname.as("writer"),
                        qIdea.title,
                        qIdea.content,
                        qIdea.imageName.concat(ServerIpAddress.s3Address).as("imageUrl"),
                        qIdea.auctionStatus.as("status"),
                        qIdea.minimumStartingPrice,
                        qIdea.bidWinPrice,
                        qIdea.category,
                        qIdea.auctionStartTime
                ))
                .where(qIdea.id.eq(ideaId))
                .from(qIdea)
                .innerJoin(qIdea.users, qUsers)
                .fetchOne());
    }

일단 제 의견은 저장할때 1번 생각이였다. 조회할때 불필요한 연산을 하는것보다 저장할때

idea/images/1000001/. 파일이름1.jpg

idea/images/1000001/. 파일이름2.jpg

idea/images/1000001/. 파일이름3.jpg

이런식으로 저장하는게 좋다고 생각하였다. 왜냐하면 S3 주소가 변경되어도 백업 해둔것을 이미지 파일들을 전부 다시 넣어놓으면 똑같은 파일구조를 가진 도메인 URL을 가지고 있기 때문이다. 

 

다른분 의견은 2번 생각이였다. 불필요한 저장을 하게 되면 중복 되는 텍스트가 너무 많이 들어간다. 몇글자 추가해서 나중에는 1 -> 10 -> 100 -> 1000 이렇게 늘어 날텐데 불필요하고 데이터 양이 커지니 가져올때도 메모리 쓰지 않느냐 라는 의견이였다.

 

아직 경험이 부족하여 어떠한것이 옳다고 생각을 할수 없다. 하지만 무언가 뿌듯하였다 히히

아래는 Chat-GPT 를 통해 답변을 받아보았고 그 외의 자료도 첨부하겠다.

 

Chat-GPT 답변

1. "idea/images/1000001/파일이름.jpg" (DB에 저장 => URL + DB에 저장한 데이터)
   • 장점:
     • 경로 정보를 함께 저장하므로 파일을 검색하거나 관리할 때 유용합니다.
     • 데이터베이스에 저장된 경로 정보를 기반으로 파일을 쉽게 찾을 수 있습니다.
   • 단점:
     • 중복된 경로 정보가 포함되어 데이터 크기가 더 커질 수 있습니다.
     • 경로 정보 변경 시 모든 관련 레코드를 업데이트해야 할 수 있습니다.
2. "파일이름.jpg" (DB에 저장 => URL + idea/image/ + id + DB에 저장한 데이터)
   • 장점:
     • 경로 정보가 더 간결하고 중복이 적어집니다.
     • 경로 변경 시 모든 레코드를 업데이트할 필요가 없습니다.
   • 단점:
     • 파일을 검색하거나 관리할 때 추가적인 로직이 필요할 수 있습니다.
     • 경로 정보를 기반으로 파일을 찾는데 시간이 더 걸릴 수 있습니다.

어떤 방법을 선택할지는 프로젝트의 성격, 데이터 양, 검색 빈도 등 여러 가지 요인에 따라 결정되어야 합니다. 만약 데이터 크기가 크거나 경로 변경이 빈번하지 않고 검색 속도가 중요하다면 2번 방법을 고려할 수 있습니다. 반면에 경로 정보를 보다 체계적으로 저장하고 관리해야 하는 상황이라면 1번 방법을 선택할 수 있습니다.

또한, 나중에 필요한 경우에 데이터 모델을 조정하거나 캐싱을 이용하여 성능을 최적화할 수도 있습니다. 최종 결정은 프로젝트 요구 사항 및 성능 테스트를 기반으로 하여야 합니다.

 

추가 자료

SQL 서버에 관련된 문서이다.

Memory Management Architecture Guide - SQL Server