DB Lock과 Select 쿼리 개선

일반적으로 데이터가 많을 때, Select 쿼리의 속도는 많이 느리다.
Select 쿼리를 개선하기 위해서는 다양한 방법이 있다.

SELECT 개선

1. INDEX
   INDEX를 달면 SELECT 쿼리는 개선된다.
   B-Tree, Hash, Fractal-Tree 등 DB 엔진마다 여러 방법이 있지만,
   이들의 공통점은 그냥 리스트로 탐색하는 O(N)보다 탐색시간이 적다는 것이다.

   세 가지 방법 중 제일 느린 B-Tree의 탐색은 O(logN) 이다.

• 단점
  B-Tree 기준 인덱싱을 하면, Update, Create가 느려질 수 밖에 없다. 만일 엄청나게 자주 Update 또한 된다면, INDEX가 그리 효율적인 방식이 아니다.
  Update 시간 동안 해당 트랜잭션이 Lock을 들고 있어, 트래픽이 많이 몰렸을 때 해당 시간동안은 Select할 수 없기 때문이다.
  더군다나 트래픽이 아주 많이 몰리고, 비동기로 처리하지 못하는 중복 api call들도 막 들어온다면?
  DeadLock 잘 난다.
  - Update문의 쿼리를 최대한 개선해서 크게 오래 걸리지 않는다면, 별로 시도되지 않는다면 괜찮을 것이다.
  - 추가로, Fractal-Tree를 쓰는 MariaDB나 어떤 트리를 쓰는지는 잘 모르겠지만, Aws aurora 같은 경우에는 이런 문제에서 조금 더 자유롭지 않을까? 하고 생각이 든다.

2. 윈도우 함수
   https://dev.mysql.com/doc/refman/8.0/en/window-function-descriptions.html
   해당 내용에 대한 지식은 부족하다. 다만, 적절히 조합했을 때 Select의 성능 개선에는 도움이 될 것 같다.
   Mysql Window Function의 퍼포먼스에 대한 정보를 찾지 못했다. 혹시 아시면 알려주세요.

3. REDIS
   사실 DB를 아예 새로운 DB로 이전할 게 아니라면, 이것만큼 효과적인 방법은 없다고 생각한다.
   DB를 Redis를 통해 캐싱해두는 것이다.
   도메인에 따라 다르겠지만, 대부분의 DB 조작은 최근 정보들에 대해서 이루어지므로 hit ratio도 높을 것이다.
   일반적으로는 REDIS에서 조회가 먼저 이루어지도록 하고, CUD의 경우 메인 DB에 먼저 반영하지만, 상황에 따라 적절하게 조합하는 게 이롭지 않을까?

요약

1. 최근의 정보를 많이, 자주 조회 및 업데이트할수록 REDIS로 DB를 캐싱하자
2. 인덱스가 무조건적으로 정답은 아닐 수 있다.
3. ORM을 쓰던 뭘 하던 하나의 쿼리를 최소화, 최적화한다.