[TIL]
[TIL] 2024.04.01 스크래핑 데이터 저장
재호링
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쿼리튜닝은 필수다.