Flask API 개발3

1. API 명세 수정

2. cache설정

• 캐시 해지에 대한 조건(크기 or 시간 제한)을 목적에 맞게 설정해야함 -> flask 공식문서나 다른 자료들에서 시간 제한만 사용하고 크기 제한하는 법을 찾지 못함

3. API 설계

쿼리 클래스와 각 카테고리별로 호출할 쿼리 함수 작성 완료

주요 이슈

• 실제 저널 입력 시간과, 디비에 저장되는 저널 입력시간(영국 표준시간)이 다름.
  eg. 2022-11-18에 입력한 저널이 디비상에는 2022-11-17 15:00로 저장됨.
  -> date 파라미터값 받고, 그 값에서 -1 days 하여 쿼리 날리도록 설정함

4. 인덱스(INDEX)

인덱스는 RDBMS에서 검색 속도를 높이기 위한 기술이다.

TABLE의 컬럼을 색인화(따로 파일로 저장)하여 검색시 해당 TABLE의 레코드를 Full Scan 하는게 아니라 색인화 되어있는 INDEX 파일을 검색하여 검색속도를 빠르게 한다.

보통 SELECT 쿼리의 WHERE절이나 JOIN 예약어를 사용했을때 인덱스가 사용되며 SELECT 쿼리의 검색 속도를 빠르게 하는데 목적을 두고 있다.
(DELETE, INSERT, UPDATE 쿼리에서는 INDEX 사용하면 오히려 느려진다. -> 인덱스 재생성 해야하므로)

SQL서버에서 데이터의 레코드는 내부적으로 아무런 순서없이 저장되는데 이때 데이터 저장영역을 Heap이라고 한다. Heap에서는 인덱스가 없는 테이블의 데이터를 찾을 때 전체 데이터 페이지의 처음 레코드부터 끝 페이지의 마지막 레코드까지 모두 조회하여 검색조건과 비교하게 된다.
이러한 데이터 검색방법을 테이블 스캔(Table Scan) 또는 풀 스캔(Full Scan)이라고 한다. 양이 많은 테이블에서 일부분의 데이터만 불러 올 때 풀 스캔을 하면 처리 성능이 떨어진다.

즉, 인덱스는 데이터를 SELECT 할 때 빨리 찾기 위해 사용된다.

Index 작동 원리

SELECT *
FROM fpms_journal
WHERE task_id=57;

위 SQL문을 수행시에 서버 프로세스가 파싱 과정을 마친 후 DB buffer cache에 task_id 가 57인 정보가 있는지 확인한다.

정보가 없으면 하드 디스크 파일에서 57정보를 가진 블록을 복사해서 DB buffer cache로 가져온 후 57 정보만 골라내서 사용자에게 보여줌

이 때 두 가지 경우로 나눌 수 있는데,

Index 없는 경우 : 57인 정보가 어떤 블록에 들어 있는지 모르므로 데이터 전부 db buffer cache로 복사한 후 하나하나 찾는다.

Index 있는 경우 : where 절의 컬럼이 index가 만들어져 있는지 확인 후, 인덱스에 먼저 가서 57인 정보가 어떤 ROWID를 가지고 있는지 확인한 후 해당 ROWID에 있는 블록만 찾아가서 db buffer cache에 복사함.

Index 장점

• 키 값을 기초로 하여 테이블에서 검색과 정렬 속도를 향상시킨다.
• 그룹화 작업의 속도를 향상시킨다.
• 인덱스를 사용하면 테이블 행의 고유성을 강화시킬 수 있다.
• 테이블의 기본 키는 자동으로 인덱스가 된다.

Index 단점

• Index 생성시 .mdb 파일 크기가 증가한다.
• 한 페이지를 동시에 수정할 수 있는 병행성이 줄어든다.
• Index 된 Field에서 Data를 업데이트하거나, Record를 추가 또는 삭제시 성능이 떨어진다.
• 데이터 변경 작업이 자주 일어나는 경우, Index를 재작성해야 하므로 성능에 영향을 미친다.
• Index를 생성하는데 시간이 많이 소요될 수 있다.
• Index가 데이터베이스 공간을 차지해 추가적인 공간이 필요해진다.
• DB의 10퍼센트 내외의 공간이 추가로 필요

Index 사용 전 명시 사항

• where절에서 자주 사용하는 컬럼에 사용한다.
• like '%~'는 조심해야 한다. %는 뒤에만 사용하도록 해야한다.
  (table scan이여서 성능 감소)
• between A and B (Clustered Index가 유리)
  범위 쿼리문에서는 클러스터 인덱스가 유리하지만 클러스터 인덱스는 테이블 당 1개만 가질 수 있다는 단점 존재
• order by에 항상 또는 자주 사용되는 컬럼에 사용한다.
• join으로 자주 사용되는 컬럼에 사용한다.
• Foreign key (1:1 매핑)이 많을 때 -> Clustered, NonClustered Index 둘 다 상관 없다.
• Foreign key (1:N 매핑)이 많을 때 -> Clustered Index 사용한다.
• 100만건의 데이터 중 10건의 데이터 조회 -> 찾는 건이 적은 컬럼에 Index를 사용한다.
  상책중복이 많은 컬럼 (EX:성별)에는 Index를 거는 것이 아니다. 조회되는 건 수가 많으면 인덱스를 걸지 않고 Table Scan이 더 나은편이다.
• not 연산자는 긍정문으로 변경
• Insert, Delete 등 데이터의 변경(DML)이 많은 컬럼은 인덱스를 걸지 않은 편이 좋다.
• 인덱스를 만드는데 시간과 저장공간이 소비되고 만들고 난 후에도 추가적인 공간이 필요하다..
• 데이터를 변경(Insert, Update, Delete)를 하면 인덱스를 다시 조정해야하기 때문에 자원이 많이 소모된다(특히 Insert 연산).

인덱스 사용 예시

-- 인덱스 확인
 SELECT * FROM pg_indexes WHERE tablename = 'fpms_journal';

-- 인덱스 생성
 CREATE INDEX ix_fpms_journal_task_id ON fpms_journal(task_id);

-- 인덱스 삭제
 DROP INDEX ix_fpms_journal_task_id;

-- 인덱스 타는지 확인하는 법
 EXPLAIN ANALYZE
 SELECT * FROM fpms_journal WHERE task_id = '57';