사람의 성향은 얼마나 빨라야 빠르다고 할까요?

정보의 공유가 빛의 속도로 빨라졌다고 하나, 그러나 이제는 대량의 속도로 쏟아지는 데이터에 대해서는 빠른 속도로 분석하여 실시간 기업에 활용하고자 하는 요구가 증대되고 있습니다.

 

이른 바 실시간 기업, Real Time Enterprise라고 하는 개념인데요. 이 기업은 인지에서부터 의사결정이 빠른 속도로 이루어지고 의사결정 되면 바로 행동이 수행되는 특징을 가지고 있습니다. 기업 간의 정보공유가 빠르고 시장에서 개념적 선점 및 제품의 우선적인 출시가 곧 생존을 결정하기 때문에 이 같은 RTE가 계속 확산되고 있다고 할 수 있습니다.

  

카카오톡(Kakao talk)은 스마트폰 환경의 시장을 빠르게 읽어내어 메시지 플랫폼을 만들어 출시하므로써 막대한 영향력을 행사하고 있습니다. 그 이후 많은 수의 메이져 주자들이 등장했지만 이를 뛰어넘지 못하고 있는데요. 이것은 빠름의 프리미엄이 아닌가 생각이 됩니다.

  

데이터처리에 있어 빠른 성능은 기업의 “경쟁력”을 뛰어넘어 “생존”을 결정하는 요소로 인식될 수 있는 부분이 되고 있습니다.

  

저는 최근에 새로운 DBMS인 벡터와이즈(Vectorwise)라는 데이터베이스를 보았고 실제로 테스트를 해보았는데요. 정말 빠르더군요, 60억건의 데이터를 SELECT coun(*) FROM ~ 하는데 단 1초도 걸리지 않았습니다. 미리 계산해 놓지 않고 어떻게 이렇게 빨리 조회할까 의심이 심히 많이 되었습니다. 그래서 이번에는 Where절에 다양한 옵션을 부여하고 DISTINCT하는 단위로 SUM을 날려보았는데요 이 또한 수 초내에 끝나버리는 엄청난 성능을 보여주었습니다. 핵심기술은 CPU안에서 데이터연산방식을 병렬화하여 성능을 향상 시켰더군요..

  

처음 이 데이터베이스의 설명 장표를 보았을 때 말도 안되는 비교 장표를 들고 온줄 알았습니다. 흔히들 제품을 공급하는 벤더에서 자기 제품을 홍보하기 위해 만들어놓은 상투적인 설명장표인 줄만 알았는데요,그 제품의 아키텍처를 뜯어보고 직접 설치되어 있는 데이터베이스에 데이터를 집어넣고 테스트를 해보니 그 결과가 남다르다는 것을 알았습니다.

  

지금처럼 확산되어 있는 컴퓨터구조를 처음 제안한 사람은 폰 노이만 이라는 사람이었습니다. 그 사람은 컴퓨터란 하나의 연상장치를 가지고 있고, 제어장치, 그리고 명령어를 처리할 수 있는 단일저장치를 가지고 있는 것으로 제안했습니다. 단일저장장치(메모리)에는 연산 수행과 관련된 일련의 명령어와 연산에 필요한 또는 연산의 결과로 생성된 데이터를 함께 수용하는 Computing Machine 모델을 제안했는데요. 이후 모든 컴퓨터는 이 구조에 적합하게 설계되고 개발이 되었습니다.

  

그러나, 이러한 모델을 따르다 보니 성능상 한계점에 이른 부분이 많이 있게 되었지요..

성능상 한계점 중 대표적인 특징이 CPU는 한 번에 단 하나의 명령어만 실행가능(SISD: Single Instruction Single Data; Flynn의 분류)한 아키텍처입니다. 이 방식은 하나의 메모리에 명령어, 데이터를 모두 저장해 메모리 버스의 병목현상 발생 및 성능향상을 위한 pipelining 구현이 어려운 형태가 된 것입니다. 이를 극복하기 위해 데이터와 명령어를 분리처리연산하기 위한 하바드(Havard) 아키텍처가 제안되어 사용되기도 하고 명령어를 여러 개를 한꺼번에 처리하기 위한 여러 가지 기법들이 등장하여 처리하는 기술들이 등장하였습니다.

  

데이터를 처리함에 있어 성능의 한계점을 뛰어넘기 위해 여러 가지 기술들이 활용되고 있는데요. 많은 요소 중에서도 성능향상을 위해 핵심적으로 사용이 되고 있는 방식이 자원을 동시에 이용할 수 있도록 병렬화 기법을 적용하여 성능을 높이고 있습니다.

  

병렬성은 하나의 프로그램이 여러 개의 자원을 이용하여 동시에 처리되는 것을 의미합니다. 여러 개의 프로그램이 하나의 자원을 이용하여 처리하는 병행성과 분류됨에 주의를 해야 하지요. 어쨌든 병렬성은 개별 프로세스의 성능향상을 위해 고안된 개념이라고 할 수 있습니다.

  

데이터처리의 성능을 향상시키기 위해서 여러 가지 병렬성을 활용하는 방법이 각 DBMS마다 적용이 되었는데요. 이를 정리하면...

① SQL문장의 병렬 처리

② 테이블 단위의 병렬처리

③ 서버 단위의 병렬처리

④ CPU내 명령어의 병렬처리

가 있습니다.

이것을 좀 더 자세하게 들여다보면 다음과 같은 내용으로 설명이 될 수 있습니다.

  

① SQL문장의 병렬 처리

