지금까지 겪은 DB에 하지 말아야 할 짓

41

시행착오

목록 보기
7/22
post-custom-banner

너무 두서없이 쓰다보니 다시 정리해서 여기에 작성했다.

시간에 인덱싱 하지마라

시간에 인덱싱 하는건 굉장히 비효율적이다.
특히나 TIMESTAMP나 DATETIME같은 시간 형식에 인덱싱 하는건 정말로 비효율적이다.
정 시간에 인덱싱을 걸고싶거든 unix timestamp 형식의 INT 형으로 만들어서 인덱스를 걸어라.
알아보기는 어렵겠지만 인덱싱 효율은 훨씬 좋다.

DB에 로그를 같이 넣지마라

로그만 넣는 (물리적으로 별개의)DB라면 별 말 안하겠다.
하지만, 데이터를 넣는 DB에 로그를 넣는건 언젠가 죽고싶은 기분을 느끼고 싶거든 말리지 않겠다.

테이블을 키우지 마라

더 필요한 컬럼이 생기거든 정말로 그 테이블에 추가를 해야되는지 더 생각해봐라.
데이터베이스 정규화라는것은 왜 하는지도 생각해봐라.
하지만 INSERT, UPDATE, DELETE를 10년에 한 행 정도 할까 말까 한 테이블이면 맘대로 해도 상관없다.

정말 필요한 컬럼만 인덱스를 걸어라

인덱스가 걸린 컬럼은 UPDATE라는 개념이 없다.
UPDATE 라고 쿼리를 쓰지만 실제론 DELETE & INSERT 로 작동한다.

인덱스를 많이 추가 할 수록 용량도 늘고 메모리도 떨어져간다.
DB가 시도때도 없이 메모리 부족으로 터져나가는걸 보게 될 것이다.

만약 거대한 테이블을 만들어버렸거든, 인덱스를 걸지 말고
엘라스틱서치 같은데에 동기화 시켜서 거기서 검색해라.

ngram 인덱스 쓰지마라

DB는 검색엔진이 아니다.

Stored Procedure 만들지 마라

DB는 DataBase지 Worker가 아니다.
DB에다가 코딩하려고 들지 마라.

생각하고 해라

이건 꼭 DB에만 해당되는건 아니다.
일단 키보드부터 치려 하지 말고 생각하고 해라.
아무 생각 없이 키보드 많이 친다고, 컴퓨터 앞에 오래 앉아있는다고 일 많이 하는거 아니다.

profile
지상 최강의 개발자 쥬니니
post-custom-banner

5개의 댓글

comment-user-thumbnail
2021년 2월 26일

너무 많은 트랜잭션을 담는 데이터 테이블이라면 DATE 는 인덱스가 오히려 필수일 수도 있습니다.

1개의 답글
comment-user-thumbnail
2021년 3월 3일

실상은 저장 프로시저를 떡발라서 굴러가는 서비스들이 있다는게 함정이죠 😭

1개의 답글