Precisa armazenar 128 * Bit * Chave primária: Devo usar a tabela SQL Azure ou Azure? Ou apenas use uma lista vinculada no Azure Blob

Question

Preciso armazenar um grande (128 bits) PK. Cada int terá algumas colunas correspondentes ... nenhum esquema está definido agora ... e eu quero o esquema flexível no futuro. (Eu só preciso de flexibilidade conservadora, por exemplo, adicionando novas colunas de tempos em tempos)

Neste ponto, não estou muito preocupado com a capacidade de fazer junções e coisas assim. Eu principalmente quero escolher um PK aleatório e pesquisar para cima ou para baixo para os próximos 10 discos. Como pode haver muito espaço em branco na pesquisa, o custo da pesquisa ascendente e para baixo pode variar.

Qual é a melhor tecnologia para lidar com essa solicitação? Estou interessado em algo que me economize dinheiro (por transação) e espaço de armazenamento. Também estou interessado em desempenho.

O que você recomenda?

Atualizar

OK, então para que serve isso? Quero criar um histórico de dados para endereços IPv6. Claro que esta será uma mesa muito esparsa ... mas eu preciso rastrear certas coisas sobre os IPs vistos.

Answer 1

As tabelas do Windows Azure seriam minha recomendação, mas há apenas uma ordem de classificação definida, por isso será difícil pesquisar para frente e para trás. Você pode acabar precisando armazenar cada chave duas vezes, uma vez em ordem normal e, uma vez revertida (0xfff ... f - chave) para suportar as duas instruções de varredura com eficiência.

Answer 2

Para esclarecer, acho que você precisa de uma chave de 128 bits (não 2^128 bits).

Estou tomando isso como uma pergunta sobre a seleção do tipo de chave de banco de dados, não tenho certeza de quais consequências o ângulo do Azure tem. Afaik está construído no topo do MS-SQL.

128 bits ou 16 bytes tem o mesmo tamanho de um GUID (UniqueIdentifier), mas não acho que você queira usar isso. Embora haja suporte para que seja usado como chave.

Uma escolha direta seria algo como binário (16), mas não sei o quão adequado é como PK.

Você pode codificá -lo como uma string hexadecimal de char (32), que não é excessiva.

Para estimativas de praticidade, o fator -chave é o quão esparsa são seus dados ou melhor: quantos endereços você espera que tenha que armazenar?

Answer 3

Primeiro de tudo, sua premissa em 2^128 chaves inteiras está errada, já que você mencionou que deseja armazenar endereços IP V6. Um endereço IP V6 tem 128 bits de comprimento. Para armazená-lo como um número inteiro, você precisa de 128/32 ou 4 números inteiros por endereço. Portanto, a estimativa correta é 2^128 endereços possíveis * 4 números inteiros por um total de 2^128 * 4 chaves de números inteiros de 32 bits ....

De qualquer forma, eu quero isso em bytes, então vamos apenas 2^128 endereços possíveis * 4 inteiros * 4 bytes por número inteiro = 5,44 * 10^39 bytes. Depois disso, basta seguir o cálculo de Andreas e você acabará com mais ....

Dito isto, a idéia de IP V6 é que temos mais endereços do que precisamos usar. Por isso, duvido muito de 2^128 será atribuído por muitos anos. No máximo, se formos para o IP V6 agora, teremos o espaço de endereço IP V4 atribuído e nada mais, e embora o número de endereços IP aumente a cada ano, não muito.

De qualquer forma, parece que você não sabe o que está armazenando, pois o esquema não está definido para que a tabela do Azure possa ser o que você deseja. Principalmente é chave/valor. Para cada endereço IP, você pode armazenar propriedades totalmente diferentes. E é realmente fácil adicionar outra propriedade/remover outra propriedade usando as operações de atualização/inserção/mesclagem. Mas se você deseja alguma uniformidade aplicada aos seus dados, use o SQL. É verdade que você terá que modificar o esquema à medida que as mudanças acontecem, mas isso aplicará que cada linha (e, portanto, o endereço IP) possui os mesmos dados. Caso contrário, é fácil deixar de fora as colunas/propriedades "necessárias" ou com erros de ortografia, se você tiver vários aplicativos. Mas isso realmente depende do que você quer fazer. É mais você valoriza a integridade dos dados ou valoriza a flexibilidade das propriedades? Embora um esquema precise ser alterado, existem comandos para adicionar/remover colunas de um esquema. É mais que você deseja que todos os endereços IP armazenem as mesmas propriedades ou possam ter propriedades diferentes. Acredito que o caminho da tabela do Azure provavelmente leva menos armazenamento por endereço do que o SQL Way se você não estiver usando a maioria das propriedades para um determinado endereço IP. Portanto, tudo depende do que você está procurando.