IT easy, IT is! | 다섯 번째, SQL과 OPTIMIZER

  SQL과 도널드 체임벌린

지난 『IT easy, IT is!』의 흥미로운 IT 이야기를 이어가겠습니다.

 

앞서 말씀 드렸던 ‘A Relational Model of Data for Large Shared Data Banks’라는, 데이터를 집합개념으로 관리할 수 있다고 제언한 논문을 쓴 E.F.Codd 박사로부터 시작된 IBM의 ‘“System R” 프로젝트’가 있습니다. 당시 “System R”에는 20~30명의 영웅들이 참여했었는데, 그 중 가장 대표적인 사람이 바로 짐 그레이 입니다. 짐 그레이는 지금 우리가 아는 리커버리, 트랜잭션 등 여러가지 DB의 매커니즘 개념을 다 만들어냈고, 짐 그레이의 책은 DB의 이론서로 뽑힙니다.

그리고 또 하나, “System R”의 가장 큰 유산은 우리가 익히 알고 있는 SQL이라는 랭귀지이고, 바로 도널드 체임벌린이라는 사람이 만들어냈습니다. 참고로 현재 “System R” 프로젝트의 내부에 관해 말씀 드리고 있는 이야기들은 체임벌린의 인터뷰나 논문에서 따온 것입니다.

 

그 체임벌린이 “System R”에 참여한지 1년 만인 1974년에, 레이먼드 보이스라는 사람과 논문을 써냈습니다. 그게 바로 SEQUEL에 대한 논문이며, 이것이 나중에 SQL로 발전하게 된 것입니다. 레이몬드 보이스 또한 밥 마이너나 짐 그레이처럼 역사에 남을 천재였는데, 안타깝게도 SEQUEL을 만든 지 1년 후에 질병으로 세상을 떠나게 됩니다. 그래서 레이몬드 보이스는 사진이 없습니다.

 

 

 

       (그림 : 도널드 체임벌린)

 

  3세대 언어와 4세대 언어

SQL에 대해 말씀 드리기 앞서, 최초의 고급언어는 포트란이었으며, 비슷한 시기에 코볼이 만들어지고 있었습니다. HOW, 데이터를 ‘어떻게’ 저장하느냐는 입력을 직접 해줘야 하는 프로그램인 포트란과 코볼, 또 C랭귀지 같은 것들을 ‘구조적 프로그램(STRUCTURED LANGAUGE)’이라고 하며, ‘3세대 언어’라고 합니다. 그리고 이런 구조적 프로그램이 나오던 시기가 1950~1960년대의 상황입니다. 3세대 언어에서는 저장하고, 찾아오는 행위가 수월하지만은 않습니다.

 

그에 대한 어려움을 해결하기 위해 나온 것이 4세대 언어이며, 4세대 언어의 가장 대표적인 것이 바로 SQL입니다. 도널드 체임벌린과 레이먼드 보이스가 만든 SQL, 즉 4세대 언어에서는 ‘HOW’라는 게 없습니다. 오로지 ‘뭐 가져와~’와 같은 ‘WHAT’만 존재합니다.

 

예를 들면 4세대 랭귀지는 군 사령관이고, 3세대 언어는 작전과장입니다. 군 사령관은 ‘저 고지를 점령해.’라고 명령을 내립니다. 군 사령관은 명령을 내리면 끝입니다. 어떻게 점령하는지는 작전과장이 계획을 짭니다. 그래서 구조적 프로그래밍은 ‘어떻게’라는 걸 다 기술해줘야 하는 반면, 4세대 랭귀지는 명령만 내리면 됩니다. 그러면 4세대 랭귀지에서 이 SQL을 코디네이터한테 날리는 거고, 이 코디네이터가 바로 DBMS입니다.

 

그래서 SQL을 DBMS에 날리면, DBMS가 작전계획을 짜줍니다. 지난 번 말씀 드린 IDS만 해도 이 SQL이 표준화되지 않았었는데, 이 때 SQL이 표준화돼서 만들어졌습니다. 그래서 DBMS가 바로 작전과장 역할을 하는 겁니다.

 

 

        (그림 : 군사령관 역할을 하는 4세대 언어와, 작전과장 역할을 하는 3세대 언어)

  Plan과 Optimizer

또한 그 ‘어떻게’라는 작전 계획을 바로 ‘PLAN’이라고 합니다. 작전계획이니까, 실제로 ‘EXECUTION PLAN’이라고도 합니다. 하나의 SQL을 던져지면, DBMS는 수 없이 많은 작전 계획을 고려합니다. 여기서 그 고려를 진행하는 DBMS의 모듈을 ‘OPTIMIZER’라고 합니다.

DBMS의 OPTIMIZER가 SQL 명령이 들어오면 그에 대한 ‘EXECUTION PLAN’을 고려해서 그 중에 하나를 비용기반으로 고르고 실행합니다. 참고로 이 비용기반 OPTIMIZER를 만든 사람은 ‘패트리샤 셀링거’(patricia selinger)인데, 이 분에 대한 이야기는 추후에 자세히 전해드리도록 하겠습니다.

 

 

 

 

 

        (그림 : 페트리샤 셀링거)

 

이어서, 이 OPTIMIZER가 수 많은 작전을 고려하고 그 중에 하나를 골랐는데, 사람이 보기에 그 작전 보다는 다른 작전을 고르는 것이 훨씬 더 효율적으로 공격할 수 있겠다는 판단이 들면, DBMS OPTIMIZER한테 ‘너 생각은 그렇겠지만, 이렇게 해라.’라고 말하는 것이 바로 ‘SQL 튜닝’이며, 이에 관련된 엑셈의 세미나가 바로 ‘SQL 튜닝의 시작 1,2’입니다.

이것은 마치 인간 작전과장이 OPTIMIZER한테 ‘계곡으로 가서 이렇게 이렇게 공격하는 것이 훨씬 더 낫다.’고, 힌트를 주는 것과 같습니다. SQL 힌트로 ‘~~하는 게 좋아.’라고 하면 대개의 경우에 오라클 OPTIMIZER가 작전을 바꿉니다. 작전계획 잘못된 걸 골라서 거기다가 힌트를 줘서 작전 계획을 새로 짜주는 SQL 튜닝도 이런 과정이라 설명할 수 있습니다. 그런 힌트를 얻으면, OPTIMIZER가 원래는 빙빙 돌면서 2시간, 5시간, 10시간을 잡아 먹던 작업을 최적화하여, 5분, 1분, 10초 만에 수행해내게 됩니다.