Parallel Database Systems: The Future of High Performance Database Processing

지금까지 내가 경험으로 알게된 바로는 Parallel한 데이터 아키텍처 구조가 전체적으로 보면

OLTP를 지향하는 데이터베이스 시스템에는 적합하지 않다는 것으로 나타났으며 

따라서 OLTP를 위해서는 어쩔 수 없이 기존의 One-machane 아키텍처를 사용해야 한다는 것이 결론이다.

하지만 이에 대한 경험을 반증하는 증거로는 1986년도에 발표된 스톤브레이커 교수의 논문 

(The case for Shared Nothing) 과 다른 많은 병렬 데이터베이스 시스템들이 Shared-Nothing 구조를 이용해서 사용되고 있다는 사실이다. 

따라서 이에 나는 과연 무엇이 진실이고, 무엇이 허구인지를 밝혀서 

앞으로 데이터베이스의 진화는 어떻게 이루어질지 파악하고 싶다. 

곧 이는 클라우드 환경에서의 데이터베이스 선택과 데이터베이스 활용의 문제로 진화 할 수 있을 것이며 그에 대한 해답을 제공 할 수 있을 뿐만 아니라, 앞으로 엔터프라이즈 환경에서의 데이터베이스가 어떻게 변화할 수 있을지에 대한 실마리를 제공해 줄 것이라 믿는다. 

--------------------------------------------------------------------

1992년도에 발표된 Shared Nothing 구조의 Parallel Database System에

대한 논문

병렬구조를 통해 향상가능한 두가지 팩터는 Speed-up과 Scale-up 두가지가 존재한다. 

Speed-up은 고사양의 하드웨어를 사용하여 같은 분량의 일을 조금더 빨리 수행하는 것을 의미하고 Scale-up은 같은 시간동안 더 많은 양(amount)의 일을 처리하는 것을 의미한다.

단 Scale-up에는 두가지 분류가 존재하는데, batch와 Transactional이다. 

만약에 특정한 종류의 job이 다량의 독립된 다수의 클라이언트로부터 오는 다수의 요청으로 이루어진 것이라면  이 경우의 Scale-up은 n배의 클라이언트 수와 n배의 요청 수를 처리할 수 있게 되는 것이다. 

위와같은 Transaction Scale-up이 바로 Parallel Database System에서 효율적으로 구현 할 수 있다고 논문은 말하고 있다. 

다른 형태의 Scale-up은 바로 Batch-Scale-up인데 이경우는 하나의 거대한 작업이 존재하는 경우이다. 이는 일반적인 형태의 database Query나 과학적 simulation 작업에 해당하는 경우다. 

이 경우의 scale-up은 N배의 강력한 하드웨어를 이용해 N배의 더 큰 작업을 처리할 수 있게 되는 것을 의미한다. 

따라서 N배 더 큰 데이터베이스에 Query를 요청하는 경우나 N배의 시간을 더 요하는 Simulation작업을 해석할 수 있다.

위와같은 선형적인 Speed-up 과 Scale-up을 방해하는 요소 가운데는 세가지가 있다. 

병렬 오퍼레이션을 모두 Start-up 하는데 걸리는 시간이 상대적으로 길다. 

Start-up - 전체 페러럴한 구조로 형성된 작업들은 스타트업 하는데 걸리는 시간도 길어진다(?)

interferrence - 특정 자원의 독점으로 인한 제한적인 요소.

skew - 전체 작업을 종료하는데 걸리는 시간은 전체 작업에서 구성된 작업 가운데 가장 느린 작업에 걸리는 시간과 같게 된다.

결론적으로 Parallel 한 구성을 통해서 점점 단위 작업의 량이 작아지는 경우 작업이 최고로 올래걸리는 시간 그 이하로 작업시간이 줄지 않게 된다. 

어느 최고점에 수렴하게 되거나 혹은 더 느려질 수 있다.

컴퓨터의 병렬 구성의 목적은 - 적당한 속도의 프로세서 파워를 모아서 강력한 한개의 프로세서를 구축하는 것을 의미한다.

Shared-Nothing은 일반적으로 대량의 데이터를 네트워크를 통해서 전달할 필요가 없이

대량의 데이터를 전달하는 것이 아니라, 요청 메시지를 전달하고 filter된 꼭 필요한 데이터들만 전달된다. 

게다가 병렬로 구성된 환경에서 interconnection을 이루는 네트워크는 현재 각각의 database 벤더들 마다 고유의 특색을 가지고 있다.

- Teradata의 경우 Redundant tree-structured communication network

- Tandem - Three-level duplexed network, (two level은 클러스터 구성에 사용) 

Gamma - Intel Hypercube 사용 

기타 등등등등

Shared-Nothing Architecture가 유리함을 가져 갈 수 있는 이유는 데이터간의 공유가 적기 때문에 interference를 최대한 작게 유지할 수 있다는 점

또한 Interconnect-Network를 통해 많은 데이터들이 오고갈 필요가 없다는 점이 유리한 이유이다. 

뿐만 아니라 Shared-Nothing 구조를 사용하면 무제한에 가까운 Scale-out이 가능하다. 

(하지만 여기서 질문, 

1. 데이터 량 자체가 방대한 경우, 하나의 쿼리를 통해 요구하는 데이터량이 많고, 결과적으로 그 데이터가 전체 Interconnection이 보장하는 대역폭 이상일 경우의 성능 저하는 어떻게 처리할 것인가? 

2. 이론적으로는 그렇게 이상적으로 보이는 아키텍처가 지금까지 진일보하지 못한 이유는 무엇인가? 단지, 투자가 그쪽으로 잘 이루어지지 않았기 때문인가? 아니면 이 이론에 대한 결론이 너무 섣부른 결론이라는 것을 증명하는 것인가? )

논문에 포함되어있는 잡다한 팩트들

데이터를 파티셔닝 하는것은 우선 IO에서 커다란 이점을 가지고 온다. 각각 필요한 데이터를 동시에 여러곳에서 나누어서 가죠올 수 있으니까.

 

파티셔닝 하는 관점은 일반적으로 라운드-로빈 방식과 해싱을 사용한 방식등이 존재한다. 

Teradata의 병렬처리에 사용되는 프로세서는 일반적으로 두 그룹으로 나뉜다. IFP (Interface Processor) AMP (Access Module Processors) 

IFP는 일반적으로 호스트와의 커넥션 연결 및 쿼리 파싱, 최적화, 쿼리 수행시의 AMP들의 지휘 역할을 맡는다. 

AMP는 일반적으로 전체 쿼리의 수행에 대한 역할을 맡는다. 

=======================================

결국 뭉뚱그려 결론을 쓰자면

오라클은 오라클 나름의 선택을 했을 뿐이고, 지금의 트렌드 형태가 결국 Shared-Nothing을 무효화 하는 역할을 하진 않는다. 이 말은 즉, 앞으로 발전 가능성의 여지가 남아있다는 말이다. 

하지만 현재 개별 하드웨어 스펙의 성능이 증가함에 따라서, 원 머신 형태의 Database가 나타날 수도 있고, 그렇지 않는다면, Shared-memory 혹은 Shared-Disk 형태의 Database가 나타날 수 있다. 

현재 자본과 능력을가지고 있는 곳은 Oracle과 IBM이고, Oracle은 현재 Shared-Nothing에 대해 큰 관심을 가지고 있지 않은 상태이다. 

과연 그렇다면 앞으로 shared-Nothing 구조를 가진 새로운 Database System은 등장할 것인가?