Sla IP-adressen zeker op als getallen, als u het extra beetje werk dat het kost niet erg vindt, vooral als u query's op de adressen moet doen en u grote tabellen/verzamelingen heeft.
Dit is waarom:
Opslag
- Een IPv4-adres is 4 bytes als het wordt opgeslagen als geheel getal zonder teken.
- Een IPv4-adres varieert tussen 10 bytes en 18 bytes wanneer het wordt uitgeschreven als een tekenreeks in gestippelde oct-vorm. (Laten we aannemen dat het gemiddelde 14 bytes is.)
Dat is 7-15 bytes voor de tekens, plus 2-3 bytes als je een stringtype met variabele lengte gebruikt, dat varieert op basis van de database die je gebruikt. Als u een tekenreeksweergave met een vaste lengte beschikbaar heeft, moet u een veld van 15 tekens met een vaste breedte gebruiken.
Schijfopslag is goedkoop, dus dat speelt in de meeste gevallen geen rol. Geheugen is echter niet zo goedkoop, en als je een grote tabel/verzameling hebt en je snelle queries wilt doen, dan heb je een index nodig. De 2-3x opslagstraf van stringcodering vermindert drastisch het aantal records dat u kunt indexeren, terwijl de index toch in het geheugen blijft.
- Een IPv6-adres is 16 bytes als het wordt opgeslagen als een geheel getal zonder teken. (Waarschijnlijk als meerdere gehele getallen van 4 of 8 bytes, afhankelijk van uw platform.)
- Een IPv6-adres varieert van 6 bytes tot 42 bytes wanneer het wordt gecodeerd als een tekenreeks in afgekorte hexadecimale notatie.
Aan de lage kant is een loopback-adres (::1) 3 bytes plus de stringoverhead met variabele lengte. Aan de bovenkant, een adres als 2002:4559:1FE2:1FE2:4559:1FE2:4559:1FE2 gebruikt 39 bytes plus de stringoverhead met variabele lengte.
In tegenstelling tot IPv4 is het niet veilig om aan te nemen dat de gemiddelde IPv6-stringlengte gemiddeld 6 en 42 zal zijn, omdat het aantal adressen met een aanzienlijk aantal opeenvolgende nullen een zeer kleine fractie is van de totale IPv6-adresruimte. Slechts enkele speciale adressen, zoals loopback- en autoconf-adressen, kunnen op deze manier waarschijnlijk worden gecomprimeerd.
Nogmaals, dit is een opslagboete van>2x voor stringcodering versus codering van gehele getallen.
Netwerkwiskunde
Denk je dat routers IP-adressen opslaan als strings? Natuurlijk niet.
Als u netwerkberekeningen op IP-adressen moet uitvoeren, is de tekenreeksweergave een gedoe. bijv. als je een query wilt schrijven die zoekt naar alle adressen op een specifiek subnet ("retourneer alle records met een IP-adres in 10.7.200.104/27", dan kun je dit eenvoudig doen door een integer adres te maskeren met een integer subnetmasker. ( Mongo ondersteunt deze specifieke zoekopdracht niet, maar de meeste RDBMS wel.) Als u adressen opslaat als tekenreeksen, moet uw zoekopdracht elke rij naar een geheel getal converteren en deze vervolgens maskeren, wat enkele ordes van grootte langzamer is. voor een IPv4-adres kan in een paar CPU-cycli worden gedaan met behulp van 2 registers. Om een string naar een geheel getal om te zetten, moet de string worden doorgelust.)
Op dezelfde manier kunnen bereikquery's ("retourneert alle records alle records tussen 192.168.1.50 en 192.168.50.100") met integer-adressen indexen gebruiken, terwijl bereikquery's op tekenreeksadressen dat niet zullen doen.
Waar het op neerkomt
Het kost wat meer werk, maar niet veel (er zijn een miljoen aton() en ntoa()-functies die er zijn), maar als je iets serieus en solide aan het bouwen bent en je het toekomstbestendig wilt maken tegen toekomstige vereisten en de mogelijkheid van een grote dataset, moet u IP-adressen opslaan als gehele getallen, niet als strings.
Als je iets snel en vies doet en het niet erg vindt om in de toekomst te verbouwen, gebruik dan strings.
Voor het doel van het OP, als je optimaliseert voor snelheid en ruimte en je denkt dat je het niet vaak wilt opvragen, waarom dan überhaupt een database gebruiken? Druk gewoon IP-adressen af naar een bestand. Dat zou sneller en efficiënter zijn dan het opslaan in een database (met bijbehorende API en opslagoverhead).