I am doing a kind of room reservation system where a collection is containing documents which contains two dates : a begin date and an end date. I would like to be able to find all the reservation which begin date is between two dates and end date is also between two dates. I have used MongoDB compound indexes thus I am indexing start date and end date field. However I am wondering if I can imporove my query performnce by using GEO2D indexes. For this we could convert begin date and end date to unix time, then each booking is a point whose position is (start date, end date). Using the $within operator it makes it possible to query for reservation which are in a range of start date AND end date.
Since GEO index are more used for spatial data I guess, would it make sense to use them for this specific use-case ?
Finally since GEO2D indexes are inplemented as B-Trees in MongoDB and not as R-Trees, what is the difference between traditional indexes and this GEO one?
It is an interesting idea, but I don't think it will help your search speed or efficiency. Geo indexes in MongoDB are just B-trees applied to a geohash, where the geohash is just a mechanism to convert something that is two dimensional to something that is one dimensional, such that it can be used by B-trees. Geohashing is a powerful concept but has some peculiarities in that points that are close together could end up in totally different buckets, which can make searching for the x nearest points to a point quite inefficient, as 9 boxes have have to searched around your point of interest. A within query would have the same issues. I would have thought that sharding on a date column (possibly as unix time) would be a more efficient way to improve performance, though there are some caveats around using a datatype that is monotonically increased as a shard key, such as a timestamp, see MongoDB shard keys.