하나의 프로그램에 있는 SQL이 여러 장의 CPU를 활용할 수 있는 SQL병렬처리 방식이 있습니다. SQL구문 하나가 실행이 될 때 여러 개의 CPU를 이용할 수 있도록 병렬환경을 지정하여 기동을 하게 하는 방법이 됩니다. SQL에 힌트를 부여하여 하나의 SQL이 여러 개의 대량의 작업을 하는 SQL이 CPU의 활용율이 낮을 만큰 적은 수의 트랜잭션이 들어오는 DB서버에 적용할 수 있는 방법이 됩니다. 즉 하나의 SQL에 많은 양의 CPU 사용티켓을 발행해주어 혼자 빨리 수행할 수 있도록 권리를 준거라고 보면 될 것 같습니다.

  

② 테이블 단위의 병렬처리

논리적인 하나의 테이블을 물리적으로 여러 개의 테이블로 분리하여 같은 DB서버내에 있게하여 SQL구문을 여러 개의 물리적인 테이블에서 처리하는 수평분할 처리 방식(파티셔닝 처리)이 있습니다. 이는 사실 물리적인 디스크가 이미 여러 가지 기법에 의해 병렬화 되어 있어 사실 병렬처리의 효과는 크지는 않습니다. 이 방식으로 인한 성능향상은 물리적인 데이터의 병렬성 때문에 성능이 향상 된다기 보다는 인덱스나 테이블의 비슷한 블록을 분리하여 경합을 줄임으로 인한 성능의 향상이 더 효과가 있는 방식입니다.

  

③ 서버 단위의 병렬처리

하나의 테이블을 여러 대의 Scale-out된 서버에 테이블로 복제(Shading)하여 처리하는 방식인 복제분할처리 방식의 병렬처리 방식이 있습니다. 테이블은 하나이지만 이것을 여러 대의 서버에 복제분산하여 한꺼번에 연산처리 할 수 있도록 하는 기법입니다. 테이블의 스키마만 복제하고 데이터를 중복하지 않고 가지고 있을 수도 있고(데이터의 일관성이 중요한 경우), 테이블의 스키마와 함께 데이터까지 중복하여 가지고 있을 수도 있습니다.(처리성능이 절대적으로 중요한 경우) 이 방식을 적용하면 통해 개별 트랜잭션에 대해서 여러 대의 서버가 한꺼번에 작동이 되어 높은 성능을 제공할 수 있습니다.

 

이것을 SMP (symmetric multiprocessing)또는 MPP (massively parallel processing)이라고 합니다. SMP의 경우 동일한 하나의 OS와 메모리를 공유하여 처리하는 방식입니다. “tightly coupled”, "shared everything" 방식이라고 하기도 합니다. OLTP에서 많이 사용하는 방식이 SMP방식입니다. DWMPP방식을 많이 적용하고 있는데요. OS나 메모리 영역을 공유하지 않고 자신만의 환경으로 적용하는 방식입니다.이 방식은 "loosely coupled" or "shared nothing"이라고 합니다. 처리 자원을 공유하지 않아도 되는당한 방식이 되고 최근에 빅데이터환경의 많은 데이터처리 환경이 이 MPP방식으로 구현이 된다고 할 수 있습니다.

  

④ CPU내 명령어의 병렬처리

마지막은 CPU안에서 하나의 명령어에 대해 여러 개의 데이터를 한꺼번에 처리하는 벡터방식의 병렬 연산방식이 있습니다. 이 방식은 하나의 SQL구문에서 연산하고자 하는 여러 개의 데이터를 동시에 CPU의Cache에 올려놓고 한꺼번에 Cache안에 있는 수만큼 동시 연산처리하는 방식인데요. 이 방식을 Flynn의 컴퓨터 분류정의에 따르면 SIMD(Single Instructor Multiple data)처리 방식이라고 합니다. 이 방식은CPU내에서 명령어가 데이터를 처리함에 있어 병렬처리를 함으로서 성능을 향상 시키는 방법이기 때문에 서버가 Scale-out하거나 많은 수의 CPU를 장착하지 않아도 자체적으로 성능을 높일 수 있는 방법이 됩니다.

최근에 나온 벡터와이즈 DBMS는 바로 이 방식을 사용하여 성능을 높혔다고 할 수 있습니다.

  

요즘 여기저기를 다녀보면 데이터처리 성능 때문에 고민하는 많은 기업 그리고 그것을 담당하는 사람들을 볼 수 있습니다. 누적되는 데이터속에서 느려지는 데이터 처리 속도 그러나 의사결정은 더 빠르게 더 정확하게 요구를 하고 있는데요. 이러한 환경 때문에 데이터를 설계하고 구축하고 또한 실 업무에 제공하기 위해 운영하는 많은 데이터전문가들에게 복잡한 숙제를 던져주는 것이 사실입니다.

  

이것을 데이터관련 직업이 없어지지 않고 오래가는 장점으로 표현해야 할까요? ^^

  

어쨌든 데이터를 담당하는 전문가들은 이에 대해서 끊임없이 생각하고 고민하여 각 업무에 적합한 최적의 솔루션 환경을 제시해야 하는 의무를 가지고 있습니다. 내가 하지 않으면 누군가 다른 사람이 하게 되어 원하지 않는 방향으로 회사생활을 할 수도 있겠지요.

 

 

성능에 대한 분석과 개선을 SQL튜닝 하나로 생각하지 말고, 성능데이터모델,데이터베이스 환경, 업무에 적합한 DBMS, 데이터의?? 업무특성에 딱 맞는 데이터베이스 환경을 구현할 필요가 있습니다.