Чи вважається обгрунтуванням веб-сайту кубом OLAP SQL Server 2012 обґрунтованим?

Мені доручено розробити рішення для великої торгової мережі. Вони хочуть дозволити кожному зі своїх 1,2 мільйонів клієнтів увійти на веб-сайт, щоб побачити розподіл останніх покупок (поточного місяця, попереднього місяця, поточного року) за приблизно 50 категоріями. Дані оновлюватимуться раз на день.

Я думаю створити куб OLAP на базі SQL Server 2012 і дозволити веб-сайту запитувати цей куб безпосередньо, використовуючи такі функції, як проактивне кешування. Однак, будучи розробником по душі, у мене поруч немає досвіду роботи з службами аналізу частин SQL Server, тому я дуже стурбований роботою цього рішення.

Чи підключення веб-сайту безпосередньо до куба OLAP звучить як можливе рішення? Чи реагують такі системи на навантаження від багатьох користувачів приблизно як SQL Server, роблячи це розумним рішенням, чи вони діють зовсім інакше?

Я не чекаю, що користувачі перевірятимуть їх статус дуже часто, і, звичайно, буду використовувати кешування на веб-сервері тощо.

Це можна зробити за допомогою системи OLAP - деякі переваги SSAS для цього типу додатків включають:

• SSAS може легко масштабувати масштаби - тим більше, що це програма, доступна лише для читання, без вимог до зворотного куба.

• Агрегації можна налаштувати для мінімізації вводу / виводу, що дозволяє налаштувати куби для ефективності.

• Клієнтське програмне забезпечення OLAP та управління сторонніми сторонами (веб-та багатий клієнт) легко доступні у багатьох постачальників.

• Видання SQL Server 2012 Business Intelligence має майже всі можливості масштабування для SSAS, тому його можна використовувати як економічно вигідну платформу для фронтальних кубів для бази даних корпоративного видання SQL Server (або третьої сторони). Зауважте, що ліцензування може бути проблемою для цього, оскільки видання BI є лише ліцензією CAL.

• SSAS має функцію передачі даних, яку можна використати для аналізу даних кошика для покупок і передачі на веб-сайті функції "запропонованих покупок".

З іншого боку, вимога полягає в тому, щоб показати відносно обмежений набір даних, тому можливість спеціальних функцій нарізання кубиків OLAP-сервера може бути надмірною як у витратах на програмне забезпечення, так і у вартості апаратної інфраструктури для його запуску ( SSAS досить голодний ресурсів). Можливо, ви зможете досягти вашої негайної потреби за допомогою періодично оновленої підсумкової бази даних та робити це з меншими витратами на обладнання та ліцензування.

З першого погляду, я вважаю, що OLAP, ймовірно, не потрібен для виконання вашої існуючої вимоги. Однак це, безумовно, можна зробити так, і ви можете отримати деякий пробіг від функцій пошуку даних, щоб забезпечити функцію "пропоновані покупки".

SSAS - дуже м'ясна тема. Майже ніхто з того, що ви знаєте про двигун бази даних, не може бути застосований до служб аналізу. Якщо єдиною метою було б забезпечити зворотній зв'язок для цього звіту, то швидкість роботи служб аналізу та впровадження бази даних OLAP була б досить істотною витратою порівняно з більш звичайним підходом періодичного оновлення деяких зведених даних, що зберігаються в реляційну базу даних або створення звіту Служб звітування, який запускається з періодично створеного знімка виконання.

Це означає, що якщо вам справді потрібна довготривала потреба у деяких сильних сторонах Служб аналізу, таких як спеціальна багатовимірна звітність та вирази MDX (ви можете зробити дуже цікаві речі), і ви працюєте з дуже великим сховище даних, що дозволяє йому значно перевершити реляційну базу даних, тоді можна було б її вивчити. Однак не сподівайтесь забрати його за день.

Так, це дуже розумне рішення. У мене є клієнти, які мають SSAS з подібним навантаженням, і він працює чудово. Як і будь-який дизайн бази даних, продуктивність, яку ви отримуєте, буде безпосередньо пов'язана з тим, наскільки хороший дизайн куба.