BLOG

Sự Gián Đoạn Tại Chỗ, Trong Chi Tính Cụ Thể

Nền tảng tại chỗ của MicroStrategy, chính thức là Nền tảng doanh nghiệp MicroStrategy và hiện được gấp lại dưới thương hiệu “Chiến lược một” rộng lớn hơn, có một lịch trình hỗ trợ cuối cùng được công bố đáng để đọc cẩn thận. Các tín hiệu lộ trình trong giai đoạn chuyển tiếp ít nhất cũng quan trọng như ngày kết thúc. Chế độ cục bộ Workstation - khả năng cho phép người dùng xây dựng và lưu bảng điều khiển so với các tập dữ liệu cục bộ - kết thúc hỗ trợ với bản phát hành tháng 3 năm 2026; các phiên bản tiếp theo không thể mở các tệp đó. Một số khả năng được hỗ trợ bởi AI được giới thiệu dưới thương hiệu mới - Tự động trả lời, Tự động SQL, Bot tự động, Bảng điều khiển tự động - chỉ có trong phiên bản đám mây. Đổi mới mới là, bằng thiết kế có chủ ý, chảy vào sản phẩm đám mây. Sản phẩm tại chỗ đang được duy trì, không tiên tiến.

Không có gì trong số này được giấu. Tài liệu riêng của nhà cung cấp mô tả hướng đi một cách rõ ràng và việc đổi thương hiệu từ MicroStrategy sang Strategy chính nó là một tín hiệu cho thấy công ty đang định vị lại một sản phẩm khác.

Đối với những khách hàng có thể di chuyển sang môi trường đám mây được quản lý trên AWS, Azure hoặc GCP, đây là một quá trình chuyển đổi có trật tự. Đối với những khách hàng không thể, sự siết chặt là có thật, và những lý do nó không thể được trả lời bằng một “di chuyển lên đám mây” đơn giản xứng đáng được đặt tên:

Câu hỏi trung thực cho những khách hàng này không phải là liệu nền tảng hiện tại của họ có tiếp tục hoạt động đến năm 2028 hay không. Nó sẽ. Câu hỏi đặt ra là chiến lược phân tích của họ sẽ như thế nào trong thập kỷ sau đó, khi phiên bản tại chỗ đã ngừng nhận được ngay cả các bản vá bảo mật và nhóm sản phẩm của nhà cung cấp đã dành năm năm để tối ưu hóa cho một kiến trúc mà khách hàng không thể áp dụng.

Giả định “Out-of-the-Box” đáng để xem xét lại

Một giả định thứ hai, kỹ thuật hơn là đáng để kiểm tra cùng với giả định chiến lược. Khách hàng MicroStrategy lâu năm - đặc biệt là những khách hàng chạy đua với kho dữ liệu Oracle - thường mô tả nền tảng này như một cửa hàng một cửa vì nó tích hợp sâu với cơ sở dữ liệu. Ví dụ được trích dẫn thường xuyên nhất là khả năng đẩy kết quả truy vấn trung gian vào Bảng tạm thời toàn cầu của Oracle, cho phép bảng điều khiển có bộ lọc bắt buộc hoạt động chống lại các bảng thực tế có kích thước tùy ý mà không cần kéo hàng tỷ hàng vào bậc BI.

Mô hình này đáng để mô tả chính xác, bởi vì độ chính xác là điểm. Một bảng điều khiển nằm trên một bảng thực tế rất lớn. Trước khi hiển thị trực quan, người dùng phải chọn một bộ lọc bắt buộc - một phân khúc khách hàng, một danh mục đầu tư, một chi nhánh, một kỳ báo cáo, một dân số được ủy quyền. Công cụ BI lấy các định danh đã chọn và ghi chúng vào một bảng tạm thời được hiển thị trong cơ sở dữ liệu. Các truy vấn bảng điều khiển tiếp theo tham gia các bảng thực tế lớn so với bộ làm việc nhỏ này. Trình tối ưu hóa thực hiện việc nâng vật nặng gần với dữ liệu. Tầng BI không bao giờ thấy dân số chưa được lọc. Áp lực bộ nhớ trên máy chủ BI vẫn bị giới hạn; truyền mạng vẫn bị giới hạn; cơ sở dữ liệu thực hiện những gì cơ sở dữ liệu tốt.

