Procurando conselhos sobre como integrar dados de mais de 100 DBs de clientes em um banco de dados centralizado de relatórios

10

Sou desenvolvedor SQL (não DBA ou arquiteto) de uma empresa SaaS pequena (~ 50 funcionários). Tenho a tarefa de descobrir como:

  1. Descarregue relatórios operacionais de nossos mais de 100 bancos de dados OLTP
  2. Permitir que esses relatórios sejam executados com dados de vários bancos de dados do cliente
  3. Posicione nossa empresa para fornecer mais soluções baseadas em análises no futuro

Eu li vários artigos sobre várias tecnologias, como replicação transacional (especificamente o modelo de assinante muitos-para-um / central), SQL service broker, envio de logs, Change Tracking (CT) e Change Data Capture (CDC). isso é somente corporativo) e não tenho certeza de qual caminho é melhor seguir.

Espero que alguns de vocês com experiência em integração possam ter encontrado uma configuração semelhante à nossa e possam me indicar um caminho bem-sucedido ou me direcionar para alguns recursos que seriam úteis.

Devido a restrições de custo, nossa solução deve funcionar no SQL Server Standard Edition. Além disso, a solução deve ser razoável para apoiar / manter dentro de nossa pequena organização.

Configuração básica:

Atualmente, temos mais de 100 bancos de dados de clientes individuais, a maioria implantada em servidores SQL em nosso data center, mas alguns implantados em servidores clientes em seus datacenters nos quais podemos conectar remotamente. Esses são todos os bancos de dados do SQL Server 2008 R2, mas planejamos atualizar para o SQL 2016 em breve.

Usamos projetos de banco de dados e dacpacs para garantir que o esquema seja o mesmo em todos os bancos de dados clientes que seriam integrados. No entanto, como não forçamos todos os clientes a atualizar para novas versões ao mesmo tempo, algumas diferenças de esquema são possíveis entre as atualizações. A solução deve ser flexível o suficiente para não ser interrompida se o cliente A estiver na versão 1.0 do software e o cliente B estiver na versão 1.1.

Atualmente, os relatórios operacionais são executados diretamente do banco de dados OLTP de cada cliente. Estamos preocupados com o impacto que isso terá no desempenho do aplicativo se não o descarregarmos.

Requisitos de alto nível:

Nossos clientes são departamentos de processamento estéril (SPDs) de hospitais que desejam relatórios atualizados sobre o que foram processados ​​até o momento, onde está o inventário, etc. Como um dos principais objetivos desse esforço é oferecer melhor suporte aos relatórios operacionais, gostaríamos que os dados estivessem o mais próximo possível do tempo real para continuar atendendo às necessidades dos clientes.

Atualmente, temos alguns SPDs em bancos de dados separados, que na verdade fazem parte do mesmo sistema hospitalar. Esses clientes desejam a capacidade de relatar todos os SPDs em seus sistemas.

Estrategicamente falando, gostaríamos da capacidade de agregar dados com facilidade em todos os nossos clientes para apoiar nossas iniciativas de análise interna. Nossa expectativa é que possamos usar os dados operacionais coletados como uma fonte para data marts / warehouse.

Pensamentos até agora:

A replicação transacional parece fornecer a solução mais "em tempo real". Achei esta resposta especialmente útil, mas estou preocupado que, com o potencial de diferenças de esquema, ela não funcione para nós: Replicação muitos-para-um do SQL Server

O envio de logs não parece ideal, pois o log não pode ser restaurado enquanto as consultas estão ativas. Eu tenho que expulsar todo mundo para que o log possa restaurar ou os dados ficarão obsoletos. Não estou claro se esse método poderia ser usado para centralizar dados de vários bancos de dados, pois cada log enviado seria apenas para o banco de dados individual de onde veio.

Usando o SQL service broker, a latência pode ser imprevisível se uma fila não conseguir acompanhar o número de mensagens a serem processadas.

O CT identifica apenas uma versão para cada linha da tabela. A latência dependeria da rapidez com que poderíamos processar algo como um pacote SSIS em cada banco de dados para recuperar os dados e inseri-los em um repositório central.

Precisamos considerar a replicação de cada banco de dados individualmente e, em seguida, talvez usar algum tipo de técnica de virtualização de dados para combinar dados das várias fontes replicadas?

Qualquer conselho ou orientação que você esteja disposto a fornecer seria muito apreciado.

bperry
fonte
11
Devido ao seu requisito (quase) em tempo real, eu examinaria apenas o processamento baseado em eventos com algumas implementações da fila de mensagens (para garantias de entrega). Espero que isso ajude
Grimaldi
11
Eu jogaria o HTAP na mistura. en.m.wikipedia.org/wiki/Hybrid_Transactional/… BIML e SSIS para preencher o armazenamento comum.
Michael Green
@Grimaldi, você recomendaria o uso do SQL service broker para implementar as filas de mensagens / processamento com base em eventos ou alguma outra tecnologia de mensagens?
bperry
Obrigado pela sugestão, @ MichaelGreen. Basicamente, parece que o HTAP nos permitiria usar nossos bancos de dados existentes para OLTP e OLAP adicionando índices columnstore não agrupados em cluster (NCCI) às nossas tabelas. As consultas de relatório usam a NCCI para que não interfiram nas operações transacionais. O SQL 2016 inclui suporte a HTAP na Standard Edition (SE), mas parece que o cache do columnstore está limitado a 32 GB em toda a instância do SQL. Isso pode ser um problema para nós, pois temos dezenas de bancos de dados na mesma instância. microsoft.com/en-us/sql-server/sql-server-2016-editions
bperry
11
Sim columnstore, mas também na memória, se a especificação do servidor permitir que você vá para lá. Ouvi Sunil Agarwal falar sobre isso recentemente. A regra prática da MS era a degradação de cerca de 3% do OLTP em benefício dos relatórios de latência zero. Infelizmente, não há almoços grátis; você pode criar novas instâncias para manter o banco de dados de relatórios ou criar uma nova instância para obter espaço suficiente para oferecer suporte ao HTAP. Não estou advogando por esse padrão. Pode não funcionar para você. Só queria que você soubesse que existia.
Michael Green

