Incremento automático no armazenamento de mesa do Azure

Question

Atualmente, estou desenvolvendo um aplicativo para armazenamento de tabela do Azure. Nesse aplicativo, tenho tabela que terá relativamente poucas inserções (alguns milhares/dia) e a chave primária dessas entidades será usada em outra tabela, que terá bilhões de linhas.

Portanto, estou procurando uma maneira de usar um número inteiro incrementado automaticamente, em vez de GUID, como chave primária na tabela pequena (pois economizará muito armazenamento e escalabilidade das inserções não é realmente um problema).

Houve algumas discussões sobre o assunto, por exemplo, http://social.msdn.microsoft.com/forums/en/windowszure/thread/6b7d1ece-301b-44f1-85ab-eb274349797.

No entanto, como os problemas de simultaneidade podem ser realmente difíceis de depurar e serem spot, fico um pouco desconfortável ao implementá -lo por conta própria. Minha pergunta é, portanto, se houver uma impressão bem testada disso?

Answer 1

Ainda não implementei isso, mas estou trabalhando nisso ...

Você pode semear uma fila com seus próximos IDs para usar e depois retirá -los da fila quando precisar deles.

Você precisa manter uma tabela para conter o valor do maior número adicionado à fila. Se você sabe que não usará uma tonelada de números inteiros, poderá ter um trabalhador de vez em quando acordar e garantir que a fila ainda tenha números inteiros. Você também pode ter uma fila de INT usada que o trabalhador pode verificar para ficar de olho no uso.

Você também pode conectar esse trabalhador, por isso, se a fila estivesse vazia quando seu código precisava de um ID (por acaso), ele poderia interromper a soneca do trabalhador para criar mais chaves o mais rápido possível.

Se essa chamada falhou, você precisaria de uma maneira de (diga ao trabalhador que você fará o trabalho para eles (bloquear), faça o trabalho dos trabalhadores de obter o próximo ID e desbloquear)

1. trancar
2. Crie a última chave da tabela
3. incremento e salvar
4. desbloquear

Em seguida, use o novo valor.

Answer 2

Para todos que o encontrarão em busca, há uma solução melhor. O tempo mínimo para o bloqueio da mesa é de 15 segundos - isso é horrível. Não use -o se desejar criar uma solução verdadeiramente escalável. Usar Etag!

Crie uma entidade na tabela para ID (você pode até nomeá -lo como ID ou qualquer outra coisa).

1) Leia.

2) incremento.

3) insertorUpdate COM ETag especificado (na consulta de leitura).

Se a última operação (InsertOrUpdate) é bem-sucedido, você tem um ID novo, exclusivo e incrementado automaticamente. Se falhar (exceção com HttpStatusCode == 412), isso significa que outro cliente o alterou. Então, repita novamente 1,2 e 3. O tempo usual para Read+InsertOrUpdate é menos do que 200ms. Meu utilitário de teste com fonte no github.

Answer 3

Ver Classe degeneradora exclusiva por Josh Twist.

Answer 4

A solução que descobri que impede IDs duplicados e permite que você

1. trava (arrendamento) uma bolha e que isso atue como um portão lógico.

2. Em seguida, leia o valor.

3. Escreva o valor incrementado

4. Libere o arrendamento

5. Use o valor em seu aplicativo/tabela

Então, se sua função de trabalhador falhasse durante esse processo, você só teria uma identificação ausente em sua loja. IMHO que é melhor que duplicata.

Aqui está um amostra de código e mais informações nessa abordagem de Steve Marx

Answer 5

Se você realmente precisa evitar o GUIDS, pensou em usar algo com base na data/hora e depois alavancar as chaves de partição para minimizar o risco de simultaneidade.

Sua chave de partição pode ser por usuário, ano, mês, dia, hora, etc. e a tecla de linha pode ser o restante do datetime em um pequeno tempo suficiente para controlar a simultaneidade.

É claro que você deve se perguntar, pelo preço da data no Azure, se evitar um GUID realmente vale todo esse esforço extra (assumindo que um GUID funcionará).