Sự phân bổ sai lầm là ở bước tiếp theo: giả sử mô hình thuộc về MicroStrategy. Bảng tạm thời toàn cầu là một tính năng của Oracle. Nó được định nghĩa bởi cơ sở dữ liệu, được quản lý bởi cơ sở dữ liệu và được tiếp xúc thông qua DDL tiêu chuẩn. Những gì MicroStrategy làm là tạo ra các biến thể của SQL đó tự động như một phần của chiến lược truy vấn đa đường chuyền của nó, được điều khiển bởi các thuộc tính VLDB như Loại bảng trung gian được đặt thành “Bảng tạm thời thực sự”. Đó là thế hệ SQL tinh vi - nhưng công việc làm cho mô hình nhanh chóng được thực hiện bởi Oracle, không phải bởi MicroStrategy.

Điều đó thay đổi câu hỏi đánh giá. Thay vì hỏi “sản phẩm nào đã có sự tích hợp chính xác của MicroStrategy Oracle?” doanh nghiệp nên hỏi “nền tảng nào có thể tái tạo mô hình khối lượng công việc mà bất động sản Oracle của chúng ta thực sự cần?” Các câu hỏi nghe có vẻ tương tự. Chúng dẫn đến những danh sách rút gọn rất khác nhau.

Những dự án thay thế nào có xu hướng hiển thị về Frontend

Một quan sát thứ hai, ít kiến trúc hơn nhưng khó tranh luận hơn, có xu hướng xuất hiện trong các dự án mà TURBOARD đã thay thế một cài đặt MicroStrategy hiện có trong môi trường công ty: mặt trận MicroStrategy, được đánh giá so với những gì người dùng doanh nghiệp hiện mong đợi từ trải nghiệm bảng điều khiển hiện đại, đang cho thấy tuổi của nó.

Đây là hậu quả có thể dự đoán được của phân nhánh trên cơ sở / đám mây được mô tả trước đó. Đây cũng là nơi mà nhiều cuộc thảo luận thay thế MicroStrategy trở nên bối rối: các nhóm cho rằng họ phải lựa chọn giữa hành vi phụ trợ cấp doanh nghiệp và tính linh hoạt của frontend hiện đại. Giả định đó xứng đáng bị thách thức.

Một Câu Trả Lời Kiến Trúc Khác

Đây là nơi nó trở nên hữu ích để giới thiệu TURBOARD - không phải là một thay thế MicroStrategy tương tự mà là một ví dụ về kiến trúc BI được xây dựng xung quanh một tập hợp các giả định khác nhau về nơi dữ liệu nên sống và cách cấp BI nên liên quan đến cơ sở dữ liệu.

Kiến trúc của TURBOARD là lai theo thiết kế. Dữ liệu có thể được truy cập thông qua các kết nối trực tiếp được tối ưu hóa bằng cách sử dụng trình điều khiển cơ sở dữ liệu gốc - không phải ODBC chung - bảo tồn loại nhận thức phiên, hành vi đẩy xuống làm cho các mẫu như Oracle GTT trở nên khả thi. Ngoài ra, dữ liệu có thể được nhập vào cửa hàng cột hiệu suất cao như MariaDB ColumnStore, ClickHouse hoặc Vertica, nơi các truy vấn phân tích được hưởng lợi từ việc nén cột và đọc được cắt tỉa cột thay vì giữ bộ dữ liệu cư trú trong RAM. Kết quả truy vấn được sử dụng thường xuyên được lưu trong Redis, với cơ chế kích hoạt bộ nhớ cache kiểm tra trường kích hoạt được chỉ định (ví dụ: dấu thời gian cập nhật cuối) để quyết định xem câu trả lời được lưu trong bộ nhớ cache có còn hiệu lực hay nguồn cần được truy vấn lại hay không.

