Việc sao lưu trang web bằng khối OLAP SQL Server 2012 có được coi là hợp lý không?

Tôi đã được giao nhiệm vụ kiến ​​trúc một giải pháp cho một chuỗi bán lẻ lớn. Họ muốn cho phép mỗi 1,2 triệu khách hàng của mình đăng nhập vào một trang web để xem phân phối các giao dịch mua gần đây (tháng hiện tại, tháng trước, năm nay) trên khoảng 50 danh mục. Dữ liệu sẽ được cập nhật mỗi ngày một lần.

Tôi đang nghĩ đến việc đưa lên một khối OLAP dựa trên SQL Server 2012 và để trang web truy vấn trực tiếp khối này, tận dụng các tính năng như lưu trữ chủ động. Tuy nhiên, là một nhà phát triển, tôi không có kinh nghiệm với các bộ phận dịch vụ phân tích của SQL Server, vì vậy tôi khá lo ngại về hiệu suất của giải pháp này.

Việc kết nối một trang web trực tiếp với khối OLAP có giống như một giải pháp khả thi không? Các hệ thống như vậy có phản ứng với tải từ nhiều người dùng gần giống như SQL Server không, biến đây thành một giải pháp hợp lý hay chúng hoạt động hoàn toàn khác nhau?

Tôi không mong đợi người dùng kiểm tra trạng thái của họ rất thường xuyên và tất nhiên tôi sẽ sử dụng bộ nhớ đệm trên máy chủ web, v.v.

Bạn có thể làm điều này với hệ thống OLAP - một số lợi ích của SSAS cho loại ứng dụng này bao gồm:

• SSAS có thể dễ dàng mở rộng ra - đặc biệt vì đây là một ứng dụng chỉ đọc mà không có yêu cầu nào cho việc viết khối.

• Các tập hợp có thể được điều chỉnh để giảm thiểu I / O cho phép các khối được điều chỉnh cho hiệu quả.

• Phần mềm máy khách OLAP và kiểm soát của bên thứ ba (web và máy khách phong phú) có sẵn từ một số nhà cung cấp.

• Phiên bản SQL Server 2012 Business Intelligence có khá nhiều tính năng mở rộng cho SSAS, do đó, nó có thể được sử dụng làm nền tảng hiệu quả về chi phí cho các khối trước cho cơ sở dữ liệu của phiên bản doanh nghiệp SQL Server (hoặc bên thứ ba). Lưu ý rằng việc cấp phép có thể là một vấn đề đối với điều này vì phiên bản BI chỉ dành cho CAL.

• SSAS có chức năng khai thác dữ liệu có thể được sử dụng để phân tích giỏ mua hàng trên dữ liệu và cung cấp tính năng 'đề xuất mua hàng' trên trang web.

Mặt khác, yêu cầu là hiển thị một tập dữ liệu tương đối hạn chế, do đó, khả năng cắt lát đặc biệt của máy chủ OLAP có thể là quá mức, cả về chi phí phần mềm và chi phí cho cơ sở hạ tầng phần cứng để chạy nó ( SSAS khá đói tài nguyên). Bạn có thể có thể đạt được yêu cầu trước mắt của mình với cơ sở dữ liệu tóm tắt được làm mới định kỳ và thực hiện nó với chi phí cấp phép và phần cứng ít hơn.

Từ cái nhìn đầu tiên, tôi muốn đề xuất OLAP có lẽ không cần thiết để đáp ứng yêu cầu hiện có của bạn. Tuy nhiên, nó chắc chắn có thể được thực hiện theo cách này và bạn có thể nhận được một số dặm từ các tính năng khai thác dữ liệu để cung cấp tính năng 'đề xuất mua hàng'.

SSAS là một chủ đề rất thịt. Hầu như không có gì bạn biết về công cụ cơ sở dữ liệu có thể được áp dụng cho Dịch vụ phân tích. Nếu mục tiêu duy nhất là cung cấp một bản sao lưu cho báo cáo này, thì việc tăng tốc độ trên Dịch vụ phân tích và triển khai cơ sở dữ liệu OLAP sẽ là một chi phí khá lớn so với cách tiếp cận thông thường hơn là làm mới định kỳ một số dữ liệu tóm tắt được lưu trữ trong một cơ sở dữ liệu quan hệ hoặc tạo báo cáo Dịch vụ báo cáo chạy từ ảnh chụp thực thi được tạo định kỳ.

Điều đó nói rằng, nếu bạn thực sự có nhu cầu lâu dài đối với một số điểm mạnh của Dịch vụ phân tích, chẳng hạn như báo cáo đa chiều đặc biệt và biểu thức MDX (bạn có thể thực hiện một số nội dung khá hay) và bạn đang làm việc với một công cụ rất lớn kho dữ liệu cho phép nó vượt trội đáng kể so với cơ sở dữ liệu quan hệ, sau đó có thể đáng để học nó. Đừng mong đợi để nhận nó trong một ngày, tuy nhiên.

Vâng, đây là một giải pháp rất hợp lý. Tôi đã có những khách hàng có SSAS với tải tương tự và nó hoạt động tốt. Giống như bất kỳ thiết kế cơ sở dữ liệu nào, hiệu suất bạn nhận được sẽ liên quan trực tiếp đến việc thiết kế khối tốt như thế nào.