지난번에 쓴 글 의 정리 버전이다.
어제는 강렬한 일을 겪고 온 뒤에 두서없이 쓴 글이라 제대로 정리해서 다시 작성해보았다.

DB에 일 시키지 마라.

DB랑 서버랑 요금을 비교해보라.
서버가 훨씬 저렴 할 것이다.
서버는 증설해도 부담이 덜하다.

서버가 연산을 해서 간단한 쿼리로 DB에 질의를 하는게 좋지,
DB에 일시켜서 버티지 못해 스펙을 높여야 하거나 클러스터링이나 샤딩 등으로 늘려야 하면 대가는 굉장히 비싸다.

로그를 넣으면 안된다.

로그 조회 전용 DB가 아니라면 로그를 넣으면 안된다.
여기서 DB란 물리적인 장비의 개념을 뜻한다.

로그 때문에 서비스중인 서버의 DB가 터지면 도망치고 싶어진다.
용량을 늘려서 복구해도 금새 또 터질게 보이기 때문이다.

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

필요한게 생겨서 컬럼을 추가하는건 너무 쉬운 일이다.
테이블에 아무 생각 없이 컬럼을 붙이다보면 어느새 컬럼이 30개 40개 50개 이렇게 되어버린다.
그렇게 거대한 테이블은 어떤 쿼리를 날려도 어떻게 인덱스를 걸어도 성능이 떨어질 수 밖에 없다.

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

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

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

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

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

DB는 검색엔진이 아니다.
검색엔진으로 쓰려면 엘라스틱서치같은 것을 이용하는게 더 좋다.
어떤 목적으로 ngram인덱스를 생성하려는지 한번 더 생각해야 한다.

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

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

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

생각을 먼저 해야한다.

AUTO_INCREMENT로 id를 매기는 테이블인데 create timestamp 컬럼에 인덱스를 걸어서 검색하는 쿼리를 본 적이 있다.

컬럼이 30개나 되고 인덱스도 40개나 걸린 테이블 때문에 메모리가 자꾸 터져서 고생한 일도 있다.

300줄이 넘어가는 Stored Procedure 때문에 애먹은적도 있다.
(한두개가 아니었다.)

DB에 로그도 같이 넣어서 조치해주려 했더니 용량을 늘리려면 스펙도 늘려야 성능을 유지할 수 있어서 엄청난 요금을 지불한 일도 있었다.

생각 하지 않고 손가락부터 움직이면 그게 차곡차곡 쌓여서 나중에 엄청난 이자와 함께 빚을 징수하러 찾아 올 것이다.

현실에서 빚 독촉을 당하면 괴로운 것 처럼 기술부채는 서비스를 불안정하게 만드는 것으로 빚 독촉을 한다.
현실에서의 빚 처럼 기술부채도 일시불로 상환할 수 없다.

그러니 손가락을 움직이기 전에 생각하고 계획을 세워야 한다.
부디 *WISCA 신드롬이나 *WIMP 신드롬에 빠지지 않길 바란다.

* WISCA: Why Isn't Sam Coding Anything?
* WIMP: Why Isn't Mary Programming?
(코드 컴플리트2에 수록된 표현)