Vì vậy, các truy vấn phạm vi kép không được khuyến khích trong Mongo. Tôi giả sử bạn có một chỉ mục duy nhất chứa cả {start_ip_num: 1, end_ip_num: 1} .
Nếu điều đó không giúp bạn đến đủ gần (thường thì nó vẫn chậm nếu bạn có đủ dữ liệu được trả về bởi trường đầu tiên, vì nó phải thực hiện rất nhiều quét B-tree), có một mẹo bạn có thể làm để chống lại điều này sử dụng truy vấn hộp 2D (chỉ hoạt động cho hai phạm vi cùng một lúc).
Về cơ bản, bạn đặt chỉ mục địa lý 2D trên một trường chứa hai điểm trong một mảng, như [start_ip, end_ip] và cung cấp cho nó giá trị tối thiểu / tối đa đủ cao để nó không đạt đến giới hạn theo mặc định. -180/180.
Cuối cùng, sử dụng truy vấn giới hạn với phạm vi đi từ giá trị min đến $ lte ở một góc của hộp, gt và giá trị max ở góc kia của hộp. Xem http://www.mongodb.org/display/DOCS/ Không gian địa lý + Lập chỉ mục # GeospatialIndexing-BoundsQueries cho cú pháp.
Nó trông giống như thế này:
db.ip_ranges.find({ip_range:{$within:{$box:[[0, 1204135028], [1204135028, max]]}}});
trong đó tối đa là ip lớn nhất mà bạn có thể có.
Đã lâu rồi tôi không nhìn thấy cái này, vì vậy hộp có thể sai, nhưng khái niệm này rất hợp lý và nó làm cho các truy vấn phạm vi kép hoạt động tốt hơn một chút so với chỉ mục cây B-cây hai trường thông thường. Liên tục dưới một giây (mặc dù thường là vài trăm mili giây), so với một vài giây với chỉ mục thông thường - tôi nghĩ rằng tôi đã có hàng trăm triệu tài liệu vào thời điểm đó, nhưng đã lâu rồi nên hãy lấy những điểm chuẩn được nhớ này một cách tỉ mỉ muối. Tôi chắc chắn rằng kết quả sẽ khác nhau tùy thuộc vào dữ liệu và kích thước phạm vi của bạn.
Cập nhật: Bạn có thể muốn thử nghiệm với bits cài đặt, thử một số thấp và một số cao để xem liệu nó có tạo ra sự khác biệt hay không. Đối với tôi, nó dường như không ảnh hưởng đến các truy vấn trung bình. Xem http://www.mongodb.org/display/DOCS/ Không gian địa lý + Lập chỉ mục # GeospatialIndexing-CreatetheIndex
cho cú pháp.
