Zdecydowanie zapisuj adresy IP jako liczby, jeśli nie masz nic przeciwko dodatkowej pracy, której to wymaga, zwłaszcza jeśli musisz wykonywać zapytania na adresach i masz duże tabele/kolekcje.
Oto dlaczego:
Pamięć
- Adres IPv4 ma 4 bajty, jeśli jest przechowywany jako liczba całkowita bez znaku.
- Adres IPv4 zawiera się w przedziale od 10 do 18 bajtów, gdy jest zapisany jako ciąg znaków w postaci kropkowanej i ósemkowej. (Załóżmy, że średnia wynosi 14 bajtów).
To jest 7-15 bajtów na znaki plus 2-3 bajty, jeśli używasz typu łańcucha o zmiennej długości, który różni się w zależności od używanej bazy danych. Jeśli masz dostępną reprezentację ciągu o stałej długości, musisz użyć 15-znakowego pola o stałej szerokości.
Pamięć masowa na dysku jest tania, więc w większości przypadków nie jest to istotny czynnik. Pamięć nie jest jednak tak tania, a jeśli masz dużą tabelę/kolekcję i chcesz wykonywać szybkie zapytania, potrzebujesz indeksu. 2-3-krotna kara pamięci wynikająca z kodowania ciągów znaków drastycznie zmniejsza liczbę rekordów, które można zindeksować, przy jednoczesnym zachowaniu indeksu rezydującego w pamięci.
- Adres IPv6 ma 16 bajtów, jeśli jest przechowywany jako liczba całkowita bez znaku. (Prawdopodobnie jako wiele 4 lub 8-bajtowych liczb całkowitych, w zależności od platformy).
- Adres IPv6 ma zakres od 6 bajtów do 42 bajtów, gdy jest zakodowany jako ciąg znaków w skróconej notacji szesnastkowej.
Na dole adres pętli zwrotnej (::1) to 3 bajty plus narzut ciągu o zmiennej długości. Na najwyższym poziomie adres taki jak 2002:4559:1FE2:1FE2:4559:1FE2:4559:1FE2 używa 39 bajtów plus narzut ciągu o zmiennej długości.
W przeciwieństwie do IPv4, nie jest bezpiecznie zakładać, że średnia długość ciągu IPv6 będzie wynosić średnio 6 i 42, ponieważ liczba adresów ze znaczną liczbą kolejnych zer stanowi bardzo mały ułamek ogólnej przestrzeni adresowej IPv6. Tylko niektóre specjalne adresy, takie jak adresy pętli zwrotnej i autoconf, mogą być kompresowane w ten sposób.
Ponownie, jest to kara przechowywania>2x za kodowanie łańcuchów w porównaniu z kodowaniem liczb całkowitych.
Matematyka sieci
Czy uważasz, że routery przechowują adresy IP jako ciągi? Oczywiście, że nie.
Jeśli musisz wykonać obliczenia sieciowe na adresach IP, reprezentacja ciągu jest kłopotliwa. Np. jeśli chcesz napisać zapytanie, które wyszukuje wszystkie adresy w określonej podsieci ("zwróć wszystkie rekordy z adresem IP w 10.7.200.104/27", możesz to łatwo zrobić, maskując adres całkowity za pomocą całkowitej maski podsieci. ( Mongo nie obsługuje tego konkretnego zapytania, ale większość RDBMS to robi). dla adresu IPv4 można to zrobić w kilku cyklach procesora przy użyciu 2 rejestrów. Konwersja ciągu na liczbę całkowitą wymaga zapętlenia ciągu.)
Podobnie zapytania o zakres („zwróć wszystkie rekordy, wszystkie rekordy z zakresu od 192.168.1.50 do 192.168.50.100”) z adresami całkowitymi będą mogły używać indeksów, podczas gdy zapytania o zakres dotyczące adresów łańcuchowych nie.
Dolna linia
Wymaga to trochę więcej pracy, ale niewiele (istnieje milion funkcji aton() i ntoa()), ale jeśli budujesz coś poważnego i solidnego i chcesz zabezpieczyć to na przyszłość przed przyszłymi wymaganiami i możliwość dużego zbioru danych, należy przechowywać adresy IP jako liczby całkowite, a nie ciągi.
Jeśli robisz coś szybko i brudno i nie masz nic przeciwko możliwości przebudowy w przyszłości, użyj stringów.
Na potrzeby OP, jeśli optymalizujesz pod kątem szybkości i przestrzeni, a nie sądzisz, że chcesz często zadawać pytania, to po co w ogóle korzystać z bazy danych? Wystarczy wydrukować adresy IP do pliku. Byłoby to szybsze i wydajniejsze przechowywanie niż przechowywanie w bazie danych (z powiązanym interfejsem API i narzutem na przechowywanie).
