Sicuramente salva gli indirizzi IP come numeri, se non ti dispiace il lavoro extra che ci vuole, soprattutto se devi fare query sugli indirizzi e hai tabelle/raccolte di grandi dimensioni.
Ecco perché:
Archiviazione
- Un indirizzo IPv4 è 4 byte se memorizzato come intero senza segno.
- Un indirizzo IPv4 varia tra 10 byte e 18 byte se scritto come stringa in forma di ottavi puntati. (Supponiamo che la media sia di 14 byte.)
Cioè 7-15 byte per i caratteri, più 2-3 byte se stai utilizzando un tipo di stringa di lunghezza variabile, che varia in base al database che stai utilizzando. Se hai a disposizione una rappresentazione di stringa di lunghezza fissa, devi utilizzare un campo a larghezza fissa di 15 caratteri.
L'archiviazione su disco è economica, quindi non è un fattore nella maggior parte dei casi d'uso. La memoria, tuttavia, non è così economica e se si dispone di una tabella/raccolta di grandi dimensioni e si desidera eseguire query veloci, è necessario un indice. La penalità di archiviazione di 2-3 volte la codifica delle stringhe riduce drasticamente la quantità di record che puoi indicizzare mantenendo l'indice residente in memoria.
- Un indirizzo IPv6 è 16 byte se memorizzato come intero senza segno. (Probabilmente come interi multipli da 4 o 8 byte, a seconda della piattaforma.)
- Un indirizzo IPv6 varia da 6 a 42 byte se codificato come stringa in notazione esadecimale abbreviata.
Nella fascia bassa, un indirizzo di loopback (::1) è di 3 byte più l'overhead della stringa di lunghezza variabile. Nella fascia alta, un indirizzo come 2002:4559:1FE2:1FE2:4559:1FE2:4559:1FE2 utilizza 39 byte più l'overhead della stringa di lunghezza variabile.
A differenza di IPv4, non è sicuro presumere che la lunghezza media della stringa IPv6 sarà media di 6 e 42, perché il numero di indirizzi con un numero significativo di zeri consecutivi è una frazione molto piccola dello spazio di indirizzi IPv6 complessivo. È probabile che solo alcuni indirizzi speciali, come gli indirizzi di loopback e autoconf, siano comprimibili in questo modo.
Ancora una volta, questa è una penalità di archiviazione di>2x per la codifica di stringhe rispetto alla codifica di interi.
Matematica di rete
Pensi che i router memorizzino gli indirizzi IP come stringhe? Ovviamente no.
Se è necessario eseguire calcoli di rete sugli indirizzi IP, la rappresentazione della stringa è una seccatura. Per esempio. se vuoi scrivere una query che cerchi tutti gli indirizzi su una sottorete specifica ("restituisci tutti i record con un indirizzo IP in 10.7.200.104/27", puoi farlo facilmente mascherando un indirizzo intero con una maschera di sottorete intera. ( Mongo non supporta questa particolare query, ma la maggior parte degli RDBMS lo fa.) Se memorizzi gli indirizzi come stringhe, la tua query dovrà convertire ogni riga in un numero intero, quindi mascherarla, che è più lenta di diversi ordini di grandezza (mascheramento bit a bit per un indirizzo IPv4 può essere eseguito in pochi cicli della CPU utilizzando 2 registri. La conversione di una stringa in un numero intero richiede il ciclo della stringa.)
Allo stesso modo, le query di intervallo ("restituiscono tutti i record tutti i record tra 192.168.1.50 e 192.168.50.100") con indirizzi interi potranno utilizzare gli indici, mentre le query di intervallo su indirizzi stringa no.
Il risultato finale
Ci vuole un po' più di lavoro, ma non molto (ci sono un milione di funzioni aton() e ntoa() là fuori), ma se stai costruendo qualcosa di serio e solido e vuoi renderlo a prova di futuro contro i requisiti futuri e la possibilità di un set di dati di grandi dimensioni, dovresti memorizzare gli indirizzi IP come numeri interi, non come stringhe.
Se stai facendo qualcosa di veloce e sporco e non ti dispiace la possibilità di rimodellare in futuro, usa le stringhe.
Ai fini dell'OP, se stai ottimizzando per velocità e spazio e non pensi di voler interrogarlo spesso, perché utilizzare un database? Basta stampare gli indirizzi IP su un file. Sarebbe più veloce ed efficiente in termini di archiviazione rispetto all'archiviazione in un database (con API e sovraccarico di archiviazione associati).
