Logo
NeoArc Studio

Search Profiles

Search profiles configure how model entities project into search indexes across supported engines including Elasticsearch, Azure Cognitive Search, OpenSearch, Typesense, Algolia, and custom engines. Includes operational strategies, index lifecycle management, and search drift detection.

Search infrastructure is often treated as a separate concern from the data model. A search engineer writes index mappings in JSON. A data architect designs entity-relationship models. The two artefacts exist in different repositories with no formal connection. When the data model changes, the search index may or may not be updated. When a new field is added to the search index, it may or may not correspond to a real model property.

Search profiles bridge this gap by making search index configuration a first-class part of the model. Each model property can carry search-specific metadata (searchable, filterable, sortable, analyser, boost, vector dimensions), and each search profile defines how abstract types map to engine-specific field types. The result is search index configuration that is traceable back to the model and governed by the same lifecycle and validation rules.

Supported Search Engines

Elasticsearch
Full support for field types, analysers, custom analysers, synonym maps, ILM policies, rollover, and shard configuration.
Azure Cognitive Search
Edm.* type mappings, scoring profiles, language analysers, synonym maps, and semantic search configuration.
OpenSearch
Compatible with Elasticsearch mappings plus OpenSearch-specific field types and analyser configurations.
Typesense
Type mappings for Typesense field types with facet and sort configuration aligned to Typesense conventions.
Algolia
Attribute configuration for searchableAttributes, attributesForFaceting, and customRanking.
Custom
Configurable type mappings and naming conventions for any search engine not covered by built-in profiles.

Profile Configuration

Each search profile contains engine-level settings that apply to all entities projected through it.

SettingPurposeExample
Engine vendorTarget search engineElasticsearch, Azure Cognitive Search, etc.
Naming conventionHow property names are transformed for index fieldscamelCase for Elasticsearch, PascalCase for Azure
Index naming conventionHow entity names are transformed for index namessnake_case: Customer becomes customer
Type mappingsAbstract-to-concrete type mappings for the target enginestring maps to keyword, text maps to text
Default analyserFallback analyser when none specified on propertystandard, english, custom
Synonym mapsProfile-scoped synonym definitionsProduct synonyms: laptop, notebook, computer
Custom analysersProfile-scoped analyser definitions with tokenisers and filtersEdge n-gram analyser for autocomplete
Shard count and replicasIndex infrastructure settings3 primary shards, 1 replica
Refresh intervalHow often the index is refreshed for near-real-time search1 second, 30 seconds, manual

Operational Strategies

Search profiles go beyond schema configuration to include operational concerns that are critical for production search infrastructure.

Change Tracking
Four strategies: high-water-mark (track changes via a timestamp field), SQL-integrated (use database change tracking), full reindex (periodic complete rebuild), or custom. The tracking field is selected from entity properties.
Deletion Strategy
Four strategies: soft-delete (mark as deleted using a property field), hard-delete (remove from index immediately), archive (move to archive index), or tombstone (keep deleted record with deletion metadata).
Index Aliases
Three swap strategies: blue-green (maintain two indexes, swap alias), rolling (create new index, populate, swap), or manual. Template variables support versioned naming.
Environment Overrides
Per-environment configuration overrides for shard count, replica count, refresh interval, and other infrastructure settings. Development uses 1 shard; production uses 5.

Index Lifecycle Management

For time-series and high-volume indexes, search profiles support lifecycle policies that move data through temperature tiers.

PhaseConfigurationPurpose
HotDuration (e.g., 7 days)Active writing and querying, highest performance tier
WarmDuration + optional force mergeRead-optimised, reduced resources, merged segments for efficiency
ColdDurationInfrequent access, minimal resources, compressed storage
DeleteDurationData removed after retention period expires

Rollover Configuration

Rollover policies control when a new index is created to prevent any single index from growing too large.

TriggerConfigurationExample
Max sizeSize value with unit (MB, GB, TB)Roll over at 50 GB
Max documentsDocument count thresholdRoll over at 10 million documents
Max ageDuration value with unitRoll over after 30 days

Search Drift Detection

The Search Drift Detection service compares the design-time schema (model properties + search profile) against a deployed search index to identify discrepancies.

Drift TypeDescriptionSeverity
field-addedA field exists in the deployed index but not in the modelWarning
field-removedA field exists in the model but not in the deployed indexError
type-changedThe field type in the deployed index differs from the model projectionError
analyzer-changedThe analyser configuration differs between model and deployed indexWarning
field-renamedA field appears to have been renamed (matched by type and position)Info