SQL (29) - 쓰레드와 캐싱

이번 포스트에서는 DB를 다루는데 있어서 쓰레드와 캐시가 무슨 역할을 수행하는지 알아보겠습니다.

 

1) READ와 WRITE로 알아본 DB의 스레드

1 - 1) READ

DB로부터 데이터를 가져오는 READ의 경우 다음의 과정을 거쳐 동작합니다.

• 데이터 사용자로부터 SQL 쿼리(SELECT)를 받음
• DB 관리자가 해당 SQL 쿼리를 파싱
• 파싱된 결과를 바탕으로 DB로부터 데이터를 읽음
• DB 관리자가 데이터 사용자에게 결과를 전달

 

1 - 2) WRITE

DB에 데이터를 쓰거나 수정하는 WRITE의 경우 다음의 과정을 거쳐 동작합니다.

• 데이터 사용자로부터 SQL 쿼리(INSERT)를 받음
• DB 관리자가 해당 SQL 쿼리를 파싱
• 파싱된 결과를 바탕으로 DB에 데이터를 씀
• DB 관리자가 데이터 사용자에게 결과를 전달

 

위와 같이 Read / Write가 동작한다고 표시하였으나,

사실 위처럼 동작하는 경우는 빠른 응답을 수행해야 하는 DB의 목표를 이뤄내지 못하게 됩니다.

 따라서 최종적으로 다음과 같은 방식으로 동작해야 빠른 응답이라는 목표를 달성할 수 있습니다.

 

1 - 3) 이상적인 READ / WRITE의 동작방식

• DB 관리자를 2개로 분리하여,
• 하나는 데이터 사용자로부터 SQL 쿼리를 받아 파싱하고,
• 다른 하나는 파싱된 쿼리를 토대로 데이터에 관련된 작업을 수행

따라서 DataBase 역시, 멀티 스레드로서 동작하여야 함을 알 수 있습니다.

 

2) DB에서의 캐싱

이전에 데이터에 관련한 Read / Write의 동작 과정을 살펴보았습니다.

 

Write의 경우, 쿼리를 받고 - 분석하여 - 처리의 과정으로 이뤄집니다.

처리에서 나온 결과물은 수행되었다라는 의미만을 가지며, 실질적인 형태는 갖고 있지 않습니다.

 

그러나 Read의 경우는 조금 다릅니다.

쿼리를 받고 - 분석하여 -처리하고 - 처리한 결과를 리턴하는 과정으로 이뤄집니다.

따라서 반드시 결과물이 존재해야 하며, 데이터 사용자는 해당 결과물을 사용해야만 합니다.

그렇다고 해서 매번, 위의 과정을 수행하며 데이터를 가져오는 것은 많은 부담을 주는 일입니다.

 

이를 위해 DB에는 캐싱하는 과정이 포함되었습니다.

캐싱은 이전의 연산의 결과물을 임시 저장하여 같은 연산이 들어오는 경우,

임시 저장한 결과값을 반환하는 메모리 효율을 구사하는 하나의 방법입니다.

 

2 - 1) 캐싱이 추가된 READ의 동작방식

이때 SQL에서는 캐싱을 위해 INDEX를 사용하여 캐싱 결과물을 가져옵니다.

최종적으로 캐싱이 추가된 READ 연산의 처리과정은 다음과 같습니다.

• 데이터 사용자로부터 SQL 쿼리(SELECT)를 받음
• 파싱하는 DB 관리자가 해당 쿼리를 분석
• INDEX를 사용하여 분석한 결과가 이전에 캐싱되어 있는지 확인
  • 캐싱되어 있다면 캐싱되어 있던 연산 결과를 데이터 사용자에게 반환
  • 캐싱되어 있지 않다면 작업하는 DB 관리자에게 분석된 쿼리를 넘김
    • 작업 결과를 캐싱하고 데이터 사용자에게 반환

또, 캐싱의 경우 캐싱 메모리가 더 이상 캐싱되는 데이터를 감당할 수 없다면

오래된 캐싱 기록부터 자동으로 삭제하므로 사용자는 부담없이 사용할 수 있습니다.

 

위와 같은 점을 보아 DB는 일반적으로 하드 디스크의 단계까지 이동하여 연산이 이뤄지진 않고,

또 처음 시도하는 연산과 다시 사용하는 연산의 경우 처리 속도가 다르다는 점도 알 수 있습니다.