搜索索引数据存储咨询：Elasticsearch与关系库重复存储及云安全疑问

Hey Bob, let's break down your questions one by one since they're all super relevant when building a search layer on top of a relational database:

1. Where should search index data be stored? #

The answer depends on whether you're self-hosting Elasticsearch or using a managed cloud service:

• Self-hosted deployments: Always use fast, local SSD storage for your index data. Elasticsearch is extremely IO-intensive, and SSDs drastically improve query and indexing performance. Avoid network-attached storage (like NFS) at all costs—high latency will cripple your cluster. For backup snapshots, you can use object storage (like S3-compatible storage) to offload long-term, low-cost storage of your index backups.
• Managed cloud services: The cloud provider handles the underlying storage for your indices (e.g., Elastic Cloud uses high-performance SSD-backed storage, AWS OpenSearch uses EBS volumes). You’ll typically just need to choose storage tiers based on your performance needs, and configure snapshot repositories to cloud object storage for backups.

2. Is duplicating data between relational databases and Elasticsearch common? Should we only store data in Elasticsearch? #

Duplicating data is extremely common—this is a standard pattern #

Most production systems use a relational database as the single source of truth (handling transactional operations, ACID compliance, and authoritative record-keeping) while syncing a subset or full copy of that data to Elasticsearch for search-specific use cases (full-text search, faceted filtering, fast aggregations). This is called the "search tier" pattern, and it’s widely adopted because it plays to the strengths of each system: relational DBs excel at transactions, Elasticsearch excels at search.

You should almost never store data only in Elasticsearch #

Elasticsearch is not designed to replace a relational database for transactional workloads. It has weak ACID guarantees, limited support for complex transactions, and isn’t ideal for point-in-time updates or referential integrity. The only exception might be pure log/metric analysis use cases where you don’t need to rely on the data for critical business transactions.

3. How secure is storing data entirely in an Elasticsearch cloud service? #

Managed Elasticsearch cloud services (like Elastic Cloud, AWS OpenSearch Service, Google Cloud Elasticsearch Service) are highly secure when configured properly—often more secure than self-hosted clusters, because providers handle many of the heavy lifting:

• Authentication & Authorization: Built-in RBAC (Role-Based Access Control), support for SAML/OAuth2 for enterprise single sign-on, and integration with cloud IAM systems to enforce least-privilege access.
• Encryption: End-to-end encryption in transit (via TLS 1.2+) and at rest (storage-level encryption managed by the cloud provider).
• Network Isolation: Options for VPC peering, private endpoints, and firewall rules to restrict access to your cluster only from trusted networks.
• Security Patching: Providers automatically apply security patches to the underlying Elasticsearch software and infrastructure, eliminating the need for you to manage updates manually.
• Audit Logging: Detailed logs of all cluster access and operations, which helps with compliance (like GDPR, HIPAA) and incident response.

That said, security is a two-way street: you still need to follow best practices, like avoiding open public access to your cluster, rotating credentials regularly, and limiting permissions to only what’s necessary.

内容的提问来源于stack exchange，提问作者Bob