Definitivamente, salve os endereços IP como números, se você não se importar com o trabalho extra que isso leva, especialmente se precisar fazer consultas nos endereços e tiver grandes tabelas/coleções.

Aqui está o porquê:

Armazenamento

• Um endereço IPv4 tem 4 bytes se armazenado como um número inteiro não assinado.
• Um endereço IPv4 varia entre 10 bytes e 18 bytes quando escrito como uma string no formato octed pontilhado. (Vamos supor que a média seja 14 bytes.)

Isso é 7-15 bytes para os caracteres, mais 2-3 bytes se você estiver usando um tipo de string de comprimento variável, que varia de acordo com o banco de dados que você está usando. Se você tiver uma representação de string de comprimento fixo disponível, deverá usar um campo de largura fixa de 15 caracteres.

O armazenamento em disco é barato, então esse não é um fator na maioria dos casos de uso. A memória, no entanto, não é tão barata e, se você tiver uma tabela/coleção grande e quiser fazer consultas rápidas, precisará de um índice. A penalidade de armazenamento de 2-3x da codificação de string reduz drasticamente a quantidade de registros que você pode indexar enquanto mantém o índice residente na memória.

• Um endereço IPv6 tem 16 bytes se armazenado como um inteiro não assinado. (Provavelmente como vários inteiros de 4 ou 8 bytes, dependendo da sua plataforma.)
• Um endereço IPv6 varia de 6 bytes a 42 bytes quando codificado como uma string em notação hexadecimal abreviada.

Na extremidade inferior, um endereço de loopback (::1) é de 3 bytes mais o overhead de string de comprimento variável. No topo, um endereço como 2002:4559:1FE2:1FE2:4559:1FE2:4559:1FE2 usa 39 bytes mais o overhead de string de comprimento variável.

Ao contrário do IPv4, não é seguro assumir que o comprimento médio da string IPv6 será de 6 e 42, porque o número de endereços com um número significativo de zeros consecutivos é uma fração muito pequena do espaço geral de endereços IPv6. Apenas alguns endereços especiais, como endereços de loopback e autoconf, podem ser compactados dessa maneira.

Novamente, esta é uma penalidade de armazenamento de>2x para codificação de string versus codificação de inteiro.

Matemática de rede

Você acha que os roteadores armazenam endereços IP como strings? Claro que não.

Se você precisar fazer contas de rede em endereços IP, a representação de string é um incômodo. Por exemplo. se você quiser escrever uma consulta que procure todos os endereços em uma sub-rede específica ("retorne todos os registros com um endereço IP em 10.7.200.104/27", você pode fazer isso facilmente mascarando um endereço inteiro com uma máscara de sub-rede inteira. ( O Mongo não oferece suporte a essa consulta específica, mas a maioria dos RDBMS o faz.) Se você armazenar endereços como strings, sua consulta precisará converter cada linha em um inteiro e, em seguida, mascará-la, o que é várias ordens de magnitude mais lenta. para um endereço IPv4 pode ser feito em alguns ciclos de CPU usando 2 registradores. Converter uma string em um inteiro requer um loop sobre a string.)

Da mesma forma, consultas de intervalo ("retornar todos os registros todos os registros entre 192.168.1.50 e 192.168.50.100") com endereços inteiros poderão usar índices, enquanto consultas de intervalo em endereços de string não.

O resultado final

É preciso um pouco mais de trabalho, mas não muito (há um milhão de funções aton() e ntoa() por aí), mas se você estiver construindo algo sério e sólido e quiser torná-lo à prova de futuro contra requisitos futuros e a possibilidade de um grande conjunto de dados, você deve armazenar endereços IP como números inteiros, não strings.

Se você está fazendo algo rápido e sujo e não se importa com a possibilidade de remodelação no futuro, use cordas.

Para o propósito do OP, se você está otimizando a velocidade e o espaço e não acha que deseja consultá-lo com frequência, por que usar um banco de dados? Basta imprimir endereços IP em um arquivo. Isso seria mais rápido e mais eficiente de armazenamento do que armazená-lo em um banco de dados (com API associada e sobrecarga de armazenamento).