OLAP 내부에 대해 아는 사람이 있습니까?

Question

데이터베이스 내부에 대해 조금 알고 있습니다. 디스크 및 BTREE 인덱스의 ISAM 구조를 사용하여 실제로 작고 간단한 관계형 데이터베이스 엔진을 구현했습니다. 재미 있고 교육적이었습니다. 나는 데이터베이스 스키마를 신중하게 설계하고 쿼리를 작성하는 것에 대해 훨씬 더 인식하고 있다는 것을 알고 있습니다.

그러나 다차원 OLAP 데이터 모델에 대해서는 아무것도 모르고 인터넷에서 유용한 정보를 찾는 데 어려움을 겪었습니다.

정보는 디스크에 어떻게 저장됩니까? 큐브로 구성된 데이터 구조는 무엇입니까? MOLAP 모델에 열과 레코드가있는 테이블을 사용하지 않으면 ... 뭐? 특히 고수 데이터에서 어떤 종류의 데이터 구조가 Molap 모델을 그렇게 효율적으로 만드는가? MOLAP 구현은 RDBMS 인덱스와 유사한 것을 사용합니까?

AD HOC Queries를 처리하는 데 OLAP 서버가 훨씬 더 나은 이유는 무엇입니까? 동일한 종류의 집계가 취할 수 있습니다 시간 일반적인 관계형 데이터베이스에서 처리하려면 OLTP 큐브에서 밀리 초로 처리 될 수 있습니다. 이를 가능하게하는 모델의 기본 역학은 무엇입니까?

Answer 1

나는 OLAP 큐브가하는 일을 모방 한 몇 가지 시스템을 구현했으며, 여기에 우리가 일을하기 위해 한 몇 가지 일이 있습니다.

1) 핵심 데이터는 차원 배열, 모두 메모리로 유지되었으며 모든 키는 포인터의 계층 구조를 통해 기본 배열로 구현되었습니다. 이런 식으로 동일한 데이터에 대해 여러 다른 키 세트를 가질 수 있습니다. 배열의 데이터는 팩트 테이블과 동일하며 종종 몇 가지 데이터 만 갖습니다.

2) 기본 배열은 종종 드물었으므로 일단 생성되면 모든 빈 셀을 제거하여 메모리를 저장하는 데 사용했지만 많은 하드 코어 포인터 산술이지만 작동했습니다.

3) 열쇠의 신속 조건이 있었기 때문에, 우리는 일상을 쉽게 작성하여 계층 구조를 쉽게 드릴/위로 올릴 수 있습니다. 예를 들어, 우리는 몇 개월 키를 거쳐 며칠 및/또는 몇 주에 매핑되어 달의 연도에 액세스 할 것입니다. 각 레벨에서 우리는 큐브 구축의 일부로 데이터를 집계합니다.

4) 우리는 어떤 종류의 쿼리 언어도 구현하지 않았지만 모든 축에서 드릴 다운을 지원했으며 (가장 큰 큐브에서 최대 7 명) 사용자가 좋아하는 UI에 직접 연결되었습니다.

5) 우리는 C ++에서 핵심 물건을 구현했지만 요즘에는 C#이 충분히 빠를 수 있지만 희소 배열을 구현하는 방법에 대해 걱정합니다.

도움이되기를 바랍니다. 흥미로운 소리.

Answer 2

그 책 Microsoft SQL Server 2008 분석 서비스는 해제되었습니다 SSAS 2008의 일부 특성을 상세하게 설명합니다. 그것은 "여기에 SSA가 어떻게 작동하는지 정확히 여기에 있습니다"는 아니지만, 특히 데이터 구조 측면에서는 매우 암시 적입니다. (정확한 알고리즘에 대해서는 상세하거나 구체적이지 않습니다.)이 지역의 아마추어 로서이 책에서 수집 한 몇 가지 사항. 이것은 SSAS Molap에 관한 모든 것입니다.

• 다차원 큐브에 대한 모든 이야기에도 불구하고 사실 표 (일명 측정 그룹) 데이터는 여전히 첫 번째 근사치이며 궁극적으로 기본적으로 2D 테이블, 사실 당 1 행에 저장됩니다. 다수의 OLAP 작업은 궁극적으로 2D 테이블의 행을 반복하는 것으로 구성됩니다.
• 그러나 데이터는 해당 SQL 테이블 내부보다 MOLAP 내부의 잠재적으로 훨씬 작습니다. 한 가지 트릭은 각 고유 한 문자열이 "String Store"에 한 번만 저장된다는 것입니다. 그런 다음 데이터 구조는 문자열을보다 컴팩트 한 형태 (기본적으로 문자열 ID)로 참조 할 수 있습니다. SSA는 또한 Molap 매장 내 행을 어떤 형태로 압축합니다. 이 수축은 더 많은 데이터를 RAM에 동시에 유지할 수 있다고 가정합니다.
• 마찬가지로 SSA는 종종 전체 데이터 세트가 아닌 데이터의 하위 집합을 반복 할 수 있습니다. 몇 가지 메커니즘이 작동 중입니다.
  • 기본적으로 SSA는 각 차원/속성 값에 대한 해시 색인을 빌드합니다. 따라서 디스크의 어떤 페이지가 예를 들어, 연도 = 1997의 관련 데이터를 포함하는 "즉시"를 알고 있습니다.
  • 데이터의 관련 서브 세트가 전체 데이터 세트와 별개로 RAM에 저장되는 캐싱 아키텍처가 있습니다. 예를 들어, 필드가 몇 개 밖에 걸리지 않고 1997 년의 데이터와 관련이있는 하위 큐브를 캐시했을 수 있습니다. 쿼리가 1997 년 정도만 묻는 경우 해당 하위 큐브를 통해서만 반복하여 속도를 높일 것입니다. . (그러나 "하위 큐브"는 첫 번째 근사치에, 2D 테이블 만 있습니다.)
  • 골재가 사전 정의 된 경우,이 작은 서브 세트는 단순히 주문시 계산/캐싱이 아닌 큐브 처리 시간에 미리 계산할 수 있습니다.
• SSAS 사실 테이블 행은 고정 된 크기로 어떤 형태로도 도움이됩니다. (SQL에서는 구본에서 가변 폭을 넓은 문자열 열이있을 수 있습니다.)
• 캐싱 아키텍처는 또한 일단 집계가 계산되면 디스크에서 리치를 다시 치우고 반복해서 재 계산 할 필요가 없음을 의미합니다.

이것들은 어쨌든 SSA에서 플레이하는 요소 중 일부입니다. 나는 다른 중요한 것들도 없다고 주장 할 수 없습니다.