-
Type: New Feature
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Execution Team 2021-07-26, Execution Team 2021-08-09
-
200
For geo types, the summary stored in the control fields is not detailed enough to index it directly. Instead, we must transform the definition to use a new internal index type that is aware of the bucket structure. In particular, a measurement field will be present in the bucket document as data.a, but will hold the column-pivoted data for all measurements. Thus a definition:
{ createIndexes: "abc", indexes: [ { key: { "a" : "2dsphere" } } ] }
will become:
{ createIndexes: "system.buckets.abc", indexes: [ { key: { "data.a" : "2dsphere_bucket" } } ] }
The new index type will treat the field a as a column of points, and generate a region containing the points. From here out, the solution is the same as for existing geo-type indexes: create a covering for the region (using the appropriate space-filling curve library) and generate index keys from the covering.
The new index type should be considered internal. Attempting to create the new index type directly on a non-bucket collection should result in an error. When examining the indexes on a time-series collection, it should report the original index type rather than the new transformed type. Examining the bucket collection directly should return the new type.
- is depended on by
-
SERVER-58371 Allow $_internalBucketGeoWithin to scan 'bucket-2dsphere' index
- Closed
- is related to
-
SERVER-82475 Consolidate S2BucketAccessMethod and S2AccessMethod
- Closed
- related to
-
SERVER-60607 improve handling of large/NaN values for geo index version
- Closed
-
SERVER-59310 clean up library dependencies in db/index/SConscript
- Closed