O backup de um site por um cubo OLAP do SQL Server 2012 é considerado razoável?

11

Fui encarregado de arquitetar uma solução para uma grande cadeia de varejo. Eles desejam permitir que cada um de seus 1,2 milhão de clientes efetue logon em um site para ver a distribuição de compras recentes (mês atual, mês anterior, ano a ano) em mais de 50 categorias. Os dados serão atualizados uma vez por dia.

Estou pensando em criar um cubo OLAP baseado no SQL Server 2012 e deixar o site consultar esse cubo diretamente, aproveitando recursos como o cache proativo. No entanto, como desenvolvedor no coração, não tenho quase nenhuma experiência com as partes de serviços de análise do SQL Server, por isso estou bastante preocupado com o desempenho dessa solução.

A conexão de um site diretamente a um cubo OLAP parece uma solução viável? Esses sistemas reagem à carga de vários usuários aproximadamente como um SQL Server, tornando essa uma solução razoável ou agem de maneira completamente diferente?

Não espero que os usuários verifiquem seu status com muita frequência e, é claro, usarei o cache no servidor da web etc.

Runa
fonte

Respostas:

11

Você pode fazer isso com um sistema OLAP - alguns dos benefícios do SSAS para esse tipo de aplicativo incluem:

  • O SSAS pode ser dimensionado facilmente - especialmente porque esse é um aplicativo somente leitura sem requisitos para write-back de cubo.

  • As agregações podem ser ajustadas para minimizar a E / S, permitindo que os cubos sejam ajustados para eficiência.

  • O software do cliente OLAP e os controles de terceiros (Web e Rich Client) estão prontamente disponíveis em vários fornecedores.

  • O SQL Server 2012 Business Intelligence edition possui praticamente todos os recursos de escalabilidade do SSAS; portanto, ele pode ser usado como uma plataforma econômica para fazer frente aos cubos de um banco de dados do SQL Server Enterprise Edition (ou de terceiros). Observe que o licenciamento pode ser um problema para isso, pois a edição de BI é apenas para CAL.

  • O SSAS possui uma função de mineração de dados que pode ser usada para fazer uma análise do carrinho de compras dos dados e alimentar um recurso de 'compras sugeridas' no site.

Por outro lado, o requisito é mostrar um conjunto de dados relativamente restrito, para que o recurso ad-hoc de fatia e dado de um servidor OLAP possa ser um exagero, tanto no custo do software quanto na infraestrutura de hardware para executá-lo ( O SSAS tem muita fome de recursos). Você provavelmente poderia atingir seus requisitos imediatos com um banco de dados de resumo atualizado periodicamente e fazê-lo com menos custos de hardware e licenciamento.

À primeira vista, sugiro que o OLAP provavelmente não seja necessário para atender aos seus requisitos existentes. No entanto, isso certamente poderia ser feito dessa maneira e você pode obter alguma milhagem dos recursos de mineração de dados para fornecer um recurso de 'compras sugeridas'.

ConcernedOfTunbridgeWells
fonte
3
Além disso, quando os cubos estiverem lá, você poderá encontrar maneiras de usá-los. Os data warehouses estão disponíveis para as perguntas que ainda não são conhecidas - as conhecidas são algo que uma consulta simples pode lidar. Definitivamente, eu faria um protótipo baseado em cubos OLAP e depois o apresentaria às partes interessadas e explicaria a flexibilidade adicional.
TomTom
1
Suspeito que a primeira opção (com SSAS e cubos) já esteja em vigor para os analistas da cadeia de varejo. No varejo, eles geralmente fazem o trabalho de mineração de dados, mas ainda não o entregam aos clientes finais. PS: Você pode ler uma breve revisão sobre alguns controles de BI ativos para aplicativos Web (no ASP.NET) na minha resposta SO .
Marian
MUITO provável - que eles já tenham alguns cubos.
TomTom
7

O SSAS é um tópico muito difícil. Quase nada do que você sabe sobre o mecanismo de banco de dados pode ser aplicado ao Analysis Services. Se o único objetivo fosse fornecer um back-end para este relatório, acelerar o Analysis Services e implementar o banco de dados OLAP seria uma sobrecarga bastante substancial em comparação com uma abordagem mais convencional de atualizar periodicamente alguns dados de resumo armazenados em um banco de dados relacional ou a criação de um relatório do Reporting Services que é executado a partir de um instantâneo de execução gerado periodicamente.

Dito isso, se você realmente tem uma necessidade de longo prazo de alguns dos pontos fortes do Analysis Services, como relatórios multidimensionais ad-hoc e expressões MDX (você pode fazer algumas coisas bem legais), e está trabalhando com um número muito grande data warehouse que permite que ele supere significativamente um banco de dados relacional, pode valer a pena aprendê-lo. Não espere buscá-lo em um dia, no entanto.

db2
fonte
3

Sim, esta é uma solução muito razoável. Eu tenho clientes que têm SSAS com carga semelhante e funciona bem. Como qualquer design de banco de dados, o desempenho obtido estará diretamente relacionado à qualidade do design do cubo.

mrdenny
fonte