Everything在生产环境的应用

Everything是一款知名的文件检索软件, 体积小巧, 功能强大, 而且免费. 基本的使用非常简单, 网上也有不少文章介绍.官网上的教程相当全面, 扫一遍, 需要的时候再细细查看, 实在不行可以在官网的BBS翻一翻帖子, 真的是比较新的问题, 提问后管理员的反馈还是很迅速的. 我观察到网上的介绍一般都局限于个人电脑, 管理文件数量都是在万/十万这个量级, 很少有跑在工作站和服务器硬件上以及管理千万/亿个文件级别的经验分享.先下结论: 硬件可以支持的情况下, Everything完全可以管理亿这个量级数量文件的实时检索, 最新的版本的稳定性可以保证生产环境24X365服务不中断. 更高的十亿量级数量文件的支持, 基于这六七年使用的情况和经验推断, 也是没问题的(没有数据, 对此结论不负责任).

本文着重介绍几个在生产环境下比较重要的特性, 给对生产环境有需要的人一点参考, 算是最佳实践吧.

首先亮一下硬件:

其次, 服务器上Everything可以实时检索3.6亿个以上的文件.

其中一个Everything实例中的文件数量:

另外一个Everything实例中的文件数量:

这个服务器是一台文件共享服务器, 大约有500台测试设备向这里实时写入txt的日志, 平均每秒会有3个文件写入.

最后说一下日常的使用:

• 数据检索入口, 可以给终端用户一个简单的查询接口, 能够从海量数据里迅速获取感兴趣的数据.

Everything提供了一个Web界面, 这个可以在设置里开启. 同时, 可以通过一些简单的CSS和图片资源的替换, 将界面包装成符合实际需求的样式, 比如插入公司Logo等. 对于复杂的界面需求, 比如在界面上再加个按钮等, 作者还提供了定制化JS文件的包, 我印象中没有在网站说明中公开, 论坛有提及和提供.

• 批量查询需求, 能够按照查询要求给出所有的文件.

本身Web界面的查询结果支持JSON格式的返回, 这是精髓所在. 这时千万/亿级别的文件的文件名, 所在文件夹, 所在路径, 创建时间, 修改时间以及文件大小等同于一个现成的高效率数据库, 这是一切批量定制化查询需求的根基所在.

• 大数据量下的多实例和效率考量

对于内存的占用, 大约1000万个文件会占用1.1G内存. 程序冷启动的话, 重建2亿个文件的索引大约需要30 -40 分钟. 对于更多的文件, 出于效率和关闭后再次打开考量, 建议拆成多个实例. Everything支持使用命令行开启多个实例的特性. 在生产环境中, 可以将超过2年或者更早的数据单独存放, 开启一个Everything实例, 将Web访问的端口改成年份, 比如2018, 2016, 便于记忆.

• 安全考量

本身Web访问支持用户名和密码, 但是并没有做权限分级, 而且对于大数据量情况下, 输入一个*执行查询, 多来个几次, 会严重堵塞整个程序. 这时候, 建议在加密的基础上, 重新制作一个页面, 这样能够比较便利地进行输入过滤. 这个页面后台去访问Everything, 对于返回的JSON则能做比较好的权限管控, 最终呈现给用户.

• 最佳实践和杂项
  1. 一些生产环境下的软件在开启时需要和服务器做文件同步, 比较粗暴的做法就是服务器上定时生成一份含有最后更新时间的文件列表, 软件开启时下载这份列表和本地文件做比对, 时间不同的则下载. 对于服务器文件比较多, 更新又比较频繁的情况, 借助Everything可以做到1秒内更新文件列表.
  2. 根据最后修改时间存档文件. 比如要把超过5年的文件从生产服务器移走, 存放到更为廉价的存储介质上, 那么借助Everything就能通过几十行代码轻松完成迁移, 省去了遍历生产服务器的低效率. JSON的返回支持一次返回的条数上限, 对于迁移来说, 一次查询剪切100个文件, 不会对前台用户web的 查询产生可感知的影响.
  3. 多个服务器的某些文件夹下的文件对比/ 单个服务器文件重复检测, 这个的核心也是借助JSON返回做对比解析, 一般来说配合LINQ效果绝佳.
  4. 在GUI界面下按Ctrl + ~可以调出控制台, 可以看到Everything做的更具体的事情. 关闭也需要用同样的快捷键, 右上角关掉控制台则意味着彻底关闭整个进程.
  5. 早先的版本在多线程时创建文件索引有崩溃的可能性, 在配置文件里把使用CPU核心改为1可作为workaround. 还有些版本在文件数量超过7,8千万时会肯定崩溃, 后来解决了.

Everything在生产环境的应用

原文：https://www.cnblogs.com/tom-zh/p/14223165.html