sql >> Database teknologi >  >> NoSQL >> MongoDB

gem IP-adresse i mongoDB

Gem helt sikkert IP-adresser som tal, hvis du ikke har noget imod det ekstra arbejde, det kræver, især hvis du skal lave forespørgsler på adresserne, og du har store tabeller/samlinger.

Her er grunden:

Opbevaring

  • En IPv4-adresse er 4 bytes, hvis den er gemt som heltal uden fortegn.
  • En IPv4-adresse varierer mellem 10 bytes og 18 bytes, når den skrives ud som en streng i punkteret octed form. (Lad os antage, at gennemsnittet er 14 bytes.)

Det er 7-15 bytes for tegnene, plus 2-3 bytes, hvis du bruger en strengtype med variabel længde, som varierer baseret på den database, du bruger. Hvis du har en strengrepræsentation med fast længde tilgængelig, skal du bruge et felt med fast bredde på 15 tegn.

Disklager er billigt, så det er ikke en faktor i de fleste tilfælde. Hukommelse er dog ikke så billig, og hvis du har en stor tabel/samling, og du vil lave hurtige forespørgsler, så skal du have et indeks. 2-3x lagerstraffen for strengkodning reducerer drastisk mængden af ​​poster, du kan indeksere, samtidig med at indekset bevares i hukommelsen.

  • En IPv6-adresse er 16 bytes, hvis den er gemt som et heltal uden fortegn. (Sandsynligvis som flere 4 eller 8 byte heltal, afhængigt af din platform.)
  • En IPv6-adresse går fra 6 bytes til 42 bytes, når den er kodet som en streng i forkortet hex-notation.

I den lave ende er en loop-back-adresse (::1) 3 bytes plus strengen med variabel længde overhead. I den høje ende, en adresse som 2002:4559:1FE2:1FE2:4559:1FE2:4559:1FE2 bruger 39 bytes plus den variable længde streng overhead.

I modsætning til med IPv4 er det ikke sikkert at antage, at den gennemsnitlige IPv6-strenglængde vil være gennemsnittet af 6 og 42, fordi antallet af adresser med et betydeligt antal på hinanden følgende nuller er en meget lille brøkdel af det samlede IPv6-adresserum. Kun nogle specielle adresser, såsom loopback- og autoconf-adresser, vil sandsynligvis være komprimerbare på denne måde.

Igen er dette en lagringsstraf på>2x for strengkodning versus heltalskodning.

Netværksmatematik

Tror du, at routere gemmer IP-adresser som strenge? Selvfølgelig gør de ikke.

Hvis du skal lave netværksmatematik på IP-adresser, er strengrepræsentationen et besvær. For eksempel. hvis du vil skrive en forespørgsel, der søger efter alle adresser på et specifikt undernet ("returner alle poster med en IP-adresse i 10.7.200.104/27", kan du nemt gøre dette ved at maskere en heltalsadresse med en heltalsundernetmaske. ( Mongo understøtter ikke denne særlige forespørgsel, men de fleste RDBMS gør det.) Hvis du gemmer adresser som strenge, skal din forespørgsel konvertere hver række til et heltal og derefter maskere den, hvilket er flere størrelsesordener langsommere. (Bitwise maskering for en IPv4-adresse kan udføres i nogle få CPU-cyklusser ved hjælp af 2 registre. Konvertering af en streng til et heltal kræver, at man løkker over strengen.)

På samme måde vil områdeforespørgsler ("returner alle poster alle poster mellem 192.168.1.50 og 192.168.50.100") med heltalsadresser være i stand til at bruge indekser, hvorimod områdeforespørgsler på strengadresser ikke vil.

Bundlinjen

Det kræver lidt mere arbejde, men ikke meget (der er en million aton() og ntoa() funktioner derude), men hvis du bygger noget seriøst og solidt, og du vil fremtidssikre det mod fremtidige krav og muligheden for et stort datasæt, bør du gemme IP-adresser som heltal, ikke strenge.

Hvis du laver noget hurtigt og beskidt og ikke har noget imod muligheden for ombygning i fremtiden, så brug strenge.

Til OP's formål, hvis du optimerer for hastighed og plads, og du ikke tror, ​​du vil forespørge det ofte, hvorfor så overhovedet bruge en database? Bare udskriv IP-adresser til en fil. Det ville være hurtigere og mere lagringseffektivt end at gemme det i en database (med tilhørende API og lagringsoverhead).



  1. Opret forbindelse til AWS ElastiCache med In-Transit-kryptering

  2. arrayFilters i mongodb

  3. MongoDB samlet forespørgsel ved hjælp af PHP-driver

  4. Bedste måde at gemme dato/tid i mongodb