BLOG

Hai kiến trúc, một thời gian ngắn

Sơ đồ trên cho thấy các lớp của TURBOARD phù hợp với nhau như thế nào. Phần còn lại của bài kiểm tra những gì mỗi kiến trúc làm khi các điều kiện xung quanh nó trở nên khó khăn hơn.

Kịch bản công bằng: khi trong ký ức thắng

Đáng để nói rõ ràng: khi tập dữ liệu phù hợp thoải mái trong RAM, khi đồng thời khiêm tốn và khi môi trường có kích thước cho ứng dụng, Qlik Sense thực sự nhanh. Công cụ liên kết là một phần kỹ thuật trưởng thành và trải nghiệm người dùng nhấp qua các bộ lọc và xem các tập hợp tính toán lại trong mili giây là, vào ngày của nó, tuyệt vời. Đối với việc triển khai bộ phận, các ứng dụng phân tích tập trung và khối lượng công việc mà mô hình dữ liệu ổn định và được hiểu rõ, cách tiếp cận trong bộ nhớ là một thế mạnh thực sự.

Đây là kịch bản mà hầu hết các cuộc biểu tình sản phẩm được xây dựng xung quanh. Đó cũng là kịch bản cho bạn biết ít nhất về cách một nền tảng sẽ hoạt động một năm vào sản xuất, sau khi dữ liệu đã phát triển, cơ sở người dùng đã mở rộng và ba ứng dụng khác đã được triển khai trên cùng một máy chủ.

Kịch bản mở rộng quy mô: nơi các kiến trúc phân kỳ

Tài liệu hỗ trợ riêng của Qlik mô tả chi tiết mô hình bộ nhớ. Động cơ hoạt động chống lại hai ngưỡng có thể cấu hình được gọi là Bộ làm việc thấp và bộ làm việc cao, với giá trị mặc định là 70% và 90% RAM vật lý tương ứng. Dưới ngưỡng thấp, công cụ vẫn giữ kết quả tính toán được lưu trong bộ nhớ cache một cách tích cực, trên nguyên tắc bộ nhớ không sử dụng bị lãng phí bộ nhớ. Khi ngưỡng thấp được vượt qua, công cụ bắt đầu loại bỏ các kết quả được lưu trữ để nhường chỗ cho những cái mới, ưu tiên trục xuất theo độ tuổi, kích thước và thời gian tính toán ban đầu. Khi ngưỡng cao được vượt qua, bộ nhớ đệm có hiệu quả dừng lại và tệp trang của hệ điều hành có thể được tham gia để giữ cho động cơ tồn tại. Tài liệu của Qlik lưu ý rằng việc sử dụng tệp trang có thể làm giảm hiệu suất đáng kể.

Cơ chế của những gì xảy ra giữa các ngưỡng đó quan trọng hơn chính các ngưỡng. Mỗi kết quả được lưu trữ được đuổi ra là một tính toán sẽ cần phải được tính toán lại vào lần tiếp theo người dùng yêu cầu nó. Khi trục xuất tăng tốc, tải tính toán chuyển từ bộ nhớ sang CPU. Trong một môi trường đồng thời cao, nơi nhiều người dùng đồng thời kích hoạt các phép tính không còn câu trả lời được lưu trong bộ nhớ cache, CPU trở thành nút cổ chai mới - và không giống như áp suất bộ nhớ, áp suất CPU biểu hiện trực tiếp dưới dạng độ trễ có thể nhìn thấy của người dùng: bảng điều khiển treo, bộ lọc mất vài giây để áp dụng, các phiên thời gian ra ngoài.

Cách tiếp cận hybrid của TURBOARD phân phối tải khác nhau. Bộ dữ liệu chưa được tổng hợp không cần phải chiếm RAM, bởi vì cửa hàng columnar được thiết kế để trả lời các truy vấn phân tích hiệu quả từ đĩa - chỉ đọc các cột mà một truy vấn chạm vào, khai thác nén nặng và phục vụ các tập hợp ở tốc độ cần xử lý trong bộ nhớ một thập kỷ trước. Tải gia tăng giữ cho cửa hàng columnar tươi mà không buộc phải tải lại hoàn toàn lặp đi lặp lại, có nghĩa là người dùng trải nghiệm dữ liệu gần như trực tiếp mà không có chi phí bộ nhớ giữ bộ dữ liệu đầy đủ trong RAM. Bộ nhớ cache Redis sau đó tăng tốc các truy vấn được hưởng lợi nhiều nhất từ tăng tốc - trong bất kỳ triển khai doanh nghiệp thực sự nào, là một tập hợp con nhỏ của tổng khối lượng truy vấn. Phần tiếp theo giải thích tại sao.

Dữ liệu trực tiếp: vấn đề Khám phá trực tiếp

Câu trả lời của Qlik cho khối lượng công việc vượt quá bộ nhớ có sẵn là Direct Discovery, một chế độ trong đó các trường kích thước được tải vào bộ nhớ trong khi các trường đo vẫn còn trong cơ sở dữ liệu nguồn và được truy vấn theo yêu cầu. Mục đích thiết kế là hợp lý; những hạn chế được ghi lại là đáng kể.

