WIL

이번엔 조회 성능을 개선하기 위해 이것저것 적용해본거 같다.
인덱스도 적용해보고
반 정규화도 해보고
캐싱도 해봤다.

인덱스를 사용하면서 쿼리 플랜을 사용하고 그게 어떤지 분석까지 해보았다.
다만 글에서는 그러한 부분들이 보이지 않아서 조금 아쉽다는 느낌이 들었다.
단순히 사진만 찍어서 올렸었는데 모르는 사람들이 봐서는 그래서... 어쩌자는 거지?라는 반응이 나올 수 도 있을거 같다라는 생각이 든다.
물론 k6를 통해 얼마나 향상이 되었는지도 테스트 해보고 그걸 AI로 분석까지는 했다.
하지만 세세하게 진행하지 못한점이 좀 아쉽다는느낌이 든다.

또한, 인덱스를 건다고 해서 단순히 성능이 기하급수적으로 올라가는건 아니었다.
오히려 잘못 사용하면 성능이 떨어질 수도 있다.
인덱스는 흔히들 책에서 쉽게 내용을 찾을 수 있는 정보로 비유를 한다.
결국 그 정보가 구체적인 경우에는 정보를 쉽게 찾을 수 있다고 생각한다.
하지만 찾으려는 정보가 구체적이지 않는다면 책에 있는 인덱스를 전부 뒤져야 할거다.
그래야 찾을 수 있으니까 그게 책전체를 보는거와 뭐가 다르냐는 말이냐..
복합 인덱스도 마찬가지다. 복합 인덱스가 빠른 이유는 단순히 인덱스를 두 개를 사용했기 때문이 아니다.
복합 인덱스가 빠른 이유는 그 정보들이 구체적이기 때문이라 생각한다.
어떤 정보의 값으로 그 값을 쉽게 유추 할 수 없다면 인덱스로써는 큰 가치가 없지 않을까?..

그 다음은 반 정규화다
반 정규하는 내가 생각할때 이번에 학습한것들 중에서 가장 트레이드 오프가 가장 심한 친구라고 생각이 든다.
그 데이터가 읽기 성능때문에 사용해야 하는건지
쓰기 성능때문에 사용하는지 고민할 필요가 있다고 생각이 든다.
기껏만들었는데 읽기 성능을 올리겠다고 반 정규화를 했는데 그 데이터는 사실 쓰기 성능때문에 사용하는거라면
반 정규화를 잘못 적용한게 아닌가 생각이 든다.
만약, 읽기 성능도 올려야 하는데 데이터가 쓰기 작업에 특화 되어있다면 조회 쿼리를 바꾸던지 인덱스를 걸어보는 방법을 선택해야 한다고 생각한다.

마지막으로 캐싱이다.
캐싱은 내가 생각할때 인덱스와 반정규화와 성격이 다르다고 생각한다.
캐싱+인덱스를 사용할 수도 있겠지만 캐싱+인덱스를 사용할 수 없는 경우도 존재한다.
만약 리스트를 캐싱한다면 어쩌면 인덱스는 의미가 없을 수도 있도 있다. 어떤 데이터로 캐싱하느냐에 따라 다르다고 생각한다.
내가 생각할때 캐싱은 마치 '악마에게 영혼을 파는 행위'라 생각한다. (악마에게 영혼을 팔면 그 만한 대가를 치러야 한다. 그게 실시간 성이다. 하지만 종종 영혼을 팔아도 잘 활용하는 경우도 존재한다..) 빠른 속도를 얻었지만, 실시간성에 대한 정보는 사라졌다. 물론 실시간성도 지키면서 개발 할 수 도 있겠지만, 그렇게 하려면 캐싱 전략이 필수적으로 필요하다. 잘못된 방법으로 캐싱을 하게 된다면 오히려 전체 서비스가 마비가 될 가능성도 있지 않을까? 고로 어떤 데이터가 캐싱을 하면 좋을지 생각해봐야 하고 만약, 캐싱을 무조건 해야 하는 상황이라면 적절한 캐싱 전략을 사용하는것이 좋다고 생각한다.

이렇게 3가지를 학습해봤다. 3가지는 공존할 수 있으면서 공존할 수 없을 수도 있다.
또 공존할 필요가 없을수도 있다. 
중요한건 적재적소에 사용하는것이 좋지 않을까 생각이 든다.