但不可否认的是，在长期的应用实践中，也发现很多不好处理的流程和场景;对于ES索引的结构维护，数据主体如果相对简单的话，可以考虑手动管理，但实际上使用索引时，通常主体结构都比较复杂，字段个数超过三五十都很常见，所以基于流程化的管理很有必要;
我们知道，完全把数据放在内存中是不可靠的，实际上也不太现实，当我们的数据达到PB级别时，按照每个节点96G内存计算，在内存完全装满的数据情况下，我们需要的机器是：1PB=1024T=1048576G节点数=1048576/96=10922个 实际上，考虑到数据备份，节点数往往在2
可以使用以下命令列出当前存储在存储库中的所有快照:从快照恢复:要从 S3 恢复索引，我们可以执行以下操作:监控快照和恢复进度:我们可以通过以下命令监控快照的状态:每日备份:创建一个 bash 脚本:我们将创建一个 bash 脚本，例如daily_elastic_search_backup.sh如下:将脚本添加到 Crontab:我们现在可以在 crontab 中添加以下行，以便每天凌晨 12 点 UTC 进行备份:另外在实际操作的过程中，一定要注意账号的问题，elaticsearch节点都要设置而且必须一致，不然在备份镜像的时候会提示权限问题。
Mysql到Elasticsearch的数据同步，一般用ETL来实现，但性能并不理想，目前大部分的ETL是定时查询Mysql数据库有没有新增数据或者修改数据，如果数据量小影响不大，但如果几百万上千万的数据量性能就明显的下降很多，本文是使用Go实现的go-mysql-transfe