Đối với TURBOARD, kết nối trực tiếp không phải là một giải pháp thay thế cho áp suất bộ nhớ. Đây là một phần hạng nhất của kiến trúc. Trình điều khiển cơ sở dữ liệu gốc - thay vì các kết nối ODBC chung - cung cấp quyền truy cập trực tiếp, hiệu suất cao vào các hệ thống nguồn, bao gồm các nền tảng dữ liệu lớn như Apache Kudu. Cơ chế kích hoạt bộ nhớ cache ngăn cơ sở dữ liệu nguồn bị ảnh hưởng trên mọi nhấp chuột của người dùng: TURBOARD xem một trường kích hoạt được chỉ định (chẳng hạn như dấu thời gian được cập nhật cuối cùng) và phục vụ các kết quả được lưu trong bộ nhớ cache từ Redis khi dữ liệu cơ bản không thay đổi, chỉ truy vấn nguồn khi trình kích hoạt cho biết dữ liệu mới có sẵn. Các tính năng phân tích nâng cao vẫn hoàn toàn có sẵn cho dù một tiện ích đang đọc từ bộ nhớ cache, từ cửa hàng cột hoặc từ một nguồn trực tiếp. Một bảng điều khiển duy nhất có thể kết hợp cả ba mà không cần thỏa hiệp.

Cái nhìn sâu sắc của Pareto, và bằng sáng chế bảo vệ nó

Trong bất kỳ triển khai BI doanh nghiệp nào, hành vi của người dùng tuân theo một mô hình có thể dự đoán được. Khoảng 80% người dùng quay lại nhiều lần vào cùng một bảng điều khiển cốt lõi - tóm tắt điều hành, báo cáo hiệu suất hàng tháng, triển khai khu vực. 20% còn lại là người dùng nguồn chạy các truy vấn đặc biệt có thể không bao giờ chạy lại dưới dạng tương tự. Hàm ý cho quản lý bộ nhớ là trực tiếp: không phải tất cả các kết quả được lưu trữ đều có giá trị như nhau và một hệ thống coi chúng tương đương là lãng phí tài nguyên đắt nhất của nó.

Mô hình trục xuất của Qlik là mù hành vi. Kết quả được lưu trữ được loại bỏ dựa trên độ tuổi, kích thước và thời gian tính toán ban đầu - không dựa trên tần suất người dùng thực tế thực sự yêu cầu chúng. Khi bộ nhớ lấp đầy, công cụ không thể phân biệt bảng điều khiển mà toàn bộ nhóm điều hành kiểm tra mỗi buổi sáng từ một truy vấn một lần đã xảy ra được lưu trữ gần đây.

TURBOARD có cách tiếp cận ngược lại. Mỗi khi một báo cáo được xem, điểm phổ biến của nó được tăng lên trong một Bộ phân loại màu đỏ - một cấu trúc dữ liệu được thiết kế cho chính xác loại mẫu truy cập được xếp hạng này. Hệ thống duy trì một bảng xếp hạng liên tục trong đó các báo cáo thực sự đang được sử dụng và sử dụng bảng xếp hạng đó để quyết định những gì vẫn còn trong bộ nhớ cache khi bộ nhớ chặt chẽ. Các báo cáo được yêu cầu nhiều nhất được bảo vệ trong Redis, nơi chúng trở lại với độ trễ bằng không cho phần lớn người dùng phụ thuộc vào chúng. Các truy vấn của người dùng nguồn bỏ lỡ bộ nhớ cache được chuyển đến cửa hàng cột hoặc nguồn trực tiếp - cả hai đều được thiết kế để trả lời các truy vấn đó một cách nhanh chóng mà không thay thế nội dung được lưu trữ có giá trị cao.

Cạnh nhau

Kết luận

Qlik Sense vẫn là một nền tảng phân tích trong bộ nhớ có khả năng và trong các điều kiện mà nó được thiết kế cho - các bộ dữ liệu giới hạn, đồng thời có thể dự đoán, cung cấp bộ nhớ hào phóng - nó hoạt động tốt. Câu hỏi mà bài đăng này đã cố gắng trả lời là điều gì xảy ra khi những điều kiện đó trở nên khó đáp ứng hơn. Khối lượng dữ liệu không bị thu hẹp. Kỳ vọng đồng thời không được thư giãn. Và chi phí và tính khả dụng của bộ nhớ, lần đầu tiên trong một thời gian dài, đang đi sai hướng.

Kiến trúc của TURBOARD là một đặt cược rằng thập kỷ tiếp theo của hiệu suất BI sẽ giành được bởi các nền tảng mà sử dụng trí nhớ một cách thông minh hơn là dồi dào. Truy cập dữ liệu kết hợp, lưu trữ cột, kết nối trực tiếp gốc và bộ nhớ cache được cấp bằng sáng chế cho phép TURBOARD cung cấp hiệu suất quy mô doanh nghiệp trên ngân sách bộ nhớ mà các kiến trúc trong ký ức hoàn toàn phải vật lộn để sống bên trong.

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

Nếu bạn đang đánh giá Qlik Sense – hoặc đã chạy nó và bắt đầu cảm nhận được áp lực bộ nhớ được mô tả trong bài đăng này – chúng tôi muốn cho bạn thấy kiến trúc lai của TURBOARD xử lý cùng một khối lượng công việc như thế nào.

Đặ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.