16 posts tagged with "opensearch"

Standing up a search stack usually starts the same way every time. Provision an OpenSearch cluster. Stand up Dashboards next to it. Wire Dashboards to the cluster with an endpoint and credentials you paste into a config file. Make sure the security plugin lets the two talk. Decide where Dashboards keeps its saved objects. Only then do you get to the part you actually wanted: indexing data and running a query.

The Launch a search workspace stack collapses that into one button. You get a managed OpenSearch cluster and a full OpenSearch Dashboards workspace, attached and EU-resident, in minutes, with nothing to wire by hand.

Your database lives on FoundryDB. Your app lives somewhere else: a separate PaaS, a VM you babysit, a Kubernetes cluster you would rather not think about. Every query crosses the public internet, hits a firewall rule you opened by IP, and crawls back. Two sets of credentials, two networks, two bills, and a latency floor set by whatever the internet feels like today. That gap is where most of the operational pain in a small-to-medium stack actually lives.

Today we close it. App Hosting on FoundryDB is live. Run your container on a dedicated VM, reachable over HTTPS, wired straight into your managed databases over a private network with credentials handed to it automatically. You deploy your app next to your data, and the connection between them stops being your problem. It becomes the platform's job.

The analyzer you assign to a field determines how text is broken into tokens at index time and at query time. Choosing the wrong one produces surprising results: searches that miss obvious matches, or matches that should not have ranked at all. This post compares the built-in English and standard analyzers, then builds a custom analyzer with synonym support.

All examples were tested against OpenSearch 2.19.1 on FoundryDB staging.

OpenSearch has a native snapshot API that writes index data to remote storage. FoundryDB wraps this API so you can trigger, list, and restore backups without configuring S3 credentials, IAM roles, or snapshot repositories manually. This post documents the backup flow using real metadata from a test run against an OpenSearch 2.19.1 cluster.

All commands use YOUR_SERVICE_ID and YOUR_API_TOKEN as placeholders. The FoundryDB API base is https://api.foundrydb.com.

OpenSearch's security plugin provides index-level permissions, field-level exclusions, and field masking out of the box. All of these are configurable through the Security REST API, which means you can automate role provisioning in CI/CD pipelines without touching the Dashboards UI. This post documents two concrete access control scenarios tested on a live OpenSearch 2.19.1 cluster managed by FoundryDB, with real HTTP responses showing enforcement in action.

All commands use YOUR_OPENSEARCH_HOST and YOUR_PASSWORD as placeholders. Note that the Security API uses the _plugins/_security prefix.

BM25 is precise on exact terms but blind to meaning. Vector search is rich in semantics but can return spurious matches when query and document happen to point in similar directions by coincidence. Hybrid search combines both signals. This post shows how to configure a Reciprocal Rank Fusion (RRF) pipeline in OpenSearch 2.19.1 and documents the difference in results across three approaches, using real scores from a FoundryDB-managed cluster.

All commands use YOUR_OPENSEARCH_HOST and YOUR_PASSWORD as placeholders.

With your OpenSearch cluster running on FoundryDB, the next step is putting data into it and querying it. This post covers explicit index mappings, the bulk ingestion API, full-text search with relevance scoring, fuzzy matching, bool queries, and aggregations.

All results are from real queries run against OpenSearch 2.19.1 on FoundryDB staging. Replace YOUR_HOST and YOUR_DB_PASSWORD with your cluster values throughout.

Log indices grow without bound unless you manage them. OpenSearch Index State Management (ISM) lets you define policies that automatically roll over active write indices when they hit a size or document threshold, and delete old ones after a retention period. This post shows how to build and verify a complete lifecycle policy on a live OpenSearch 2.19.1 cluster managed by FoundryDB.

All commands use YOUR_OPENSEARCH_HOST and YOUR_PASSWORD as placeholders.

OpenSearch SQL is familiar, but Piped Processing Language (PPL) is often better for log analysis: its pipeline syntax maps naturally to how you think about filtering and aggregating event streams. Each | stage narrows or transforms the result set from the previous one. This post runs five PPL queries against a 200-document structured log dataset on a live OpenSearch 2.19.1 cluster managed by FoundryDB. Every number below is from a real query.

All commands use YOUR_OPENSEARCH_HOST and YOUR_PASSWORD as placeholders.

Dense vector search (k-NN) is powerful but requires embedding both documents and queries with a neural model at query time. Neural sparse search takes a different approach: expand tokens with learned weights at index time, store them as a rank_features field, and at query time do a fast lookup rather than a vector computation. The result is semantic search with no GPU requirement at query time. This post shows the full setup on a live OpenSearch 2.19.1 cluster managed by FoundryDB.

All commands use YOUR_OPENSEARCH_HOST and YOUR_PASSWORD as placeholders.