블로그

On-Premise Hiatus, In Specifics의 최상위 리뷰

MicroStrategy 온프레미스 플랫폼(MicroStrategy on-premise Platform)은 공식적으로 MicroStrategy Enterprise Platform이며, 현재 더 광범위한 “Strategy One” 브랜드 변경으로 접혀 있으며, 신중하게 읽을 가치가 있는 지원 종료 일정을 게시했습니다. 전환 기간 동안 로드맵 신호는 적어도 종료 날짜만큼 중요합니다. 워크스테이션 로컬 모드 — 사용자가 로컬 데이터 집합에 대해 대시보드를 빌드하고 저장할 수 있는 기능 -은 2026년 3월 릴리스로 지원을 종료합니다. 후속 버전은 해당 파일을 열 수 없습니다. 새로운 브랜딩(Auto Answer, Auto SQL, Auto Bot, Auto Dashboards)에 따라 도입된 여러 AI 기반 기능은 클라우드 에디션에서만 사용할 수 있습니다. 새로운 혁신은 고의적 인 설계에 의해 클라우드 제품으로 흘러가는 것입니다. 온프레미스 제품은 고급이 아닌 유지되고 있습니다.

이 중 어느 것도 숨겨져 있지 않습니다. 공급업체의 자체 문서는 방향을 명시적으로 설명하며 MicroStrategy에서 Strategy로의 브랜드 변경은 회사가 다른 제품을 재배치하고 있다는 신호입니다.

AWS, Azure 또는 GCP에서 관리되는 클라우드 환경으로 마이그레이션할 수 있는 고객의 경우 이는 질서 있는 전환입니다. 할 수없는 고객의 경우, 스퀴즈는 실제이며, 간단한 "구름으로 이동"으로 대답 할 수없는 이유는 다음과 같이 명명 될 자격이 있습니다.

이러한 고객에게 정직한 질문은 현재 플랫폼이 2028 년까지 계속 작동 할 것인지 여부가 아닙니다. 그럴 것이다. 문제는 온프레미스 버전이 보안 패치 수신을 중단하고 공급업체의 제품 팀이 고객이 채택할 수 없는 아키텍처를 최적화하기 위해 5년을 보냈던 10년 후의 분석 전략이 어떤 모습인지입니다.

The "Out-of-the-Box"재검토 가치가있는 가정

두 번째, 더 기술적 인 가정은 전략적 가정과 함께 검토 할 가치가 있습니다. 오랫동안 활동한 MicroStrategy 고객, 특히 Oracle 데이터 웨어하우스를 상대로 운영하는 고객은 데이터베이스와 얼마나 깊이 통합되는지 때문에 플랫폼을 원스톱 샵으로 묘사하는 경우가 많습니다. 가장 자주 인용되는 예는 중간 쿼리 결과를 Oracle Global Temporary Tables로 푸시하여 필수 필터가 있는 대시보드가 수십억 행을 BI 계층으로 드래그하지 않고 임의 크기의 사실 테이블에 대해 작동할 수 있도록 하는 기능입니다.

패턴은 정밀이 요점이기 때문에 정확하게 설명 할 가치가 있습니다. 대시 보드는 매우 큰 사실 테이블 위에 있습니다. 시각화를 렌더링하기 전에 사용자는 고객 세그먼트, 포트폴리오, 브랜치, 보고 기간, 승인된 인구와 같은 필수 필터를 선택해야 합니다. BI 엔진은 선택한 식별자를 가져 와서 데이터베이스 내부의 세션 범위 임시 테이블에 씁니다. 후속 대시보드 쿼리는 이 작은 작업 집합에 대해 큰 사실 테이블에 가입합니다. 최적화 프로그램은 데이터에 가까운 무거운 리프팅을 수행합니다. BI 계층은 필터링되지 않은 인구를 결코 보지 못합니다. BI 서버의 메모리 압력은 경계에 있고, 네트워크 전송은 경계에 머무르고, 데이터베이스는 데이터베이스가 잘하는 작업을 수행합니다.

잘못된 속성은 다음 단계에 있습니다. 패턴이 MicroStrategy에 속한다고 가정합니다. 글로벌 임시 테이블은 Oracle 기능입니다. 데이터베이스에 의해 정의되고 데이터베이스에 의해 관리되며 표준 DDL을 통해 노출됩니다. MicroStrategy가 하는 일은 다중 패스 쿼리 전략의 일부로 해당 SQL의 변형을 자동으로 생성하는 것입니다. 이 변형은 "True Temporary Table"으로 설정된 중간 테이블 유형과 같은 VLDB 속성에 의해 제어됩니다. 정교한 SQL 세대이지만 패턴을 빠르게 만드는 작업은 MicroStrategy가 아닌 Oracle에 의해 수행됩니다.

그것은 평가 질문을 바꿉니다. “질문하는 대신”MicroStrategy의 정확한 Oracle 통합을 이미 보유한 제품은 무엇입니까? 기업은 "물어야 한다"Oracle 부동산이 실제로 필요로하는 워크로드 패턴을 재현 할 수있는 플랫폼은 무엇입니까? " 질문은 비슷하게 들립니다. 그들은 매우 다른 후보자로 이어집니다.

대체 프로젝트가 프론트 엔드에 대해 보여주는 경향이있는 것

두 번째 관찰은 건축적이지 않지만 논쟁하기 어려운 두 번째 관찰은 TURBOARD가 기업 환경에서 기존 MicroStrategy 설치를 대체 한 프로젝트에서 표면화되는 경향이 있습니다. 기업 사용자가 현재 최신 대시 보드링 경험에서 기대하는 것에 대해 평가 된 MicroStrategy 프론트 엔드는 그 나이를 보여주고 있습니다.