Respostas:

1

Precisamos considerar a replicação de cada banco de dados individualmente e, em seguida, talvez usar algum tipo de técnica de virtualização de dados para combinar dados das várias fontes replicadas?

Sim. Você pode hospedar vários bancos de dados de assinantes em uma única instância e, em seguida, consultá-los com visualizações ou carregá-los em um banco de dados consolidado.

David Browne - Microsoft
fonte
Existe uma maneira mais elegante de configurar essas visualizações além de algo como ... SELECT Campo1, Campo2, Campo3 FROM [Banco de Dados1]. [Esquema]. [TableName] UNION ALL SELECT Campo SELEÇÃO1, Campo2, Campo3 FROM [Banco de Dados2]. [Esquema ]. [TableName]
bperry
1

De acordo com a descrição acima, o link abaixo ajudará você e eu também a trabalhar no mesmo cenário. Vários editores com um único assinante.

  1. Adicione mais uma coluna como server_id com valor padrão como 1,2,3 e assim por diante e torne-a chave primária composta.

  2. Ao criar as publicações e adicionar artigos, a propriedade Ação do artigo, se o nome estiver em uso, deve ser configurada como Excluir dados. Se o artigo tiver um filtro de linha, exclua apenas os dados que correspondem ao filtro. Isso pode ser definido usando o diálogo Novas Propriedades do Artigo do Assistente para Publicação ou usando os procedimentos armazenados de replicação sp_addarticle e especificando um valor de exclusão para o argumento @pre_creation_cmd. Dessa forma, quando o assinante central for inicializado ou reinicializado a partir de vários instantâneos de publicação, os dados de instantâneo aplicados anteriormente serão preservados, pois somente os dados correspondentes à cláusula de filtro serão excluídos.

insira a descrição da imagem aqui

http://www.sqlrepl.com/sql-server/central-subscriber-model-explained/

Gulrez Khan
fonte
obrigado pelo artigo. Usando o modelo de assinante central, você descobriu como lidará com as atualizações do esquema de seus editores (por exemplo, com atualizações de versão)? Você forçará a atualização simultânea de todos os bancos de dados do editor? No meu ambiente, nem sempre temos essa opção e essa foi minha principal hesitação em buscar um modelo de replicação de assinante central. Se existe uma maneira de contornar essa barreira, eu adoraria saber!
bperry
Eu não estou usando o 'Update Publisher'. Dividi o banco de dados em duas partes, como (dois tipos de replicação), algumas das tabelas no editor detalhado (Publisher para o assinante centralizado) e algumas são editor principal (assinante centralizado para todo o editor) ... .Meu assinante centralizado também faz parte do grupo de disponibilidade AlwaysOn, portanto, minha réplica secundária funciona como servidor de relatório.
Gulrez Khan
Deixe-me garantir que entendo sua solução. Digamos que o Publisher A esteja na versão 1 e o Publisher B na versão 2. 1) Você desativou a replicação das alterações de esquema nos dois publicadores (usando replicate_ddl = 0 na instalação). 2) A versão 2 inclui uma nova coluna; portanto, você a adicionaria manualmente no assinante central. 3) No Editor B (atualizado), você adicionaria manualmente a nova coluna à replicação (usando sp_articlecolumn). Nenhuma alteração é feita no Publicador A. Isso permitiria que os dois editores continuassem replicando para o assinante central sem interromper a replicação?
bperry
veja o link abaixo .. dba.stackexchange.com/questions/142449/…
Gulrez Khan
veja também .. dba.stackexchange.com/questions/146070/…
Gulrez Khan
1

Uma arquitetura possível:

Considere os relatórios como uma solução baseada em data warehouse.

Normalmente, um data warehouse é um banco de dados com um esquema que representa o subconjunto necessário dos sistemas de origem. O AdventureWorks e o AdventureworksDW demonstram essa modelagem.

Em seguida, o ETL: Movendo dados das fontes para o armazém de dados.

Uma possível implementação aqui é usar o rastreamento de alterações.

Em primeiro lugar, pode-se implementar visualizações que são específicas da versão no que consomem, mas em termos do que retornam, são uniformes. Por exemplo, se o Person.Gender existir na versão 2, mas não na versão 1, a visualização da pessoa para a versão 1 poderá retornar, por exemplo, nulo para a versão 1.

Para o consumidor do armazém, lendo apenas as visualizações, os dados têm a mesma forma (com abrangência variável).

O rastreamento de alterações fornece uma maneira (relativamente) leve de determinar quais dados precisam ser alterados a cada atualização.

A implementação das opções acima depende de ferramentas manuais, para que você tenha confiança na codificação SQL e teste os cenários de desempenho para ver a rapidez com que os incrementos são executados. Em muitos casos, eles podem ter menos de 1 segundo, mas algumas tabelas de transações altas podem gerar alta carga nas alterações de processamento. (O rastreamento de alterações é 'relativamente' leve ... somente os testes provam isso).

A coisa boa aqui é que você tem um alto grau de controle sobre como as diferenças de esquema se manifestam e, com o rastreamento de alterações, não há chance de problemas de integridade quando implementados corretamente, pois o rastreamento é feito no nível do mecanismo.

Se isso é definitivamente certo para você, seria difícil dizer.

Paul Holmes
fonte