Đối với trường hợp sử dụng GTT cụ thể, kiến trúc sáng tác một cách tự nhiên. Các trình điều khiển Native Oracle bảo tồn ngữ nghĩa phiên mà GTT yêu cầu. Bảng điều khiển bộ lọc bắt buộc so với các bảng thực tế rất lớn đẩy công việc lọc và tổng hợp của họ xuống Oracle chính xác như họ sẽ theo bất kỳ cấp BI được điều chỉnh tốt nào, với kết quả trung gian được thực hiện trong GTT, nơi tạo ra các kế hoạch tốt hơn. Đối với khối lượng công việc mà Oracle không phải là công cụ thực hiện phù hợp - bảng điều khiển hoạt động đồng thời cao, thăm dò đặc biệt qua dữ liệu lịch sử - cửa hàng cột và lớp tăng tốc Redis thay thế. Kiến trúc không buộc phải lựa chọn giữa truy vấn trực tiếp và ghi nhớ; nó đang để mỗi khối lượng công việc đáp ứng động cơ phù hợp với nó.

Để thảo luận về kiến trúc về lý do tại sao điều này lại quan trọng liên quan đến các nền tảng thuần túy trong bộ nhớ, So sánh của TURBOARD với mô hình bộ nhớ của Qlik Sense là đáng đọc đầy đủ.

Quyết định kiến trúc, Side by Side

Sự khác biệt về kiến trúc giữa bất động sản MicroStrategy tại chỗ và triển khai TURBOARD lai được hiểu rõ nhất không phải là so sánh tính năng mà là so sánh những gì mỗi kiến trúc giả định.

Bảng không đầy đủ, và bất kỳ tế bào cá nhân nào xứng đáng có một cuộc trò chuyện sâu sắc hơn một hàng có thể mang theo. Nhưng hình dạng của sự so sánh là điểm. Đây là hai triết lý kiến trúc khác nhau, được đánh giá dựa trên những hạn chế mà các doanh nghiệp thực sự hoạt động.

Thập Kỷ Phía Trước

Các nền tảng vẫn sẽ có liên quan mười năm kể từ bây giờ là những nền tảng tôn trọng cơ sở hạ tầng dữ liệu mà khách hàng của họ thực sự có, thay vì cơ sở hạ tầng dữ liệu mà nhà cung cấp mong muốn mà họ có. Đó không phải là một sở thích lãng mạn đối với điện toán tại chỗ; đó là một sự thừa nhận rằng các doanh nghiệp hoạt động dưới những ràng buộc - quy định, tài chính, kiến trúc, tổ chức - mà lộ trình của nhà cung cấp có xu hướng thiếu cân.

Đối với các tổ chức có câu trả lời cho câu hỏi năm 2028 là “chúng tôi vẫn sẽ chạy khối lượng công việc phân tích đáng kể trên cơ sở hạ tầng của chính chúng tôi”, sự lựa chọn đang thu hẹp. Nền tảng đương nhiệm, theo lịch trình được ghi lại công khai của riêng mình, tiếp tục. Các lựa chọn thay thế khả thi là những lựa chọn được thiết kế từ đầu để xử lý thực thi cơ sở dữ liệu, lưu trữ cột và bộ nhớ đệm thông minh như các phần có thể kết hợp của một kiến trúc duy nhất thay vì như dự phòng khi đặt cược trong bộ nhớ ngừng trả tiền.

Sẵn sàng để thấy sự khác biệt?

Nếu bạn đang đánh giá các lựa chọn thay thế cho MicroStrategy - hoặc đã chạy nó và bắt đầu cảm thấy áp lực của một lộ trình thu hẹp - chúng tôi muốn cho bạn thấy cách kiến trúc của TURBOARD xử lý khối lượng công việc tương tự trên cơ sở hạ tầng của riêng bạn.

Đặt một hướng dẫn với nhóm của chúng tôi và xem nền tảng đang hoạt động với dữ liệu của riêng bạn. Không có áp lực - chúng tôi muốn bạn tìm thấy sự phù hợp phù hợp với nhu cầu cụ thể của bạn.

Bạn cũng có thể khám phá của chúng tôi So sánh BI đầy đủ trang để xem cách chúng tôi xếp chồng lên nhau trên nhiều tình huống doanh nghiệp hơn nữa.