Tabelas do Azure ou SQL Azure?

Question

Estou no estágio de planejamento de um aplicativo da Web que será hospedado no Azure com o ASP.NET para o site e o Silverlight no site para uma rica experiência do usuário. Devo usar tabelas do Azure ou SQL Azure para armazenar meus dados de aplicativos?

Answer 1

O armazenamento de mesa do Azure parece ser mais barato que o SQL Azure. Também é mais altamente escalável que o SQL Azure.

O SQL Azure é mais fácil de trabalhar se você estiver fazendo muitos funcionários do banco de dados relacionais. Se você estivesse portando um aplicativo que já estava usando um banco de dados SQL, movê -lo para o SQL Azure seria a escolha óbvia, mas essa é a única situação em que eu o recomendaria.

A principal limitação nas tabelas do Azure é a falta de índices secundários. Isso foi anunciado no PDC '09 e está atualmente listado em breve, mas não houve nenhum anúncio de quadro de tempo. (Ver http://windowszure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-tecondary-indexes?ref=title)

Vi o uso proposto de um sistema híbrido em que você usa o armazenamento de tabela e blob para a maior parte dos seus dados, mas use o SQL Azure para índices, pesquisa e filtragem. No entanto, ainda não tive a chance de experimentar essa solução.

Uma vez que os índices secundários forem adicionados ao armazenamento de tabela, ele será essencialmente baseado em nuvem Nosql sistema e será muito mais útil do que é agora.

Answer 2

Apesar dos nomes semelhantes, as tabelas SQL Azure e o armazenamento de mesa têm muito pouco em comum.

Aqui estão dois links que podem ajudá -lo:

• Armazenamento de mesa, um fator de custo de 100x
• Entidades gordas no armazenamento de mesa

Basicamente, a primeira pergunta deve se perguntar é Meu aplicativo realmente precisa escalar? Caso contrário, vá para o SQL Azure.

Answer 3

Para aqueles que tentam decidir entre as duas opções, certifique -se de levar os requisitos de relatórios na equação. Relatórios do SQL Azure e outros produtos de relatórios suportam o SQL Azure para fora da caixa. Se você precisar gerar relatórios complexos ou flexíveis, provavelmente desejará evitar o armazenamento de tabela.

Answer 4

As tabelas do Azure são mais baratas, mais simples e em escala melhor que o SQL Azure. O SQL Azure é um ambiente SQL gerenciado, por natureza com vários inquilinos; portanto, você deve analisar se seus requisitos de desempenho forem adequados para o SQL Azure. Uma versão premium do SQL Azure foi anunciada e está em pré -visualização até o momento da redação (ver AQUI).

Eu acho que os fatores decisivos para decidir entre as tabelas SQL Azure e Azure são os seguintes:

• Você precisa fazer junções complexas e usar índices secundários? Se sim, o SQL Azure é a melhor opção.
• Você precisa de procedimentos armazenados? Se sim, SQL Azure.
• Você precisa de recursos de escala automática? As tabelas do Azure são a melhor opção.
• Linhas dentro de uma tabela do Azure não podem exceder 4 MB de tamanho. Se você precisar armazenar grandes dados dentro de uma linha, é melhor armazená -los no armazenamento do blob e fazer referência ao URI da blob na linha da tabela.
• Você precisa armazenar grandes quantidades de dados semiestruturados? Se sim, as tabelas do Azure são vantajosas.

Embora as tabelas do Azure sejam tremendamente benéficas em termos de simplicidade e custo, existem algumas limitações que precisam ser levadas em consideração. Por favor, veja AQUI Para alguma orientação inicial.

Answer 5

Uma outra consideração é a latência. Costumava haver um site que a Microsoft executou com Microbenchmarks na taxa de transferência e latência de vários tamanhos de objetos com o armazenamento de tabela e o SQL Azure. Como esse site não está mais disponível, apenas darei uma aproximação aproximada do que me lembro. A loja de tabela tende a ter uma taxa de transferência muito maior que o SQL Azure. O SQL Azure tende a ter menor latência (em até 1/5).

