Enregistrez définitivement les adresses IP sous forme de nombres, si cela ne vous dérange pas le peu de travail supplémentaire que cela demande, surtout si vous devez faire des requêtes sur les adresses et que vous avez de grandes tables/collections.
Voici pourquoi :
Stockage
- Une adresse IPv4 fait 4 octets si elle est stockée sous forme d'entier non signé.
- Une adresse IPv4 varie entre 10 octets et 18 octets lorsqu'elle est écrite sous forme de chaîne sous forme d'octe avec des points. (Supposons que la moyenne est de 14 octets.)
C'est 7-15 octets pour les caractères, plus 2-3 octets si vous utilisez un type de chaîne de longueur variable, qui varie en fonction de la base de données que vous utilisez. Si vous disposez d'une représentation sous forme de chaîne de longueur fixe, vous devez utiliser un champ de largeur fixe de 15 caractères.
Le stockage sur disque est bon marché, ce n'est donc pas un facteur dans la plupart des cas d'utilisation. La mémoire, cependant, n'est pas aussi bon marché, et si vous avez une grande table/collection et que vous voulez faire des requêtes rapides, alors vous avez besoin d'un index. La pénalité de stockage 2-3x du codage de chaîne réduit considérablement la quantité d'enregistrements que vous pouvez indexer tout en gardant l'index résident en mémoire.
- Une adresse IPv6 est de 16 octets si elle est stockée sous la forme d'un entier non signé. (Probablement sous forme d'entiers multiples de 4 ou 8 octets, selon votre plate-forme.)
- Une adresse IPv6 s'étend de 6 octets à 42 octets lorsqu'elle est encodée sous forme de chaîne en notation hexadécimale abrégée.
Au bas de l'échelle, une adresse de bouclage (::1) est de 3 octets plus la surcharge de la chaîne de longueur variable. En haut de gamme, une adresse comme 2002:4559:1FE2:1FE2:4559:1FE2:4559:1FE2 utilise 39 octets plus la surcharge de la chaîne de longueur variable.
Contrairement à IPv4, il n'est pas sûr de supposer que la longueur moyenne de la chaîne IPv6 sera moyenne de 6 et 42, car le nombre d'adresses avec un nombre significatif de zéros consécutifs représente une très petite fraction de l'espace d'adressage IPv6 global. Seules certaines adresses spéciales, comme les adresses de bouclage et d'autoconf, sont susceptibles d'être compressibles de cette manière.
Encore une fois, il s'agit d'une pénalité de stockage de > 2x pour l'encodage de chaîne par rapport à l'encodage d'entier.
Mathématiques en réseau
Pensez-vous que les routeurs stockent les adresses IP sous forme de chaînes ? Bien sûr qu'ils ne le font pas.
Si vous avez besoin de faire des calculs réseau sur les adresses IP, la représentation sous forme de chaîne est un problème. Par exemple. si vous souhaitez écrire une requête qui recherche toutes les adresses sur un sous-réseau spécifique ("retourne tous les enregistrements avec une adresse IP dans 10.7.200.104/27", vous pouvez facilement le faire en masquant une adresse entière avec un masque de sous-réseau entier. ( Mongo ne prend pas en charge cette requête particulière, mais la plupart des SGBDR le font.) Si vous stockez des adresses sous forme de chaînes, votre requête devra convertir chaque ligne en un entier, puis la masquer, ce qui est plusieurs ordres de grandeur plus lent. (Masquage au niveau du bit pour une adresse IPv4 peut être fait en quelques cycles CPU en utilisant 2 registres. La conversion d'une chaîne en entier nécessite une boucle sur la chaîne.)
De même, les requêtes de plage ("retourner tous les enregistrements tous les enregistrements entre 192.168.1.50 et 192.168.50.100") avec des adresses entières pourront utiliser des index, contrairement aux requêtes de plage sur les adresses de chaîne.
L'essentiel
Cela demande un peu plus de travail, mais pas beaucoup (il y a un million de fonctions aton() et ntoa() là-bas), mais si vous construisez quelque chose de sérieux et solide et que vous voulez le pérenniser par rapport aux exigences futures et la possibilité d'un ensemble de données volumineux, vous devez stocker les adresses IP sous forme d'entiers et non de chaînes.
Si vous faites quelque chose de rapide et sale et que la possibilité de remodeler à l'avenir ne vous dérange pas, utilisez des cordes.
Pour les besoins de l'OP, si vous optimisez la vitesse et l'espace et que vous ne pensez pas vouloir l'interroger souvent, alors pourquoi utiliser une base de données ? Imprimez simplement les adresses IP dans un fichier. Ce serait plus rapide et plus efficace en termes de stockage que de le stocker dans une base de données (avec l'API associée et la surcharge de stockage).