이것은 앞서 설명한 온프레미스/클라우드 분기의 예측 가능한 결과입니다. 이것은 또한 많은 MicroStrategy 교체 토론이 혼란스러워지는 곳입니다. 팀은 엔터프라이즈 등급 백엔드 행동과 현대적인 프론트 엔드 유연성 중에서 선택해야한다고 가정합니다. 그 가정은 도전받을 가치가 있습니다.

다른 건축답변

이것은 TURBOARD를 도입하는 것이 유용해지는 곳입니다. MicroStrategy 대체품이 아니라 데이터가 어디에 있어야 하고 BI 계층이 데이터베이스와 어떻게 관련되어야 하는지에 대한 다른 가정 집합을 기반으로 구축된 BI 아키텍처의 예로 사용됩니다.

TURBOARD의 아키텍처는 설계에 따라 하이브리드입니다. 데이터는 Oracle GTT와 같은 패턴을 가능하게 하는 세션 인식, 푸시다운 동작의 종류를 보존하는 기본 ODBC가 아닌 네이티브 데이터베이스 드라이버를 사용하여 최적화된 라이브 연결을 통해 액세스할 수 있습니다. 또는 데이터를 MariaDB ColumnStore, ClickHouse 또는 Vertica와 같은 고성능 열 저장소로 가져올 수 있습니다. 여기서 분석 쿼리는 RAM에 데이터 집합을 거주하지 않고 원주 압축 및 열이 자른 읽기의 이점을 누릴 수 있습니다. 자주 사용하는 쿼리 결과는 Redis에 캐시되며, 캐시된 답변이 여전히 유효한지 또는 소스를 다시 쿼리해야 하는지 여부를 결정하기 위해 지정된 트리거 필드(예: 마지막 업데이트된 타임스탬프)를 확인하는 캐시 트리거 메커니즘이 있습니다.

GTT 사용 사례의 경우 아키텍처가 자연스럽게 구성됩니다. 네이티브 Oracle 드라이버는 GTT가 요구하는 세션 의미 체계를 보존합니다. 매우 큰 사실 테이블에 대한 필수 필터 대시 보드는 필터링 및 집계 작업을 잘 조정 된 BI 계층에서와 마찬가지로 Oracle로 푸시하며 중간 결과는 GTT에서 구체화되어 더 나은 계획을 수립합니다. 오라클이 올바른 실행 엔진이 아닌 워크로드의 경우 - 높은 동시 운영 대시 보드, 과거 데이터에 대한 임시 탐색 - 원주 저장소와 Redis 가속 레이어가 대신 부하를받습니다. 아키텍처는 라이브 쿼리와 인메모리 사이에서 선택을 강요하지 않습니다. 각 작업량이 자신에게 맞는 엔진을 충족하도록 합니다.

이것이 순전히 인메모리 플랫폼에 대해 중요한 이유에 대한 건축적 논의를 위해, TURBOARD와 Qlik Sense의 메모리 모델 비교 전체로 읽을 가치가 있습니다.

건축 결정, 나란히

온프레미스 MicroStrategy 부동산과 하이브리드 TURBOARD 배치의 건축적 차이는 기능 비교가 아니라 비교로 가장 잘 이해됩니다. 각 아키텍처가 가정하는 것.

테이블은 철저하지 않으며 개별 셀은 행이 수행 할 수있는 것보다 더 깊은 대화를 나눌 자격이 있습니다. 그러나 비교의 모양이 요점입니다. 이들은 기업이 실제로 운영하는 제약에 대해 평가되는 두 가지 다른 건축 철학입니다.

원제 : The Decade Ahead

10년 후에도 여전히 관련성이 있는 플랫폼은 공급업체가 원하는 데이터 인프라가 아니라 고객이 실제로 가지고 있는 데이터 인프라를 존중하는 플랫폼입니다. 그것은 온프레미스 컴퓨팅에 대한 낭만적인 선호가 아닙니다. 기업이 규제, 금융, 건축, 조직 등 제약 하에서 운영된다는 인식입니다. 공급업체 로드맵은 저체중인 경향이 있습니다.

2028 질문에 대한 답변이 "우리는 여전히 자체 인프라에서 중요한 분석 워크로드를 실행할 것"이라는 질문에 대한 답변이 있는 조직의 경우 선택은 좁혀지고 있습니다. 현직 플랫폼은 공개적으로 문서화 된 일정에 따라 계속 진행됩니다. 실행 가능한 대안은 데이터베이스 네이티브 실행, 원주 저장소 및 지능형 캐싱을 메모리 내 내 내 베팅이 지불을 중단 할 때의 하락이 아닌 단일 아키텍처의 구성 가능한 부분으로 처리하기 위해 처음부터 설계된 대안입니다.

차이를 볼 준비가 되셨습니까?

MicroStrategy에 대한 대안을 평가하거나 이미 실행 중이며 로드맵이 좁아지는 압력을 느끼기 시작하면 TURBOARD의 아키텍처가 자체 인프라에서 동일한 워크로드를 처리하는 방법을 보여주고 싶습니다.

우리 팀과 함께 연습을 예약하고 자신의 데이터로 플랫폼을 볼 수 있습니다. 압력 없음 - 우리는 오히려 당신이 당신의 특정한 필요를 위해 적당한 적합을 찾아내고 싶습니다.

당신은 또한 우리의 탐구 할 수 있습니다 전체 BI 비교 페이지는 우리가 더 많은 엔터프라이즈 시나리오에 걸쳐 쌓이는 방법을 확인합니다.