Já foi mencionado que a loja de mesa é fácil de escalar. No entanto, o SQL Azure também pode escalar Federações. Observe que as federações (efetivamente sharding) adiciona muita complexidade ao seu aplicativo. Também não tenho certeza de quanto as federações afetam o desempenho, mas imagino que haja algumas despesas gerais.

Se a continuidade dos negócios é uma prioridade, considere que com o Azure Storage você recebe replicação geográfica barata por padrão. Com o SQL Azure, você pode realizar algo semelhante, mas com mais esforço com SQL Data Sync. Observe que a sincronização de dados do SQL também incorre na sobrecarga de desempenho, pois requer gatilhos em todas as suas tabelas para observar alterações de dados.

Answer 6

Sei que essa é uma pergunta antiga, mas ainda é muito válida, então estou adicionando minha resposta a ela.

Coderdennis e outros apontaram alguns dos fatos - as mesas do Azure são mais baratas, e as mesas do Azure podem ser muito maiores, mais eficientes etc. Se você tiver 100% de certeza de que ficará com o Azure, vá com tabelas.

No entanto, isso pressupõe que você já tenha decidido no Azure. Ao usar tabelas do Azure, você está se prendendo na plataforma do Azure. Significa escrever código muito específico para tabelas do Azure que não vão apenas portar para a Amazon, você precisará reescrever essas áreas do seu código. Por outro lado, a programação para um banco de dados SQL com o LINQ portará muito mais facilmente para outro serviço em nuvem.

Isso pode não ser um problema se você já decidiu sua plataforma em nuvem.

Answer 7

Sugiro olhar para o cache do Azure em combinação com a tabela do Azure. Somente a tabela possui 200 a 300ms de latências, com picos ocasionais mais altos, o que pode diminuir significativamente os tempos de resposta / interatividade da UI. A tabela de cache + parece ser uma combinação vencedora, para mim.

Answer 8

Para sua pergunta, quero falar sobre como decidir com a lógica escolher a tabela SQL e que precisa usar a tabela do Azure.

Como sabemos, a tabela SQL é um mecanismo de banco de dados relacional. Mas se você tiver um big data em uma tabela, a tabela SQL não será aplicável, porque a consulta SQL Get Big Data é lenta.

Nesse momento, você pode escolher a tabela do Azure, a consulta da tabela do Azure é tão rápida que a tabela SQL para big data, por exemplo, em nosso site, alguém assinou muitos artigos, fazemos o artigo como feed para o usuário, todo usuário tem uma cópia de Título do artigo e descrição, portanto, na tabela de artigos, existem muitos dados, se usarmos a tabela SQL, cada execução de consulta pode levar mais de 30 segundos. Mas na tabela do Azure, obtenha o artigo dos usuários Feed by PartionKey e RowKey é tão rápido.

A partir deste exemplo, você pode saber como escolher entre a tabela SQL e o Azure.

Answer 9

Gostaria de saber se vamos acabar com algumas bibliotecas de API em nuvem "independentes do fornecedor" no devido tempo?

Answer 10

Eu acho que você tem primeiro para definir quais são os funis de uso do seu aplicativo. Seu modelo de dados será submetido a alterações frequentes ou é estável? Você deve ser capaz de realizar inserções e leituras ultra rápidas não são tão complicadas? Você precisa de avançar no Google como pesquisa? Armazenando bolhas?

Essas são as perguntas (e não apenas) que você precisa fazer e responder a si mesmo para decidir se é mais provável que você use a abordagem NOSQL ou SQL para armazenar seus dados.

Por favor, considere que ambas as abordagens podem coexistir facilmente e também podem ser estendidas com o armazenamento do blob.

Answer 11

Tanto as tabelas do Azure quanto o SQL Azure são duas bestas diferentes. Ambos destinam -se a diferentes cenários, uma tabela Con to Azure é que você não pode passar do Azure para qualquer outra plataforma, a menos que você escreva provedores em seu código que possam lidar com essas mudanças.