Qual é o melhor paradigma de acesso a dados para escalabilidade?

Question

Existem tantas opções diferentes surgindo da Microsoft para acesso a dados.Qual é o melhor para aplicativos escalonáveis?

Linq

Deveríamos usar o Linq?Certamente parece fácil, mas se você conhece o seu SQL, isso realmente ajuda.Também ouvi dizer que você não pode executar consultas assíncronas no ASP.NET usando Linq.Portanto, eu me pergunto se é realmente escalável?Existem sites realmente grandes usando Linq (com a possível exceção do stackoverflow).

Estrutura de entidade

Não ouça tanto barulho sobre o Entity Framework.Parece mais próximo do modelo de objeto com o qual estou familiarizado.

Astoria/dados dinâmicos

Deveríamos expor nossos dados como um serviço?

Estou bastante confuso e isso antes de entrar em outros produtos ORM como o NHibernate.Alguma idéia ou sabedoria sobre o que é melhor?

Answer 1

Eu recomendaria NHibernate ou Entity Framework.Para sites grandes, eu usaria o ADO.NET Data Services.Eu não faria nada grande com LINQ to SQL.Acho que o Stack Overflow pode acabar com alguns problemas de escala interessantes sendo de 2 camadas em vez de 3 camadas, e eles também terão alguns problemas para refatorar à medida que os aspectos físicos do banco de dados mudam e essas mudanças se propagam por todo o código.Apenas um pensamento.

Answer 2

Acho que o ADO.Net Data Services (anteriormente chamado de Astoria) tem um papel importante a desempenhar.Ele se adapta perfeitamente à arquitetura de estilo REST da web.

Como a web é escalável, acho que qualquer coisa que siga sua arquitetura também é escalável.Além disso, você pode querer ficar atento ao SQL Server Data Services.

Answer 3

Se você está falando sobre bancos de dados relacionais, meu voto é encapsular todas as suas operações de dados em procedimentos armazenados, independentemente de como você os acessa nas outras camadas.

Se você desabilitar todo o acesso de leitura/gravação ao banco de dados, exceto por meio de procedimentos armazenados, poderá ocultar seu modelo de dados atrás de contratos bem definidos.O modelo de dados pode ser alterado livremente, apenas para que os procedimentos armazenados ainda respeitem suas entradas e saídas.

Isso dá aos DBAs total liberdade para ajustar seu aplicativo e torná-lo escalonável.Esta é uma tarefa muito, muito difícil quando o SQL está sendo gerado por uma ferramenta fora do banco de dados.

Answer 4

Bloquear-se em procedimentos armazenados parece ser uma forma de pensar em declínio atualmente, pelo menos essas são minhas observações atuais.Essa maneira de pensar se presta ao mundo ORM, uma vez que eles são tipicamente mais afetivos indo contra as tabelas diretamente, mas qualquer ORM que se preze também permitirá o uso de procs – às vezes você não tem escolha.

Há muitas opiniões em torno da EF e independentemente do que alguém diga, bom ou ruim, é um produto V1 e com a regra geral de que a MS leva cerca de 3 rotações para acertar, pode ser prudente esperar pela próxima rotação em ao menos.

Parece que o maior player neste espaço é o NHibernate e há muito apoio para isso na comunidade.Linq, o recurso da linguagem, não deve estar muito longe de chegar à pilha do NHibernate.

Answer 5

Use o que funcionar para você.Tudo isso é mais fácil de configurar se você já tiver um banco de dados razoavelmente normalizado (ou seja, uma boa definição de chaves primárias e chaves estrangeiras).No entanto, se você tiver dados que não são facilmente normalizados, o Entity Framework é mais flexível que o LINQ to SQL, mas dá mais trabalho para configurar.

Answer 6

Temos experimentado o LINQ em um ambiente de cluster e ele parece estar sendo bem dimensionado em máquinas individuais e em todo o cluster.Das três opções que você forneceu, eu diria que o LINQ é a melhor escolha, embora cada opção tenha um público-alvo ligeiramente diferente, portanto você deve definir o que fará com os dados antes de decidir sobre o paradigma de acesso.

Answer 7

Eu sugeriria linq.Ele se adapta bem ao nosso site e é bastante simples de usar.

Answer 8

use procedimentos armazenados com LINQ... mas não deixe os sprocs se transformarem em uma camada de acesso a dados!

Answer 9

Esta postagem é de 2008, antes da nuvem realmente decolar.Parece que é necessária uma atualização da resposta.Fornecerei apenas alguns links e uma visão geral.Tenho certeza que há postagens mais atualizadas neste site sobre esse assunto e, se eu as encontrar, adicionarei os links aqui.

Quando se trata de escalabilidade de dados e escalabilidade de processamento de transações, em 2017 precisamos falar sobre Nuvem e Provedores de Serviços de Nuvem.

Acho que os três principais provedores de nuvem atualmente são:

• Amazon Web Services (AWS)
• Plataforma de nuvem do Google (GCP)
• Microsoft Azure

Custo

Uma das melhores vantagens de usar serviços em nuvem é que não há custos iniciais, nem taxas de rescisão, e você paga apenas pelo que usa.(Citando o artigo do Sr. Alba de 2016 "Uma comparação lado a lado entre AWS, Google Cloud e Azure")

Nós mesmos usamos AWS.Pagamos apenas enquanto temos VMs instaladas e em execução, por isso pode ser uma forma barata de iniciar.Normalmente, os provedores de serviços cobram por minuto ou por hora, mas você tem a garantia de tê-lo durante todo esse tempo.

Uma maneira mais barata de fazer isso é o preço spot de melhor esforço.O preço Spot representa o preço acima do qual você deve licitar para garantir que uma única solicitação Spot seja atendida.Quando o preço spot estiver acima do preço spot, o Amazon EC2 iniciará sua instância spot, e quando o preço spot subir acima do preço spot, o Amazon EC2 encerrará sua instância spot.(Citando descaradamente o Guia do usuário da Amazon aqui)

Uma comparação lado a lado entre AWS, Google Cloud e Azure é um bom artigo que faz uma comparação lado a lado desses três provedores de serviços disponíveis aqui.

Para uma visão mais acadêmica dos serviços em nuvem, leia o artigo de 2010 de Yu, Wang, Ren e Lou "Alcançando controle de acesso a dados seguro, escalonável e refinado em computação em nuvem" nos Anais do INFOCOM 2010 disponíveis aqui, mas pode ser necessário ser membro do IEEE para obter acesso a ele.Embora seja um pouco desatualizado, é excelente e você pode usá-lo como ponto de partida.

O dimensionamento na nuvem está explodindo e, até recentemente, esse dimensionamento era feito com a inicialização de novas máquinas virtuais, o que levava segundos, mas com os contêineres é possível ativar novas instâncias em milissegundos.Para obter mais informações sobre isso, consulte Docker e Docker Containers aqui.

Peço desculpas por esta resposta ser apenas um monte de links para mais informações, mas achei que a resposta a esta pergunta deveria ser atualizada.Espero que isso inspire alguém a fornecer mais detalhes em primeira mão.Se você já postou alguma informação relacionada, considere fornecer links para suas próprias postagens.Obrigado!