[논문분석] MOSIQS 와 GSM(Group Split and Merge)
논문에서 소개 하는 MOSIQS 는 Persistent Memory(이하 PM) 에서 사용하는 객체 저장소 프레임워크다. PM 은 비휘발성 메모리로 인텔과 마이크론과 같은 회사들이 개발한 3D XPoint, 그리고 MRAM 등이 있다. MOSIQS 는 PM pool 위에 메모리 객체를 저장하고 접근할 수 있는 집합 메모리 풀을 제공함으로써 과학적 계산을 가속화한다.
cf) MOSIQS 는 "Persistent Memory Object Storage with Metadata Indexing and Querying for Scientific Computing" 의 줄임말이다.
경량의 PM kev-value 저장소를 사용해서 메모리 객체의 메타데이터를 관리하고, 수백만 개의 메모리 객체에 대한 메타데이터 검색 및 쿼리를 용이하게 한다. 논문 실험 결과에서 100% 쓰기 성능 향샹과 인덱스 저장 공간 오버헤드를 2.7배 감소시켰다고 한다.
Motivation
기존 과학 응용 프로그램에 직접 PM을 사용하는 것은 도전적이다. 기존 애플리케이션은 블록 기반 파일 시스템 인터페이스를 바탕으로 구축되어 있으며, 이는 바이트 주소 지정이 가능한 PM 하드웨어와는 확실히 맞지 않다. 간단한 해결책은 PM을 인식하는 파일 시스템을 배포하고 애플리케이션에서 PM을 사용하도록 하는거지만, PM에 특별히 설계된 ext4-DAX 는 원시 PM 장치의 쓰기 대역폭에 비해 최대 13배의 오버헤드를 발생시킨다. 따라서 파일 시스템을 배포하는 것은 PM에 최적의 선택이 아니다. 반면, 객체 저장 모델은 훨씬 간단한 인터페이스를 제공하지만 추가적인 메타데이터 관리와 객체 공유 제어가 필요하다.
파일 시스템 인터페이스 없이 PM에 직접 애플리케이션 객체를 저장하는 것은, 파일 시스템 오버헤드 없이 더 빠른 저장과 직접 계산과 같은 여러 이점을 제공한다. 그러나 동시에 여러 도전과제도 제기된다.
첫째, 애플리케이션 간의 데이터 공유와 다른 협업자들과의 공유는 과학 커뮤니티에서 필수적인 요구사항이다. 추가적인 설명 메타데이터 없이 PMO에 접근하고, 선택하고, 공유하는 것은 도전적이다. 왜냐하면 객체 접근과 공유는 애플리케이션, 사용자 또는 과학자가 제공하는 객체 이름, 크기, 소유자와 같은 객체 의미론(semantics)을 요구하기 때문이다. 다시말해 객체의 의미론적 정보(semantics)는 객체의 이름, 크기, 소유자와 같은 특성을 포함한다. 이러한 정보는 애플리케이션, 사용자 또는 과학자에 의해 제공될 수 있다.
반면, PMO는 단순한 메모리 할당 객체이며 지속적인 포인터를 통해서만 접근하고 공유될 수 있다. 예를 들어, 인텔의 PMDK libpmemobj API를 사용하면 PM에 저장된 각 객체는 아래 그림에서 보여진 것처럼 PMEMoid 유형의 객체 핸들로 표현된다.
cf) PMEMoid 는 인텔의 PMDK(Persistent Memory Development Kit) 라이브러리에서 제공하는 데이터 타입으로, PM 내의 객체를 가리키는 데 사용되는 고유 식별자다.
주어진 객체에 대한 PMEMoid는 realloc() 연산이 호출되지 않는 한 객체/애플리케이션의 생애 동안 변경되지 않는다. 따라서 PMO에 접근하고 공유하기 위해서는 사용자나 애플리케이션이 제공하는 의미론적인 객체에 대한 추가적인 메타데이터 매핑이나 인덱스가 필요하다. 또한, 과학 파일의 자체 기술적 메타데이터, 즉 과학 데이터 파일 내부에 내장된 메타데이터와 과학자에 의한 데이터 객체의 태그나 주석도 메모리 객체와 함께 지속되어야 한다.
둘째, PMO는 충돌 일관성(crash consistent)을 가져야 한다. 즉, 시스템은 애플리케이션 충돌이나 우아하지 않은(ungraceful) 전원 실패의 경우 메모리 객체의 접근성과 일관성을 보장해야 한다. 셋째, 각 PMO에 대한 인덱스 메타데이터를 생성하고 관리하는 것은 높은 인덱스 저장 공간 오버헤드와 큰 쿼리 검색 공간을 발생시킨다.
이를 위해, 우리는 shared PM pool 위에 객체 저장 추상화를 가진 애플리케이션 프레임워크를 구축할 계획이다. 제안된 애플리케이션 모델은 PMDK가 제공하는 트랜잭션을 사용하여 원자성과 일관성을 보장한다. 메타데이터는 경량의 persistent key-value 저장소에서 관리된다. 다중 속성 인덱싱, 검색 및 쿼리를 위해, Group Split and Merge (GSM) 인덱스 데이터 구조를 도입한다. GSM은 특정 공유 속성 세트를 기반으로 다양한 메모리 객체를 그룹화함으로써 쿼리 검색 공간과 저장 오버헤드를 최소화한다.
Design And Implementation
Architecture
MOSIQS는 과학적 애플리케이션을 위한 확장 가능한 데이터 관리 및 메타데이터 검색 서비스를 제공하는 PM 객체 저장 프레임워크다. MOSIQS의 목표 아키텍처는 수백 개의 컴퓨팅 노드에 걸쳐 분산된 PM 장치 배열이다. 각 컴퓨팅 노드의 PM은 Gen-Z 와 같은 고속 패브릭 어태치드 메모리(FAM) 인터커넥트를 통해 공유된 PM 풀 추상화를 통해 다른 컴퓨팅 노드와 공유된다.
아래 그림은 MOSIQS의 고수준 아키텍처 개요를 보여준다. 여러 컴퓨팅 노드는 MOSIQS 라이브러리를 통해 공유된 PM 풀 위에 공유된 네임스페이스 추상화를 생성하고 이러한 네임스페이스에서 메모리 객체를 직접 저장하고 관리할 수 있다. 이러한 컴퓨팅 노드에서 실행되는 여러 프로세스는 네임스페이스 추상화를 통해 PMO에 접근하고 공유할 수 있다. 그림은 컴퓨팅 노드 2에서 실행되는 프로세스가 네임스페이스 1과 2에서 두 개의 PMO에 접근하는 것을 보여준다.
응용 프로그램에 메모리 수준 객체 저장소 추상화를 가능하게 하기 위해, 인텔 PMDK가 제공하는 오픈 소스 PM 객체 저장소 인터페이스인 libpmemobj 라이브러리를 사용한다. 공유 메모리 객체 저장소 추상화 위에, MOSIQS는 과학적 메타데이터 검색 서비스를 응용 프로그램과 과학자들에게 제공하여 특정 PMO 또는 PMO의 부분 집합을 찾는 문제를 극복하고 성능을 더욱 가속화한다.
System Overview
MOSIQS는 주로 다음과 같은 주요 추상화로 구성된다.
- Shared memory pool
- Namespace manager
- Metadata extractor
- Sharing manager
- Group manager
- Index manager
- Query manager
아래 그림은 MOSIQS의 다층 구조를 제시한다. 가장 아래층은 모든 PM 장치를 집약하고 단일 PM 풀로 노출하는 공유 PM 풀이다. 다음으로 PMDK 계층은 libpmemobj와 libpmem을 통해 트랜잭션 및 신뢰성 있는 객체 조작과 같은 저수준 기본 요소를 제공한다. 모든 애플리케이션은 MOSIQS를 통해 PM 풀에서 메모리 객체를 연결하거나 분리하며, 이는 내부적으로 libpmemobj 인터페이스에 의존한다.
Metadata extraction and Storage Management 계층은 가장 아래층 위에 쌓여 있다. Metadata extractor 는 객체 이름과 PMEMoid 매핑을 추출하고 채우는 역할을 담당한다. 또한, 객체에서 주석, 사용자가 제공한 태그 및 기타 메타데이터도 추출한다. 추출된 모든 메타데이터는 kev-value 쌍 메타데이터 객체 형태로 존재한다.
Sharing manager 는 애플리케이션 및 협업자 간의 데이터 공유를 가능하게 한다. Group manager 는 애플리케이션 and/or 과학자가 정의한 PMO의 논리적 구성을 제공한다. 우리 설계에서 Group manager 는 인덱스 메타데이터를 보다 쉽고 공간 효율적으로 제공하는 중요한 역할을 한다. 또한, 여러 속성에 걸쳐 쿼리 검색 공간을 줄이는 데에도 도움을 준다. pool KV 저장소는 MOSIQS 객체의 모든 메타데이터를 위한 메타데이터 저장 백엔드다. Namespace manager는 대규모 공유 PM 풀을 애플리케이션 또는 사용자 정의 네임스페이스로 분할하는 유연한 제어를 가능하게 한다.
세 번째 계층은 다중 속성 메타데이터 검색 및 쿼리 서비스를 제공하며 PMO 메타데이터에 의존한다. Index manager 는 Group Split-Merge (GSM) 인덱스 데이터 구조를 제어한다. GSM 인덱스는 모든 메타데이터가 저장된 pool KV 저장소 위에서 효율적인 쿼리를 제공하도록 설계된 트리 데이터 구조다. Query manager 의 주요 책임은 사용자/과학자 및 애플리케이션으로부터의 쿼리 요청을 처리하는 것이다.
Data Model
MOSIQS 데이터 모델은 세 가지 주요 구성 요소로 이루어져 있다.
- PMO: PMO는 자체 설명이 가능한 개체로, 단일 값, 배열, 또는 복합 데이터 타입을 나타낸다. 응용 프로그램 또는 사용자에 의해 생성될 수 있다. PMO는 그룹 내에 위치하며, 추가적인 주석과 힌트를 명시할 수 있다. MOSIQS에서 PMO는 응용 프로그램과 사용자 간의 최소 공유 단위다. PMO는 일관된 상태를 보장하는 충돌 일관성, 시스템 네이밍, 그리고 다른 프로세스 및 협업자와 공유될 수 있도록 허용하는 권한 제어와 같은 여러 속성을 지원해야 한다.
- Group: 그룹은 공통 속성과 특성을 공유하는 PMO 모음을 나타낸다. MOSIQS는 그룹 간의 포함 관계를 지원한다. 즉, 하나의 그룹은 파일 시스템의 중첩된 디렉토리와 유사한 중첩된 그룹을 가질 수 있다. 구체적으로 그룹은 논리적 조직을 제공하고 PMO 모음을 저장 및 공유하는 방법을 제공한다. 그룹의 주요 속성은 나중에 "GSM: Multi-Attribute Indexing And Querying" 에서 논의할 공유 빈도(SF)다.
- Attribute: 속성은 <key, value> 쌍으로, 주석, 사용자 정의 태그 및 그룹 및 객체의 속성을 가능하게 한다. 우리의 속성 개념은 과학 데이터 형식인 HDF5 및 netCDF에서의 속성과 동일하다. 각 속성은 나중에 "GSM: Multi-Attribute Indexing And Querying" 에서 설명할 SF를 유지한다.
Shared Persistent Memory Pool
shared persistent memory pool은 MOSIQS가 PM 장치 배열의 집합적인 뷰와 집계 용량을 응용 프로그램에 제공할 수 있게 한다. 이는 과학적 응용 프로그램의 용량 요구를 만족시킨다. 내부적으로, MOSIQS는 libpmempool API 를 통해 공유 PM 풀을 생성하며, 이때 장치 파일들, 즉 위 Figure 3 그림에서 보여지는 /dev/pmem[1-6]은 단일 PM 풀을 형성하기 위해 연결된다. PM 풀 내의 어떤 객체도 루트 객체 포인터를 통해 접근할 수 있다. 애플리케이션이 풀을 열 때, 전역 메모리 루트 포인터에 접근할 수 있는 권한이 주어지며, 이를 통해 애플리케이션은 풀 KV 저장소에 저장된 메타데이터에 접근하여 PMO를 찾을 수 있다. 메모리 할당 및 해제는 libpmemobj 내부의 하위 수준에서 libpmem을 통해 수행된다.
MOSIQS는 공유 PM 풀을 사용하는 애플리케이션을 위해 데이터 모델 위에 네임스페이스 추상화를 제공하여 저장을 용이하게 한다. 우리 설계에서 네임스페이스는 프로세스의 메모리 주소 공간과 동일하지만, 우리의 네임스페이스는 지속적이며 애플리케이션 수명을 넘어서도 유지된다. 각 네임스페이스는 네임스페이스 내의 PMO를 저장하고 찾기 위한 자체 메타데이터 KV 저장 엔진을 가지고 있습니다. 공유 PM 풀을 사용하는 애플리케이션 또는 과학자들은 이름, 소유자 및 접근 권한과 같은 네임스페이스 메타데이터를 인지하는 경우 다른 네임스페이스의 PMO에 접근할 수 있습니다. 이러한 네임스페이스 관리는 애플리케이션 또는 과학자별로 더 쉽고 간단한 저장 모델을 제공한다.
Metadata Extraction And Storage
MetaData Extraction
우리는 MOSIQS에 대해 중요하게 입증된 일반적인 설계 기술은 중요한 I/O 경로에서의 작업 수를 단순화하고 최소화하는 것이라는 점을 분석했다. PMO 메타데이터와 사용자/애플리케이션 주석 태그를 추출하고 저장하는 주요 아이디어는 공유를 가능하게 하고 빠른 접근, 효율적인 PMO 검색을 위한 인덱스를 구축하고 향후 분석을 가능하게 하는 것이다. 메타데이터 추출기는 애플리케이션 또는 사용자가 주석한 태그를 그룹 또는 PMO에서 추출할 수 있는 서비스로 구현된다. 이는 각 PMO 또는 그룹에 대한 단일 메타데이터 KV 객체를 생성하고 풀 KV 저장소에 삽입한다. MOSIQS는 PMO와 그룹에 대한 메타데이터 객체의 자체 레이아웃을 정의한다.
위 그림은 풀 KV 저장소에 추출되어 저장된 두 유형의 메타데이터 KV 객체, PMO 메타데이터 및 그룹 메타데이터 객체에 대한 개요를 보여준다. OID는 PMO 객체를 나타내며, GID는 그룹 메타데이터 객체를 가리킨다.
그림에서 보여지는 <OID|GID, Value> 쌍의 값 자체는 과학 데이터 형식에 의해 동기를 받은 추가적인 자체 설명 엔터티를 나타낸다. 우리는 값 부분을 헤더 부분과 데이터 부분으로 나눈다. 각 OID에 대해, 헤더는 PMEMoid와 같은 메타데이터 정보를 포함하며, 데이터 부분은 사용자 또는 애플리케이션에 의해 특정 PMO에 제공된 관련 속성 및 주석된 값들을 포함한다. 각 OID는 MOSIQS에 저장된 단일 PMO를 가리킨다.
각 GID에 대해, 헤더는 그림에서 보여지듯이 공유 범위와 함께 그룹의 메타데이터인 주석된 속성을 포함한다. 반면, 데이터 부분은 동일한 속성 세트를 공유하는 PMO 목록과 그들의 고유한 값들을 포함하며, 이는 단일 값 문자열, 정수, 또는 트리 또는 메시와 같은 복합 합성 데이터 구조일 수 있다. 풀 KV 저장소에서 OID와 GID를 <k,v> 메타데이터 객체로 저장하는 동기는 여러 혜택을 제공한다. i) PMO에 대한 쉬운 접근, ii) 유연하고 확장 가능한 태깅, iii) 효율적인 메타데이터 검색 쿼리.
메타데이터 추출의 일관성을 보장하기 위해, 우리는 각 작업을 로깅 접근 방식으로 뒷받침된 트랜잭션으로 캡슐화한다. 성능 저하를 최소화하기 위해, 메타데이터 추출을 background 에서 수행하고 <OID|GID, Value> 쌍은 풀 KV 저장소에서 동기적으로 채워진다. 메타데이터 추출 작업과 <OID|GID, Value> 쌍 채우기는 병렬로 실행된다. 데이터 객체 일관성을 위해, 우리는 libpmemobj가 제공하는 일관성 의미론에 의존한다. 인덱스 힌트를 bypass 하는 주석이 달린 모든 PMO는 메타데이터 추출기에 의해 추출 작업에서 제외된다. 이러한 객체의 경우, 객체 이름에서 PMEMoid로의 매핑만 저장된다.
Object Sharing Controls
MOSIQS를 설계함에 있어 우리의 목표는 과학자들과 애플리케이션이 메모리 수준의 객체 공유를 가능한 한 간단하게 할 수 있도록 하는 것이다. PMDK 는 persistent 포인터, 즉 PMEMoid를 제공하며, 애플리케이션의 충돌과 우아하지 않은 종료를 견딜 수 있도록 내부 가상 주소 매핑의 간접 참조를 메모리 기본 주소로 처리한다. 따라서 다른 애플리케이션이나 과학자들에게 애플리케이션의 경계를 넘어 PMO를 공유하려면 PMO의 영구 포인터를 저장해야 한다. 반면, 다른 애플리케이션 또는 과학자들은 이러한 메모리 포인터 주소를 모르고 대신 객체 네이밍 의미론을 사용하여 객체를 공유한다. 이러한 이유로, 우리는 "Metadata Extraction And Storage" 에서 설명한 대로 풀 KV 저장소에 객체 매핑 정보를 유지한다. 우리는 두 수준, 즉 객체 및 그룹 수준에서 공유 제어를 제공한다. 객체 수준 공유의 경우, 애플리케이션 또는 과학자가 객체를 요청한다. 공유 관리자는 요청을 받고 풀 KV 저장소에서 요청된 객체 매핑을 확인한다. 객체 항목이 발견되면, 공유 관리자는 객체 범위와 속성을 확인한다. 객체가 공유 가능하면, 공유 관리자는 요청한 애플리케이션 또는 과학자에게 PMEMoid를 반환한다.
공유 제어를 더욱 용이하게 하고 POSIX와 유사한 권한 제어에 가깝게 만들기 위해, 그룹은 데이터 공유 오버헤드를 최소화하는 공유 그룹으로 표시될 수 있다. 즉, 파일 시스템에서 디렉토리를 공유하는 것과 비교하여 개별 파일을 공유하는 것과 유사하다. 애플리케이션 또는 협력자는 그룹에 대한 공유 요청을 시작한다. 이 경우, 공유 관리자는 풀 KV 저장소에서 그룹 범위와 속성을 검증한다. 그룹이 전역 및 공유 범위로 주석이 달려 있다면, 요청한 애플리케이션 또는 협력자에게 그룹 데이터 부분에 포함된 OID 목록을 반환한다. 그룹 수준 추상화는 파일 시스템과 유사한 의미론을 제공한다. 예를 들어, 공유 그룹에서 'ls -l' 명령은 공유 파일 시스템 디렉토리에서 'ls -l' 명령과 유사하게 작동한다.
Metadata Search And Query
MOSIQS는 과학자들과 애플리케이션이 풀의 key-value 저장소에 저장된 메타데이터를 사용하여 PMO를 검색하고 쿼리할 수 있게 해준다. 그러나 메타데이터 저장을 위한 간단한 API에도 불구하고, key-value 저장소의 상속된 한계는 과학 애플리케이션과 커뮤니티에서 일반적인 경향인 다중 속성 또는 다차원 검색 쿼리의 부재다. 과학 데이터는 대체로 비구조화되어 있으며 key-value 쌍 속성의 형태로 많은 서술적 메타데이터를 포함하고 있다. 그리고 원하는 데이터 세트를 검색하는 것은 보통 이러한 다중 메타데이터 속성에 의존한다. 또한, 이러한 검색은 종종 과학자와 애플리케이션에 의해 제공된 추가 태그와 주석을 검색 쿼리에 포함한다. 따라서, PMO도 과학 애플리케이션의 성능을 가속화하기 위해 이러한 다중 속성 메타데이터 검색 서비스가 필요하다. 그러나 수십억 개의 메모리 객체에 대해 기존 인덱스 데이터 구조를 단순히 사용하는 것은 방대한 쿼리 검색 공간과 인덱스 메타데이터 저장 공간 오버헤드를 수반한다.
큰 쿼리 검색 공간과 인덱스 저장 공간 오버헤드 문제를 극복하기 위해, 우리는 PMEMKV 위에 영구적이면서 간단한 인덱스 데이터 구조를 도입하고 내장할 계획이다. 이는 다중 메타데이터 속성에 걸쳐 있는 과학적 쿼리를 개선하기 위함이다. 우리는 제안된 영구 인덱스 데이터 구조를 다음 섹션에서 제시할 거다.
GSM: Multi-Attribute Indexing And Querying
GSM(Group Split and Merge)는 PMO 메타데이터 인덱싱 및 쿼리를 위해 설계된 동적 인덱스 데이터 구조다. 이 구조는 메모리 객체들이 서로 공유하는 많은 공통 속성을 가지고 있으며, 이러한 공유된 연관성으로부터 쿼리가 이익을 얻을 수 있다는 특성을 활용한다. 현실적으로, 과학적 객체는 백 개 이상의 속성과 연관될 수 있다. 예를 들어, MIQS는 HDF5 파일 객체가 200개 이상의 고유 속성을 포함하며, 같은 파일 내 다른 객체들과 속성이 중복된다고 언급했다. 우리는 여러 속성과 관련된 과학적 객체의 예를 사용하여 이를 자세히 설명한다. 간단함을 위해, 각 객체마다 3개의 속성만을 사용한다.
아래그림 5(a)는 여러 속성을 가진 여러 객체를 보여준다. 각각의 속성이 하나의 PMO에만 한정되지 않고 여러 PMO 사이에서 공유될 수 있다. 그리고 앞서 Data Model 에서 언급한 바와 같이, 속성은 key-value 쌍이며 많은 객체에서 동일한 속성이 반드시 같은 값을 가지는건 아니다. 즉, 풀의 key-value 저장소에서 객체마다 속성 값이 다를 수 있다.
이러한 연관성을 GSM 인덱스로 변환하기 위해, 각 객체가 생성될 때 메타데이터와 관련 속성/태그를 추출하고 이를 인덱스 관리자에게 추가 처리를 위해 전달한다. 인덱스 관리자는 객체의 관련 속성을 기반으로 GSM 트리 내의 객체 위치를 결정한다. 우리는 공유 또는 중첩 속성을 가진 객체들을 동일한 그룹에 포함시키려고 노력한다.
앞서 언급한 바와 같이, 그룹 객체는 Figure4 그림에 표시된 것처럼 단일 key-value 항목에 여러 객체를 수용할 수 있는 집합 연관 구조로 정의된다. 단일 객체는 여러 그룹과 중첩될 수 있다. 앞으로의 쿼리가 더 많은 연관성을 가진 속성에 대해 수행될 가능성이 높기 때문이다. Figure5(b)는 고유하고 중첩된 속성을 가진 객체로부터 구축된 GSM 인덱스 트리를 보여준다. 우리는 각 그룹과 속성에 중요한 요소인 공유 빈도(SF)를 도입하고 연결한다. 그룹 SF는 그룹에 포함된 속성의 수로 정의되며, 속성 SF는 그룹 내 특정 속성과 관련된 객체의 수를 나타낸다. 예를 들어, Figure5(b)에 표시된 대로 <A, B> 그룹의 SF는 두 속성을 유지하기 때문에 2다. 반면, 속성 A와 B의 공유 빈도는 이 두 속성과 관련된 4개의 PMO가 있기 때문에 4다.
GSM: Insert Operation
애플리케이션 또는 사용자가 그룹을 생성할 때, 그룹 관리자는 기존 그룹에 주석이 없는 한 인덱스 트리의 첫 번째 레벨에 그룹을 간단히 추가한다. 삽입 작업은 객체와 함께 그 태그와 속성을 받는 즉시 시작된다. GSM 인덱스 트리에서 객체를 그룹에 연결하는 두 가지 방법이 있다. 첫 번째는, 객체 생성 시 그룹 주석이 제공되는 애플리케이션 또는 사용자 정의 그룹이다. 이는 우리 이전 작업의 목록 1에서 보여진 바와 같다. 우리는 이러한 객체를 태그된 객체(Tagged Object)라고 한다. 두 번째, 애플리케이션 또는 사용자가 객체에 그룹을 주석하지 않은 경우, 연관된 속성에 기초하여 적절한 그룹을 찾아 객체 배치를 검색한다. 우리는 이러한 객체를 자유 객체(Free Object)라고 한다.
따라서 삽입 알고리즘은 각 객체마다 다르게 처리한다. 태그된 객체에 대해서는 삽입 작업이 간단하다. 우리는 그룹을 선택하고 속성의 SF를 업데이트하며, 그룹 또는 속성 SF가 분할 및 병합 임계값을 충족하는지 확인한다. 분할 및 병합 임계값이 위반되지 않으면, 우리는 풀 key-value 저장소에서 그룹 값을 그에 따라 업데이트한다. 자유 객체의 경우, 우리는 먼저 일치하는 속성을 기반으로 그룹을 검색한다. 그룹이 발견되면, 태그된 객체와 동일한 방식으로 나머지 절차가 수행된다. 자유 객체의 삽입은 속성별로 진행된다. 여러 속성/태그를 가진 자유 객체는 여러 그룹에 중첩될 가능성이 높다. 아래 그림은 GSM 인덱스 트리에서 자유 객체 삽입을 보여준다. 그룹이 발견되지 않으면, 우리는 새 그룹을 생성하고 초기화하며, 객체를 그룹에 연결하고 풀 key-value 저장소에 그룹 메타데이터 객체를 기록한다.
GSM: Split Operation
스레드가 분할 임계값이나 SF 값 위반 없이 GSM 트리에 항목을 삽입할 수 있는 모든 옵션을 소진한 경우, 그룹 분할 작업을 트리거하게 되며, 이는 GSM 인덱스 트리의 확장일 수 있다. 분할 임계값은 쿼리 검색 공간을 최소화하기 위해 애플리케이션 또는 사용자가 구성할 수 있는 조정 가능한 매개변수다. 아래 그림은 GSM 인덱스 트리에서 분할 작업을 보여준다. 이러한 그룹 분할은 쿼리에 대해 높은 병렬성을 제공할 뿐만 아니라, 제공된 쿼리 힌트를 기반으로 그룹을 분할하는 등의 광범위한 쿼리를 가능하게 한다. 예를 들어, Group<A1>은 특정 값보다 낮은 온도를 가진 객체들을 포함하고, Group<A2>는 특정 값보다 높은 온도를 가진 객체들을 포함하는데, 이는 과학 커뮤니티에서 흔한 쿼리 패턴이다. 이러한 분할은 원치 않는 결과를 쿼리에서 제외함으로써 쿼리 비용과 지연 시간을 줄인다.
GSM: Merge Operation
분할 작업과 반대로, SF가 임계값 아래로 떨어질 때 그룹은 인덱스 저장 공간 오버헤드를 최소화하고 쿼리를 가속화하기 위해 병합될 수 있다. 병합 작업은 여러 그룹에서 겹치는 객체들이 있을 때, 즉 여러 그룹의 속성을 공유할 때 필요하다. 병합 작업은 GSM 트리를 압축한다. 병합 작업은 쿼리 기준에 여러 속성이 포함되어 있고, 쿼리 검색 공간에 관계없이 여러 그룹을 반복하여 원하는 데이터셋을 찾아야 할 때 추가 I/O의 수를 최소화하는 데 유용하다. 병합 작업의 또 다른 사용 사례는, 애플리케이션이 사전에 쿼리 힌트를 제공할 때 그룹을 병합하여 쿼리를 효율적으로 실행할 수 있다. 분할과 병합 작업은 애플리케이션, SF 또는 사용자 정의 쿼리 패턴에 따라 수행될 수 있다.
Crash Consistency
GSM 인덱스 트리가 삽입, 분할 또는 병합 작업을 수행할 때 원자적으로 수정되어야 하며, 애플리케이션 오류, 전원 손실 또는 하드웨어 장애로 인한 충돌 후 일관성을 제공해야 한다. 이를 위해 통합(unified) 로깅(ulog) 접근 방식을 사용한다. 즉, 메타데이터 작업에 대한 언두 로그와 데이터 작업에 대한 리두 로그를 사용한다. 언두 로그는 속성 및 그룹 공유 빈도와 같은 그룹 메타데이터의 불일치를 방지한다. 반면, 리두 로그는 그룹, 속성 및 객체 연관성을 보존한다. 우리의 로그 레코드 크기는 8바이트이며, GSM 트리에서 각 작업에 대해 주로 두 개의 로그 레코드를 작성한다. 리두 로그는 그룹 데이터 부분에 영향을 미치며 중복 결과를 견딜 수 있지만, 쿼리가 헤더 부분에 의존하기 때문에 그룹 헤더에서는 중복을 피한다. 헤더에서의 이러한 중복은 거짓 양성(false positive) 결과의 증가로 이어진다.
Multi-Attribute Search And Querying
이전 연구에 따르면, 다중 속성에 기반한 쿼리는 실제 과학 애플리케이션에서 마주치는 가장 흥미롭거나 복잡한 유형의 쿼리다. 실제로 특정 속성은 쿼리의 알려지지 않은 부분일 수 있으며, 실제로 한 사람이 여러 파일에 걸쳐 있는 객체들 사이의 관계를 쿼리할 수 있다(예를 들어, 시뮬레이션 s1에서 시간 t1에 생성된 온도와 압력 속성을 가진 모든 객체를 검색하는 경우). 따라서, 우리는 MOSIQS에서 PMO 에 대한 다중 속성 쿼리 기능을 제공할 계획이다.
여기에서는 MOSIQS가 다중 속성을 포함한 넓은 검색 공간에 걸쳐 있는 쿼리에 어떻게 효율적으로 응답하는지 설명한다. 과학자나 애플리케이션이 특정 필드를 포함하거나 여러 속성에 걸쳐 있는 쿼리를 문자열 형태로 제공하며, 아래 그림에서 보여준다. 예를 들어, Figure8(c)에서 정의된 속성 집합과 관련된 모든 PMO를 검색한다. 쿼리 관리자는 GSM 인덱스 트리에서 쿼리 속성을 가진 그룹을 스캔한다. 모든 속성이 단일 그룹 헤더에 있는 경우, 우리는 풀 key-value 저장소에서 그룹 메타데이터 객체를 읽고 OID 목록을 반환한다.
그러나 다른 그룹이 속성을 저장하고 있는 책임이 있고 각 그룹에 병렬 쿼리가 시작된 경우, 결과는 아래 그림에서 보여진 것처럼 중복 OID를 포함할 수 있다. 중복은 많은 그룹에 걸쳐 겹치는 OID 때문에 발생할 수 있으며, 즉 많은 속성과 관련된 PMO 때문이다. 이러한 쿼리의 경우, 쿼리 결과에서 중복을 최소화하는 것이 중요하다. 따라서 쿼리 관리자는 결과 OID 목록에 대해 합집합 및 정렬 작업을 수행하고 고유한 OID 목록을 반환한다. 참고로, 우리는 지속 메모리 객체에 대한 속성-값 기반 쿼리를 위해 GSM 인덱스 트리를 확장하고 개선하는 것을 향후 작업으로 고려하고 있다.
