Search Profiles
Search profiles map canonical model types to engine-specific types and define naming conventions, analysers, synonym maps, and operational strategies for 6 supported search engines.
Search profiles define how the central model maps to a specific search engine's index schema. Each profile targets one of 6 supported engines and controls type mappings, naming conventions, analyser defaults, synonym maps, custom analysers, and operational strategies. Profiles are stored as .neoarc-search-profile.json files in .neoarc-project/profiles/.
Supported Search Engines
NeoArc Studio supports 6 search engine vendors. Each profile targets exactly one engine.
| Engine | ID | Default Analyser | Description |
|---|---|---|---|
| Elasticsearch | elasticsearch | standard | Open-source distributed search and analytics engine |
| Azure Cognitive Search | azure-cognitive-search | standard.lucene | Microsoft Azure managed search service |
| OpenSearch | opensearch | standard | AWS-backed open-source search and analytics suite |
| Typesense | typesense | default | Open-source typo-tolerant search engine |
| Algolia | algolia | (schemaless) | Hosted search-as-a-service platform |
| Custom | custom | (configurable) | Custom or unlisted search engine |
Profile Structure
A search profile contains several configuration sections. All fields beyond the engine selection are optional and have sensible defaults.
Synonym Maps
Synonym maps define term equivalences for query expansion. Each profile maintains its own registry of synonym maps, referenced by name from property-level search configuration.
| Rule Type | Direction | Example |
|---|---|---|
| equivalent | Bidirectional | laptop, notebook, portable computer (any term matches any other) |
| explicit | Directional | UK => United Kingdom, Britain (source terms map to target terms only) |
Custom Analysers
Custom analysers compose a tokeniser with token filters and character filters. Each custom analyser is registered at the profile level and becomes available in property-level analyser dropdowns alongside the engine's built-in analysers.
interface SearchCustomAnalyzer {
name: string;
tokenizer: string; // Dropdown lookup from engine's built-in tokenisers
tokenFilters?: string[]; // Add/remove list with dropdown lookup per item
charFilters?: string[]; // Add/remove list with dropdown lookup per item
}Operational Settings
Search profiles include operational configuration that governs how indexes are maintained at runtime.
Change Tracking Strategy
Defines how the indexer detects changed documents.
| Strategy | Description |
|---|---|
| high-water-mark | Uses a timestamp or version column to detect changes since the last indexing run |
| sql-integrated | Relies on SQL Server integrated change tracking |
| full-reindex | Rebuilds the entire index on each run |
| custom | Custom change detection logic |
Deletion Strategy
Controls how document deletions are handled in the index.
| Strategy | Description |
|---|---|
| soft-delete | Marks documents as deleted via a configurable field and value |
| hard-delete | Removes documents immediately from the index |
| archive | Moves deleted documents to an archive index |
| tombstone | Retains a deletion marker for a configurable retention period |
Index Alias Management
Aliases enable zero-downtime reindexing. The alias pattern uses template variables ({indexName}, {version}, {date}, {environment}).
| Swap Strategy | Description |
|---|---|
| blue-green | Builds a new index, then atomically swaps the alias from old to new |
| rolling | Gradually migrates traffic to the new index |
| manual | Requires manual alias swap after the new index is built |
Index Lifecycle Management
For time-series or retention-sensitive indexes, ILM automates tier transitions and cleanup.
| Setting | Description |
|---|---|
| Hot duration | Time in the hot (primary read/write) tier |
| Warm duration | Time in the warm (read-only, reduced resources) tier |
| Cold duration | Time in the cold (archived, minimal resources) tier |
| Delete duration | Time before permanent deletion |
| Force merge on warm | Whether to force-merge segments on transition to warm |
| Rollover: max size | Maximum index size before rollover (MB, GB, or TB) |
| Rollover: max docs | Maximum document count before rollover |
| Rollover: max age | Maximum age before rollover |
Environment Overrides
A single base profile serves multiple environments. Environment overrides vary operational settings while keeping schema-level configuration (type mappings, analysers, engine) constant across environments.
| Overridable Setting | Typical Variation |
|---|---|
| shardCount | 1 in development, 3 in production |
| replicaCount | 0 in development, 2 in production |
| refreshInterval | 1 second in development, 30 seconds in production |
| changeTrackingStrategy | full-reindex in development, high-water-mark in production |
| deletionStrategy | hard-delete in development, soft-delete in production |
| aliasConfig | Disabled in development, blue-green in production |
Engine Features Matrix
Not all features are available on every engine. The matrix below shows which features each engine supports.
| Feature | Elasticsearch | Azure Cognitive Search | OpenSearch | Typesense | Algolia | Custom |
|---|---|---|---|---|---|---|
| Custom Analysers | Yes | Yes | Yes | No | No | Yes |
| Synonym Maps | Yes | Yes | Yes | Yes | Yes | Yes |
| Vector Search | Yes | Yes | Yes | Yes | No | Yes |
| Geo Search | Yes | Yes | Yes | Yes | Yes | Yes |
| Nested Types | Yes | No | Yes | No | No | Yes |
| Index Aliases | Yes | No | Yes | Yes | No | Yes |
| Scoring Profiles | No | Yes | No | No | Yes | Yes |
| Suggesters | Yes | Yes | Yes | Yes | Yes | Yes |
| Index Lifecycle (ILM) | Yes | No | Yes | No | No | Yes |
| Cross-Cluster Search | Yes | No | Yes | No | No | Yes |