Banco de dados do SQL Server em um SSD - alguma vantagem de um arquivo separado para cada tabela?


19

Estou criando um banco de dados no qual haverá cerca de 30 tabelas, com todas as tabelas contendo dezenas de milhões de linhas e cada tabela contendo uma única coluna importante e uma coluna de chave primária / estrangeira, a fim de maximizar a eficiência da consulta diante de problemas pesados. atualizações e inserções e faça uso intenso de índices em cluster. Duas das tabelas conterão dados textuais de tamanho variável, com um deles contendo centenas de milhões de linhas, mas o restante conterá apenas dados numéricos.

Como realmente quero extrair toda a última gota de desempenho do hardware que tenho disponível (cerca de 64 GB de RAM, um SSD muito rápido e 16 núcleos), estava pensando em permitir que cada tabela tivesse seu próprio arquivo para que não importasse se Estou entrando em 2, 3, 4, 5 ou mais tabelas, cada tabela sempre será lida usando um thread separado e a estrutura de cada arquivo estará alinhada com o conteúdo da tabela, o que, com sorte, minimizaria a fragmentação e a tornaria mais rápida para o SQL Server adicionar ao conteúdo de qualquer tabela.

Uma ressalva, estou preso no SQL Server 2008 R2 Web Edition . O que significa que não posso usar o particionamento horizontal automático, o que exclui isso como um aprimoramento de desempenho.

O uso de um arquivo por tabela realmente maximizará o desempenho ou estou ignorando as características internas do mecanismo do SQL Server que tornariam isso redundante?

Segundo, se o uso de um arquivo por tabela é vantajoso, por que create tableme dá a opção de alocar a tabela para um grupo de arquivos e não para um arquivo lógico específico? Isso exigiria que eu criasse um grupo de arquivos separado para cada arquivo no meu cenário, o que sugere que talvez o SQL Server não esteja visualizando as vantagens que estou assumindo que viriam ao fazer o que estou propondo.

Respostas:


18

Eu estava pensando em permitir que cada tabela tivesse seu próprio arquivo, para que não importasse se eu ingresse em 2, 3, 4, 5 ou mais tabelas, cada tabela será sempre lida usando um thread separado e a estrutura de cada arquivo será esteja estreitamente alinhado com o conteúdo da tabela, o que, esperançosamente, minimizaria a fragmentação e tornaria mais rápido o SQL Server adicionar ao conteúdo de qualquer tabela

Do que diabos você está falando? Não tenho certeza de onde você obteve suas informações, mas você certamente deve descartar essa fonte. Nada do que você assume aqui está realmente correto.

Se você quiser ler uma boa discussão sobre o desempenho do SSD para o SQL Server, existem várias séries de blogs por aí. Como sempre, a primeira de Paul Randal é a principal:

Brent também tem uma boa apresentação sobre o tópico: SQL em SSDs: Hot and Crazy Love e há mais por aí.

Ao passar por todas essas apresentações, você notará rapidamente que todas elas se concentram nas gravações, pois é nesse ponto que o desempenho dos SSDs entra em cena. O texto da sua postagem é quase inteiramente sobre leituras, que é um tópico diferente. Se as leituras são o seu ponto crítico, você deve estar falando sobre RAM, não sobre SSDs e sobre estratégias adequadas de indexação e consulta.


1
Sim, recebi informações erradas em algum lugar ao longo da linha, mas, como comentei a resposta de Stuart, fiz a pergunta para ter certeza de que não baseava minhas decisões em informações incorretas. Obrigado pelos links, vou vê-los.

17

Minha primeira sugestão seria não fazer suposições sobre desempenho sem fazer testes de carga nas duas configurações.

Meu palpite por ter visto essas configurações (que fazem sentido no papel) no passado seria que ter cada tabela em um arquivo separado não teria um impacto positivo mensurável no desempenho ... e que a complexidade adicional compensaria qualquer ganho de desempenho mesmo que fossem mensuráveis.

Por fim, quando se trata de extrair cada gota de desempenho de um Sql Server, refiro-lhe o seguinte gráfico (fornecido pela Microsoft):

insira a descrição da imagem aqui

Quaisquer otimizações em potencial que possam ser feitas da perspectiva de um aplicativo superam facilmente todas as otimizações possíveis no nível de configuração de hardware / banco de dados ... então concentre sua atenção adequadamente.


Claro. No entanto, no meu caso, tenho otimizado o sistema inteiro o máximo que posso e o principal gargalo que tenho no momento é a velocidade de consulta muito rápida diante de atualizações, exclusões e inserções frequentes. Como vou alavancar o SQL Server para resolver esse problema, quero garantir a melhor chance possível de operar o mais rápido possível nos meus dados.

@NathanRidley Ok, entendi ... Acho que a resposta real, a menos que alguém tenha um recurso dizendo "nunca faça isso", que o melhor curso de ação seria comparar duas configurações com a sua carga de trabalho típica e ver se há uma diferença mensurável.
Michael Fredrickson

4

Como outros observaram, não há benefício direto de um arquivo por tabela; aqui está uma ótima sinopse de Steve Jones sobre como esse mito se originou: http://www.sqlservercentral.com/blogs/steve_jones/2009/10/13/sql-server-legend-data-files-and-threads/

Você também pode querer investigar uma exibição particionada que, acredito, é suportada pelo 2008 Web Edition. Existem alguns truques para codificar em uma exibição particionada, mas você pode imitar muita funcionalidade das tabelas particionadas com relativa facilidade.


2

Eu acho que arquivos separados para cada tabela não trariam benefícios de desempenho. Os índices corretos podem ter incrase de desempenho potencial (leitura de disco) no servidor de banco de dados.

O SQL Server 2008 R2 suporta compactação? Se sim, ative isso.

Corrija-me se eu estiver errado.


Você poderia explicar por que não haveria benefício no desempenho? No mínimo, explique por que esse é o caso quando arquivos separados permitem que o SQL Server use vários threads para leitura.

Se você colocar toda a tabela em seu próprio grupo de arquivos, mas na mesma unidade, o desempenho será igual antes do particionamento. Mas se você estiver separando algumas tabelas para os grupos de arquivos em um disco diferente e mais rápido, isso terá um benefício de desempenho. Você também pode particionar, por exemplo, por ano, se tiver muitos dados que dependem do ano. Com esta técnica, você pode manter os dados mais usados ​​em um disco mais rápido que os antigos. Você também pode separar os índices, mas somente se os colocar em um novo disco físico terá algum benefício de desempenho.

Você está certo sobre os threads paralelos (tabelas / arquivos), mas acho que até você ter apenas um disco físico, o ganho de desempenho será pequeno.

E eu recomendo que você obtenha uma matriz de stronge HDD RAID para o banco de dados porque o SSD morrerá em breve.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.