Elasticsearch Adoption and Architecture Cases in Major Chinese Companies
The article surveys how leading Chinese tech firms such as JD Daojia, Ctrip, Qunar, 58.com, and Didi have adopted Elasticsearch for large‑scale search, real‑time analytics, and security, detailing their evolving cluster architectures, shard strategies, data volumes, and supporting services.
Elasticsearch is widely used by many Chinese companies, including Ctrip, Didi, Toutiao, Ele.me, 360 Security, Xiaomi, and Vivo, not only for search but also for real‑time big‑data analysis, log monitoring, metrics, and information security.
1. JD Daojia Order Center Elasticsearch Evolution – The order center faces massive read‑heavy traffic, prompting a shift from MySQL to Elasticsearch for query offloading. The cluster now stores 1 billion documents with daily queries reaching 500 million, employing a real‑time active‑standby architecture with VIP load balancing, gateway client nodes, and a primary‑replica shard layout (one primary, two replicas) to ensure stability and performance.
The design balances shard count to optimize both single‑ID lookups and paginated aggregations, adjusting the number of shards after extensive load testing.
2. Ctrip Elasticsearch Use Cases
• Hotel order search uses real‑time indexing of sharded databases and a dedicated web service for efficient queries.
• Flight ticket cluster management involves a 120‑node data cluster across 70 servers, handling 60 billion daily index entries, peak indexing rates of millions per second, and a total data volume of about 1 PB.
3. Qunar Order Center Solution – To handle 1 million+ daily orders, Qunar moved from hot‑table sharding to Elasticsearch for searchable fields while keeping detailed data in MySQL. The index uses 8 shards, storing 140 million documents (≈64 GB) on a 240 GB cluster.
4. 58.com Information Security Department – The Elastic Stack is deployed for security log collection, storage selection, performance tuning of master and data nodes, high‑throughput low‑latency search, and Kibana visualizations.
5. Didi Multi‑Cluster Architecture – Since 2016 Didi operates over 3 500 Elasticsearch instances storing >5 PB of data with peak write throughput >20 million TPS. Data ingestion is managed by a Sink service that consumes Kafka streams (logs, binlogs, custom metrics) and writes to multiple clusters for disaster recovery. A Gateway service provides HTTP/REST, TCP, and SQL interfaces, handling authentication, rate‑limiting, index separation, DSL throttling, and cross‑cluster failover.
6. Practical Order Search Solution – Leveraging Elasticsearch’s support for structured queries and near‑real‑time updates, the solution abstracts order models, stores searchable fields in ES, and uses service‑oriented architecture to provide unified APIs for front‑ and back‑end applications and reporting systems.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Java Captain
Focused on Java technologies: SSM, the Spring ecosystem, microservices, MySQL, MyCat, clustering, distributed systems, middleware, Linux, networking, multithreading; occasionally covers DevOps tools like Jenkins, Nexus, Docker, ELK; shares practical tech insights and is dedicated to full‑stack Java development.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
