ElasticSearch分布式搜索储存集群的引入，主要是为了解决订单数据的存储与搜索的问题。
项目背景：
15年去哪儿网酒店日均订单量达到30w+，随着多平台订单的聚合日均订单能达到100w左右。原来采用的热表分库方式，即将最近6个月的订单的放置在一张表中，将历史订单放在在history表中。history表存储全量的数据，当用户查询的下单时间跨度超过6个月即查询历史订单表，此分表方式热表的数据量为4000w左右，当时能解决的问题。但是显然不能满足携程艺龙订单接入的需求。如果继续按照热表方式，数据量将超过1亿条。全量数据表保存2年的可能就超过4亿的数据量。所以寻找有效途径解决此问题迫在眉睫。由于对这预计4亿的数据量还需按照预定日期、入住日期、离店日期、订单号、联系人姓名、电话、酒店名称、订单状态……等多个条件查询。所以简单按照某一个维度进行分表操作没有意义。ElasticSearch分布式搜索储存集群的引入，就是为了解决订单数据的存储与搜索的问题。
具体解决方案：
1、系统性能
对订单模型进行抽象和分类，将常用搜索字段和基础属性字段剥离DB做分库分表。存储订单详情,ElasticSearch存储搜素字段。订单复杂查询直接走ElasticSearch。如下图：
通用数据存储模型
关键字段
■ 业务核心字段，用于查询过滤
系统字段
■ version 避免高并发操作导致数据覆盖
大字段
■ order_data订单详情数据(JSON)
■ 可灵活需要索引的字段返回的字段
2、系统可用性
系统可用性保障：双机房高可用如下图。
数据可用性保障：
一、异步多写保证数据一致性。
二、数据补充机制：
1、每天凌晨task扫描数据库热表数据与es数据版本进行比较。
2、将第三方推送过来数据中的，订单号即时插入订单同步队列表中。如果数据模型解析转换、持久化成功。删除队列中订单号。同时设置1分钟一次的task 扫描队列表。
3、推送第三方的数据也采用同样的方式。保证给第三方数据的准确性。
3、系统伸缩性
elasticSearch中索引设置了8个分片，目前Es单个索引的文档达到到1.4亿,合计达到2亿条数据占磁盘大小64G，集群机器磁盘容量240G。
项目背景：
15年去哪儿网酒店日均订单量达到30w+，随着多平台订单的聚合日均订单能达到100w左右。原来采用的热表分库方式，即将最近6个月的订单的放置在一张表中，将历史订单放在在history表中。history表存储全量的数据，当用户查询的下单时间跨度超过6个月即查询历史订单表，此分表方式热表的数据量为4000w左右，当时能解决的问题。但是显然不能满足携程艺龙订单接入的需求。如果继续按照热表方式，数据量将超过1亿条。全量数据表保存2年的可能就超过4亿的数据量。所以寻找有效途径解决此问题迫在眉睫。由于对这预计4亿的数据量还需按照预定日期、入住日期、离店日期、订单号、联系人姓名、电话、酒店名称、订单状态……等多个条件查询。所以简单按照某一个维度进行分表操作没有意义。ElasticSearch分布式搜索储存集群的引入，就是为了解决订单数据的存储与搜索的问题。
具体解决方案：
1、系统性能
对订单模型进行抽象和分类，将常用搜索字段和基础属性字段剥离DB做分库分表。存储订单详情,ElasticSearch存储搜素字段。订单复杂查询直接走ElasticSearch。如下图：
通用数据存储模型
关键字段
■ 业务核心字段，用于查询过滤
系统字段
■ version 避免高并发操作导致数据覆盖
大字段
■ order_data订单详情数据(JSON)
■ 可灵活需要索引的字段返回的字段
2、系统可用性
系统可用性保障：双机房高可用如下图。
数据可用性保障：
一、异步多写保证数据一致性。
二、数据补充机制：
1、每天凌晨task扫描数据库热表数据与es数据版本进行比较。
2、将第三方推送过来数据中的，订单号即时插入订单同步队列表中。如果数据模型解析转换、持久化成功。删除队列中订单号。同时设置1分钟一次的task 扫描队列表。
3、推送第三方的数据也采用同样的方式。保证给第三方数据的准确性。
3、系统伸缩性
elasticSearch中索引设置了8个分片，目前Es单个索引的文档达到到1.4亿,合计达到2亿条数据占磁盘大小64G，集群机器磁盘容量240G。
[尊重社区原创，转载请保留或注明出处]
本文地址：http://searchkit.cn/article/6197
本文地址：http://searchkit.cn/article/6197
3 个评论
硬件方面只写了磁盘，能不能把内存和CPU都写一下。硬盘是SSD还是普通的硬盘？
ES不支持事务，请问下是如何保证订单表数据完整的导入到es中的？
拿人家途家技术分享的图来当自己的原创，真是好意思！～
