How a Visual Platform Cut Search Costs by 60% with All‑in‑Elasticsearch

Background and Pain Points

A leading entertainment‑focused visual platform (referred to as Company A) operated three isolated search pipelines: a general Elasticsearch‑based keyword search, a separate log‑search service for massive access logs, and an independent Milvus vector store for image similarity and recommendation. This “three‑chimney” architecture caused high nightly compute costs, complex glue code, data inconsistency, and slow full‑sync updates.

Phase 1 – The Three‑Chimney Problem

General search: Material‑center and video keyword search on a large‑scale ES cluster.

Log search: Dedicated log service for compliance storage; expensive 20‑node 8C‑32G fleet ran 16 hours a day at low utilization.

Vector search: Milvus cluster for visual similarity and RAG‑enhanced recommendations, requiring extra glue code to join ES results.

Key pain points included “midnight money‑burn” due to over‑provisioned resources, brittle glue code that caused 404 errors when data diverged, and sluggish full‑sync processes.

Phase 2 – Consolidation to All‑in‑Elasticsearch

After consulting Alibaba Cloud AI Search experts, Company A performed a technical “断舍离” (cut‑off) and migrated all workloads to Alibaba Cloud Elasticsearch (ES) with serverless features.

Log‑Search Refactor

Replaced self‑managed ES nodes with the high‑performance, managed Indexing Service and OpenStore hybrid storage.

Before: 20 servers running 24 h, paying for idle capacity.

After: Serverless scaling automatically adds capacity during peak hours and scales to near‑zero cost during off‑peak, reducing log‑related spend by ~60%.

Vector‑Search Integration

Adopted Alibaba Cloud ES’s native hybrid vector engine (FalconSeek) to replace the separate Milvus cluster.

Latency dropped from >200 ms (vector‑store → ES → app) to a single API call.

FalconSeek’s C++ kernel adds SIMD and HNSW optimizations, delivering >40% vector‑search speedup and up to 4× performance with the Filter‑Knn feature.

Additional optimizations: regular Force Merge on old segments (5× speedup), exclusion of vector fields at ingest (1 TB storage saved), and RRF‑based hybrid ranking that fuses vector similarity with BM25 scores.

Why “All‑in‑ES” Works

Unifying search, log, and vector workloads on a single ES stack simplifies operations: a single console, unified RBAC/VPC security, and consistent monitoring. Serverless elasticity matches the “peak‑valley” traffic pattern of logs, while hybrid storage (OpenStore) separates compute from cheap object storage, cutting storage costs >60%.

Cost‑Effectiveness and Recommendations

Key metrics from the migration:

Compute resources: FalconSeek engine on ecs.g8i/r8i instances boosts vector throughput.

Storage: OpenStore’s compute‑storage separation eliminates high‑cost cold‑data storage.

Write performance: Indexing Service with physical replication reduces CPU load under high write concurrency.

Operations: A single ES cluster serves all teams, cutting fragmented manpower by >20%.

Takeaways

For architects, the topology becomes clearer and more stable; for ops, mastering ES suffices for the entire data‑retrieval stack; for executives, total cost of ownership drops dramatically while gaining enterprise‑grade security and compliance.