Index Design
Choose indexes from the application’s filters, ordering and paging requirements. Use the operator reference for constructor details and index query examples for filters and spatial candidates.
Two index families
Section titled “Two index families”| Access pattern | Index family | Typical operators |
|---|---|---|
| Sort, exact lookup, prefix/range scan, ordered paging | Ordered | Property reference, Multiple, Reversed, Normalize |
| Search terms across a named set of fields | Search | AnyOf, Split, Normalize |
Ordered indexes
Section titled “Ordered indexes”Compose an ordered tuple in the same leading-field order as the query. Scalar indexes normally produce one key per record; collection indexes can fan out.
Search indexes
Section titled “Search indexes”Search indexes emit terms. Query the named surface with Matches, MatchesPrefix
or MatchesRegEx. They do not provide the application’s record sort order.
Why the distinction matters
Section titled “Why the distinction matters”A catalog can need both ordered browsing and token search over the same fields. Define both when the access patterns require them; normalization alone is not tokenization.
Ordered index building blocks
Section titled “Ordered index building blocks”Reference
Section titled “Reference”Use surname.ref() for the stored value. See Reference.
Normalize
Section titled “Normalize”Transform a value before comparison or tokenization. See Normalize.
Reversed
Section titled “Reversed”Reverse one component’s order. See Reversed.
ReferenceToMax
Section titled “ReferenceToMax”Use max-oriented positioning for a reference component. See ReferenceToMax.
Multiple
Section titled “Multiple”Compose ordered components; leading parts determine useful lookup ranges. See Multiple.
Search index building blocks
Section titled “Search index building blocks”Emit terms with Whitespace or WordBoundary boundaries. See Split.
Combine fields belonging to one search surface. See AnyOf.
Composition patterns
Section titled “Composition patterns”Ordered composition
Section titled “Ordered composition”Multiple(Normalize(surname.ref()), firstName.ref(), Reversed(createdAt.ref()))Compare normalized surname, then first name, then descending creation time.
Search composition
Section titled “Search composition”AnyOf("name", surname.ref(), firstName.ref(), fullName.ref()) .normalize().split(WordBoundary)Normalize and tokenize each child field under the name surface.
Composable syntax
Section titled “Composable syntax”Transforms on AnyOf apply to each child; they do not concatenate fields first.
See equivalent forms.
Query semantics
Section titled “Query semantics”Ordered index queries
Section titled “Ordered index queries”Use property filters and order clauses. See ordered queries.
Search index queries
Section titled “Search index queries”Use the named search filters. See search queries.
Geospatial candidate indexes
Section titled “Geospatial candidate indexes”GeoHash narrows candidates for exact box/radius filters; it does not sort by distance. See spatial candidates.
Design advice
Section titled “Design advice”Define both index types when needed
Section titled “Define both index types when needed”Use separate ordered and search indexes when both browsing and token search are required.
Keep AnyOf focused
Section titled “Keep AnyOf focused”Group related name parts, addresses or aliases into their own user-facing surfaces.
Use Normalize deliberately
Section titled “Use Normalize deliberately”Normalization changes comparison values; adding Split changes term boundaries.
Choose SplitOn based on semantics
Section titled “Choose SplitOn based on semantics”Whitespace separates whitespace; WordBoundary also handles hyphen-like boundaries.
Write regexes for transformed search terms
Section titled “Write regexes for transformed search terms”Target emitted, normalized terms rather than the original stored string.