Zapnologica's questions

Eu tenho uma tabela de log do Sql Server, que está sendo inserida continuamente, quero revisar o design desta tabela.

Atualmente, estamos usando um GUID como o PK, porque o software pode gerar isso e nós apenas o inserimos, e esperamos que várias inserções não bloqueiem umas às outras. No entanto, UniqueId não é um PK muito eficiente para uma tabela e nossos índices são muito grandes e fragmentados.

Se eu alterar essa coluna para um longcom auto-incrementenabled. Isso se tornará um gargalo de inserção simultânea?

Eu não preciso que minha chave primária esteja em qualquer tipo de ordem, apenas um id exclusivo para essa linha?

Bom dia, tenho a seguinte tabela de banco de dados sql server:

Observe a chave primária composta. Isso foi feito por 3 motivos:

• Impedir entradas duplicadas
• Melhore o desempenho da consulta, pois todas as consultas terão todas as 3 chaves.
• Precisávamos e indexamos, e eu não queria introduzir um ID aleatório.

Observe também que esta tabela foi projetada com seu tamanho em mente. Esta tabela armazenará milhões e milhões de linhas de dados.

OK agora para a minha pergunta real. Estou usando o azure sql server para hospedar este banco de dados. e habilitei o ajuste automático. E, estranhamente, vejo que ele foi e criou um novo índice. (Veja abaixo)

Agora, na minha mente, isso parece ser um índice duplicado, pois as mesmas colunas estão sendo indexadas.

Então agora eu tenho dois índices na minha tabela:

Original (Meu PK):

ALTER TABLE [dbo].[SensorDataRaw] ADD  CONSTRAINT [PK_SensorDataRaw] PRIMARY KEY CLUSTERED 
(
    [DateTime] ASC,
    [SensorId] ASC,
    [Key] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

Recém-adicionado (criado automaticamente pelo ajuste do Azure):

CREATE NONCLUSTERED INDEX [nci_wi_SensorDataRaw_DC9789077DA75B4440AC8BFE3E2AA198] ON [dbo].[SensorDataRaw]
(
    [Key] ASC,
    [SensorId] ASC,
    [DateTime] ASC
)
INCLUDE (   [Value]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

Observações:

• A ordem das colunas foi invertida no novo índice.
• O novo índice NÃO é único
• o novo índice inclui a coluna de valor.

Observe que meu conhecimento sobre índices não é avançado, por isso estou perguntando isso.

Então minha pergunta é:

1. Alguém pode explicar por que o índice recém-adicionado é melhor do que o meu criado inicialmente.
2. Como posso remover os dois índices e apenas criar um que cubra os dois casos. Sendo este um banco de dados tão grande, não posso arcar com o espaço que esses dois índices ocuparão.
3. O talvez seja uma alternativa de design melhor?

Informação adicional:

Estou assumindo que o tipo de consulta se torna importante aqui, então listei alguns exemplos.

Todas as consultas incluem DateTime, SensorIde Key.

Consultas simples:

Select SensorId Where average value for key w is greater than x where time between (y,z)

Dados gráficos:

SELECT AVG([Value]) AS 'AvgValue',    
    DATEADD( MINUTE, 
    (DATEDIFF(MINUTE, '1990-01-01T00:00:00', [dbo].[SensorDataRaw].
[DateTime]) / @IntervalInMinutes) * @IntervalInMinutes,
        '1990-01-01T00:00:00'
    )      AS 'TimeGroup'
 FROM [dbo].[SensorDataRaw]
 where 
    [dbo].[SensorDataRaw].[SensorId] = @SensorId
    and [dbo].[SensorDataRaw].[Key] = @KeyValue
    and [dbo].[SensorDataRaw].[DateTime] Between @DateFrom and @DateTo
    and [dbo].[SensorDataRaw].[Value] IS NOT NULL  
  GROUP BY (DATEDIFF(MINUTE, '1990-01-01T00:00:00', [dbo].[SensorDataRaw].
    [DateTime]) / @IntervalInMinutes)

De acordo com a documentação datetime2 (Transact-SQL) :

Tamanho de armazenamento
6 bytes para precisões menores que 3.
7 bytes para precisões 3 e 4.
Todas as outras precisões requerem 8 bytes.

O tamanho de datetime2(0), datetime2(1), datetime2(2)usa a mesma quantidade de armazenamento (6 bytes).

Estaria correto ao dizer que poderia muito bem seguir datetime2(2)e obter o benefício da precisão sem nenhum custo adicional de tamanho?

Observe:

• Esta coluna é indexada com o PK para formar um índice clusterizado composto (usado para particionamento de tabela)
• Eu não me importo com milissegundos

A CPU seria datetime2(0)mais eficiente quando usada em uma cláusula where ou ao buscar por meio de um índice?

Esta é uma tabela enorme, então a menor otimização fará uma grande diferença.

Desejo atualizar meu SQL Server 2008 Enterprise Edition para o SQL Server 2016 Standard Edition; no entanto, um banco de dados faz uso de partições de tabela em vários grupos de arquivos (usado em uma grande tabela de log, cada dia é uma partição)

Vejo em Edições e recursos com suporte para SQL Server 2016 na seção "RDBMS Scalability and Performance", que diz que a Standard Edition oferece suporte ao particionamento de tabela e índice , mas não oferece suporte ao paralelismo de tabela particionada .

Não tenho certeza de que compreendo totalmente as consequências disso.

O que exatamente isso significa no meu caso e como isso afetará o desempenho do banco de dados?