상세 컨텐츠

본문 제목

[TIL] 2024.04.01 스크래핑 데이터 저장

[TIL]

by 재호링 2024. 4. 1. 22:37

본문

 

약 40개의 스크래핑 데이터를 가져와 저장했다.

데이터를 저장할 때 쓴 쿼리빌더다.

원래는 .save로 작업을 해뒀지만

 

쿼리 빌더를 사용한 이유는

DB 관계가 복잡해질 수록 기존 repository를 이용한 메서드들을 통한

CRUD 사용이 어려워지는 경우가 존재한다고한다.

 

예를 들자면 내가 작업하는 파트에 1:N 관계의 테이블 여러개 추가된다고 가정해보자.

지금 테이블과 N:1 관계를 맺는 엔티티가 추가되었을때 관련된 save() 메서드들이 오작동하게 되어

 

결국에 쿼리 빌더로 리팩토링 해야하는 경우가 생길 수 있어

후에 진행해야 할 쿼리빌더 리팩토링을 먼저 진행한 것이다.

 

쿼리빌더가 ORM의 강력한 장점이기도 하지만 너무 의존해서는 안된다.

SQL을 명확히 이해하고 DB를 다루는 기본적인 능력을 길러야한다.

결국엔 SQL 쿼리에 대한 이해를 바탕으로 TypeORM 뿐 아니라

여러 ORM들을 적응할테니

 

typeorm @Index()

@Index(): 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조, B+ Tree 알고리즘을 사용, 하여 3번만에 검색할 수 있음 책에 색인(목차)을 추가하는 것과 같음

단점

  • 인덱스를 관리하기 위해 DB의 약 10%에 해당하는 저장공간 필요
  • create, delete, update가 빈번한 속성에 index를 걸게 되면 index 크기가 커져서 오히려 성능 저하되는 역효과 발생

고려해야할 사항

  • select의 속도만 빨라지지 insert와 update는느려진다.
  • 추가 정보가 들어오면 또 추가해야한다 그래서 인덱스를 신중하게 고려해야한다
  • 조회에 자주 사용되는 컬럼이 무엇인지
  • 유니크한 값인지
  • 업데이트가 빈번하지 않은 컬럼인지

최적화를 위한 SQL쿼리튜닝은 필수다.

 

관련글 더보기