[데이터베이스] RDB에 하지 말아야 할 것들

우연히 좋은 좋은 글을 발견해서 공유하고자 한다.

 

 

1. DB에 일 시키지 말자.

DB랑 서버랑 요금을 비교해보면 서버가 훨씬 저렴할 것이다.

또한, 서버는 증설해도 DB 보다는 부담이 덜하다.

 

이 말은 즉, 서버가 연산을 해서 DB에 질의를 하는 것이 좋지,

DB에 일 시켜서 버티지 못해 스펙을 높여야 하거나 클러스터링이나 샤딩 등으로 늘려야 하는 대가는 굉장히 비싸다.

 

 

2. RDB에 로그를 넣으면 안된다.

로그 전용 DB 라면 로그를 넣어도 된다.

하지만 로그는 계속해서 발생할 것이고, 유저가 몰리게 된다면 짧은 시간에 로그는 대량으로 발생할 것이다.

 

그렇게 발생한 대량의 로그 때문에 서버의 DB가 터질 수 있다. 아니 터진다.

 

 

3. 컬럼을 추가하기 전에 생각해야한다.

필요한게 생겨서 컬럼을 추가하는건 너무 쉬운 일이다.

테이블에 아무 생각 없이 컬럼을 붙이다보면 어느새 컬럼이 30개 40개 50개 이렇게 되어버린다.

그렇게 거대한 테이블은 어떤 쿼리를 날려도 어떻게 인덱스를 걸어도 성능이 떨어질 수 밖에 없다.

 

시간이 갈 수록 이 테이블의 컬럼을 이용하는 코드는 늘어 갈 것이고, 분리하려면 신경써야 할 범위는 복리 이자가 붙듯이 계속 늘어난다.

 

 

4. 인덱스를 만들기 전에 생각해야한다.

인덱스로 설정된 컬럼은 UPDATE라는 개념이 사라진다.
"당신의 UPDATE 대체되었다. DELETE & INSERT로"
modify time을 담는 컬럼에 인덱스를 걸면...

 

그리고 컬럼 이야기를 할 때 언급한 '거대한 테이블'에 인덱스를 걸다보면 이리 검색하고 저리 검색하는 케이스가 생기기 때문에 경우의 수 만큼 multi key index 를 만들게 된다.
용량문제보단 메모리 문제 때문에 괴로워 질 것이다.

 

 

5. ngram 인덱스는 생각을 많이 해야한다.

DB는 검색엔진이 아니다.

검색엔진으로 쓰려면 엘라스틱서치같은 DB를 이용하는게 좋다.

 

6. procedure에도 단일 책임 원칙을 적용하라.

개인적으로는 Stored Procedure를 잘 쓰는 케이스를 경험하지 못해서 좋아하진 않지만, 단일 책임 원칙을 지키면서 요긴하게 쓴다면 좋을수도 있다.

 

하지만, Stored Procedure 안에 절차지향적 코딩으로 변수에 할당에 재할당을 해가며 이리저리 INSERT와 UPDATE, DELETE 해대면 성능에도 좋지 않고, 분리해내기도 쉽지 않다.
그런 Stored Procedure 라면 곧 DB 전체에 성능저하를 미칠텐데 의존하는 쿼리들 때문에 조치하기도 쉽지 않다.

 

 

 

 

 

 

 

 

 

 

 

[참고]

https://velog.io/@juunini/DB%EC%97%90-%ED%95%98%EC%A7%80-%EB%A7%90%EC%95%84%EC%95%BC-%ED%95%A0-%EA%B2%AA%EC%9D%80-%EC%9D%BC%EB%93%A4