[Architecture of a Database System] Parallel Architecture: Processes and Memory Coordination

이번 장에서는 DBMS 용어를 정리하고 각각의 process models에서 메모리를 어떻게 사용하는지 알아본다.

3.1 Shared Memory

Shared-Memory Parallel Systemd은 모든 프로세서가 같은 RAM과 디스크에 비슷한 퍼포먼스로 사용할 수 있다. 3가지 프로세스 모델 모두 이 아키텍처 위에서 잘 동작한다. Shared-memory의 프로세스 모델은 uniprocessor에서도 잘 동작한다. 대부분의 데이터베이스 시스템은 초기에 uniprocessor에서 동작되도록 만들어졌기 때문이다. Shared-memory 머신에서는 OS가 transparent하게 동작하도록 보장한다.

이 아키텍처의 주요 문제인 쿼리 실행 계층(Query Execution Layer)에서 단일 쿼리를 병렬화하는 것은 5장에서 공부한다.

3.2 Shared Nothing

Shared-Notiong Parallel System은 독립적인 머신이 네트워크 위에서 통신하도록 만들어졌다. 다른 시스템의 메모리나 디스크에 바로 접근할 수 있는 방법이 없다. 이 시스템은 하드웨어 공유에 대한 추상화를 제공하지 않는다. coordination을 DBMS에게 맡긴다. 가장 많이 사용하는 방식은 클러스터의 각각의 머신 또는 노드에 프로세스 모델을 실행시키는 것이다. 각가의 노드가 클라이언트의 SQL 요청을 처리하고, 메타데이터에 접근하고, SQL 요청을 컴파일하고, data access를 실행할 수 있다. 차이점은 클러스터 안의 각각의 시스템이 데이터의 일부만 저장한다는 것이다. 테이블이 horizontal data partitioning 되어있다.

파티셔닝은 1)hash-based partitioning by tuple attribute, 2)range-based partitionaing by tuple attribute, 3)round-robin, 4)hybrid(range-based and hash-based)의 방법이 있다. 쿼리 실행 단계에서, 쿼리 옵티마이저는 테이블얼 어떻게 horizontally repartition하고 결과를 intermediate할 것인지 결정한다.

decision-support 어플리케이션이나 데이터웨어하우스에서 많이 사용한다.

이 아키텍처에서는 다음과 같은 문제가 있을 수 있다.

1. 트랜잭션이나 로드밸런싱을 위해 cross-processor coordination이 필요한 경우가 있다.
   • 분산된 데드락 감지나 two-phase commit과 같은 이슈에 대응하기 위해 프로세서는 control message를 공유해야 한다.
2. partial failure에 대응해야 한다.
   • 모든 노드를 bring down 시킨다.
   • Data Skip을 한다.
   • full database redundancy(coarse-grained) to chained declustering(fine-grained)을 제공한다.
     • chained-declustering의 장점
       • availability를 보장하기 위해 적은 수의 머신이 필요하다.
       • 노드가 페일하면, 시스템 로드가 균등하게 분산된다. (n/n-1으로 linear degradation)
     • 대부분의 상업 시스템은 coarse-grained 와 fine-grained 의 중간 어딘가의 아키텍처를 사용한다.

3.3 Shared-Disk

모든 프로세서가 디스크에 같은 성능으로 접근할 수 있고, 다른 프로세서의 램에는 접근할 수 없다.

shared-nothing system에 비해 administration의 비용이 적게 들어간다. 하나의 노드의 failure가 다른 노드에 영향을 끼치지 않는다.

문제점

• 데이터가 손상을 입거나 하드웨어나 소프트웨어에 의해 부패되면 모든 노드에 영향을 끼친다.
• 데이터 공유를 coordinate 하기 위한 메모리가 없으므로, explicit coordination이 필요하다. 분산된 락 매니저와 분산된 버퍼 풀 관리를 위한 cache-coherency 프로토콜에 의존한다. 이들은 복잡한 소프트웨어 컴포넌트이고 bottleneck이 될 수 있다.

3.4 NUMA (Non-Uniform Memory Access)

shared memory programming model over a cluster of systems with independent memories 를 제공한다. 클러스터의 각 시스템은 자체 로컬 메모리에 빠르게 접근할 수 있는 반면 클러스터 인터커넥트를 통한 리모트 메모리에는 지연되어 접근이 가능하다. 이 아키텍처의 이름은 non-uniformity of memory access times에서 유래됐다.

NUMA 하드웨어 아키텍처는 shared-nothing과 shared-memory의 중간에 있다. 상업적으로 성공적이지 못했지만 NUMA 디자인 컨셉은 Shared Memory multi-processors에 적용되어 사용되고 있다.

DBMS가 NUMA로 실행되게 하는 방법

1. Non-Uniformity of Memory Access를 무시하기
2. near-memory와 far-memory의 access time이 1.5:1 에서 2:1 하면 optimization 하기
   optimization은 다양한 형태가 있지만, 모두 다음 두가지 접근을 따른다.
   1. 프로세서에서 사용할 데이터를 메모리에 올릴 떄, 로컬 메모리를 사용한다.
   2. DBMS 워커는 전에 사용하던 하드웨어 프로세서를 사용하도록 보장한다.

3.6 Standard Practice

대부분의 DBMS는 다수의 parallelism 모델을 지원한다.

• Shared Memory: IBM DB2, Oracle, Microsoft SQL Server
• Shared-Nothing: IBM DB2, Informix, Tandem
• Shared-Disk: Oracle RAC, RDB, IBM DB2 for zSeries

3.7 Discussion and Additional Material

새로운 문제들

1. many-core architectures를 이용할 수 있는 DBMS 아키텍처
2. service-oriented computing 영역에서 macro-scale 아키텍처
   • 어플리케이션과 서버의 운영이 자동화 되어야 한다.
   • recovery가 자동화되어야 한다.
   • 규모에 따라 다른 서버 또는 디스크에 데이터가 백업되어야 한다.
     • replication at the data storage level (Storage-Area Networs)
     • data replication at database storage engine level
     • retundant execution of queries by the query processor
     • redundant database requests auto-generated at the client software level (by web servers or application servers)

다양한 계획은 non-standard하고 어려워, 여전히 주류로 자리잡은 모델이 없다.