导图社区 Es数据清洗方案设计
Es数据清洗方案设计，可以学习一些关于流程设计的东西，本图知识梳理清楚，非常实用，值得收藏。
社区模板帮助中心，点此进入>>
互联网9大思维
组织架构-单商户商城webAPP 思维导图。
域控上线
python思维导图
css
CSS
计算机操作系统思维导图
计算机组成原理
IMX6UL(A7)
考试学情分析系统
ES数据筛选方案
订单维度存储
优势
数据导入比较方便
根据条件筛选数据比较方便
劣势
排序以及分页处理比较麻烦
返回用户维度的数据也需要处理
用户信息无法详细的确认
不考虑订单维度存储数据
用户维度存储
处理数据方便，返回的数据格式就是用户维度
分页排序比较方便
用户信息已处理完成
方便后续用户维度的数据操作
脚本筛选会随着数据量递增，效率递减
选择用户维度
实时查询效率问题，以及无法确认数据量
数据中间层
ES
查询数据数据方便
数据可以很直观的展示
分页排序比较简单直接
以商户为维度的话，索引太多，后期维护比较难
一个索引，以标识区分商户，数据量大，查询效率会降低
增删数据性能比较慢
这个可以在凌晨做数据更新
字段类型创建就无法修改
大量增删数据容易产生碎片，删除文档并没有真正删除，只是做个标记不被查询到
使用forcemerge命令合并段减少分片中段数量、删除冗余数据，根据删除的频率和数据量确认一个时间去执行
POST /merchant_user_433028/_forcemerge?only_expunge_deletes=true
。索引太多的话维护成本高。适合做大数据检索，增删性能不太好，索引分片的数量影响读写性能、故障恢复速度，且字段类型无法修改
mysql
查询数据方便
分页，排序操作简单
数据可以直观展示
千万级数据以上，mysql性能会直线下降
大量增删操作，会导致相应的锁
数据更改放在晚上处理，不要影响白天的业务流程或者新增临时表去处理
数据存储是结构化的，后续更改数据结构比较麻烦
大数据性能操作较低，做集群成本较高，数据储存为结构化数据，如果后期数据结构变动，可能会比较麻烦
redis
分页操作简单
数据不够直观
结果集查询不方便，查询非常依赖key
大key查询，性能存在问题
数据存储在内存中，数据量就有很大限制
redis不适用大数据存储，大key查询很影响性能，数据不直观
mongodb
数据可以直观显示
大数据存储，单节点就能够支持
php-mongodb不支持swoole协程，只能通过task去处理
占用磁盘空间很大
频繁删除数据之后，会产生很多磁盘碎片
db.merchant_user.runCommand('compact');运行过程会产生相应的锁，尽量在凌晨运行，根据删除的频率和数据量确认一个时间去执行。
当从MongoDB中删除文档或集合后，MongoD不 会将Disk空间释放给OS，MongoDB在数据文 件（Data Fies）中维护Empty Records的列 表。当重新插入数据后，MongoDB从Empty Re cords列表中分配存储空间给新的Document
大数据存储，查询，更新，聚合比较方便，各方面较性能都比较好，非结构化数据存储
获取客户端的查询条件，并创建一个task_id和条件存入到redis中
创建一个crontab，获取redis里面task_id和查询条件
如果获取不到，就直接break
获取数据进行下一步
判断db数据库，当前商户下面的商户数量
如果查询数据+本来的数据大于等于五万
查询五万减当前数据，并删除掉redis
如果查询数据+本来的数据小于五万
继续下一个商户，获取redis里面的task_id和查询条件
数据什么时候清除的问题：客户端查询完，给我们一个ack确认，我们再去删除数据？还是说我们这边制定时间定时去删除？
