Tak więc zapytania z podwójnym zakresem są w Mongo nierozważne. Zakładam, że masz jeden indeks zawierający zarówno {start_ip_num: 1, end_ip_num: 1} .
Jeśli to nie sprawi, że jesteś wystarczająco blisko (często jest to nadal powolne, jeśli masz wystarczającą ilość danych zwróconych przez pierwsze pole, ponieważ musi wykonać dużo skanowania B-drzewa), możesz zrobić jedną sztuczkę, aby to zwalczyć za pomocą zapytań 2D box (działa tylko dla dwóch zakresów na raz).
Zasadniczo umieszczasz indeks geograficzny 2D na polu zawierającym dwa punkty w tablicy, np. [start_ip, end_ip], i nadajesz mu wystarczająco wysoką wartość min/maks, aby nie osiągnął limitów, które domyślnie są tylko -180/180.
Na koniec użyj zapytania o granice z zakresem od min do wartości $lte w jednym rogu pola oraz wartości gt i max w drugim rogu pola. Zobacz http://www.mongodb.org/display/DOCS/ Geospatial+Indexing#GeospatialIndexing-BoundsQueries dla składni.
Wygląda mniej więcej tak:
db.ip_ranges.find({ip_range:{$within:{$box:[[0, 1204135028], [1204135028, max]]}}});
gdzie max to największy adres IP, jaki możesz mieć.
Minęło trochę czasu, odkąd zajrzałem do tego, więc ramka może być nieprawidłowa, ale koncepcja jest słuszna i sprawiła, że zapytania o podwójnym zakresie działają nieco lepiej niż w przypadku zwykłego dwupolowego indeksu B-drzewa. Konsekwentnie poniżej sekundy (chociaż zwykle kilkaset ms), w porównaniu do kilku sekund ze zwykłym indeksem – myślę, że miałem wtedy setki milionów dokumentów, ale minęło trochę czasu, więc weź te zapamiętane testy porównawcze z ziarnistością z soli. Jestem pewien, że wyniki będą się znacznie różnić w zależności od danych i rozmiarów zakresu.
Aktualizacja: Możesz poeksperymentować z bits ustawienie, wypróbowanie niskiej i wysokiej liczby, aby sprawdzić, czy ma to znaczenie. Dla mnie nie wydawało się to średnio wpływać na zapytania. Zobacz http://www.mongodb.org/display/DOCS/ Geospatial+Indexing#GeospatialIndexing-CreatingtheIndex
dla składni.
