分词器一定要结合Lucene使用吗

在很多时候我们面临的解决方案总是非常的让人难受，那么分词器真的有必要去让我们实现Lucene这种结构吗。我觉得并不是，在底层的一翻挖掘之后我发现lucene的存储策略有五种

MMapDirectory,NIOFSDirectory,SimpleFSDirectory，FSDirectory，RAMDirectory ，其中我讲三种mmapDirectory基于虚拟内存，RAMDirectory 基于内存存储数据，以及FSDirectory 基于硬盘存储，

而他的结构到底是什么样子的呢，一个索引库一个文件库。我成功的进行过索引，但是这种东西的速度并不是很快，可以支持多线程读取，但是无法支持批量添加的操作，这也会与lucene的本质有极大的关系，在源码之中我们可以看到很多关于存储优化io优化的过程，这种过程的出现也极大的展现出了各代之间的差异性，

跨版本之间的代码不兼容。在我上一个项目的时候采用的是lucene7.2.1的版本，当前项目应用的是lucene的5.5.0版本。上一个项目是互联网项目，于是我们把Lucene存到了硬盘上，而后在用户检索的时候实现了一次异步的数据缓存。在数据产生变化的时候就会去更改我们所面临的缓存更改，这个缓存数据库我们采用的是redis

这个时候我们项目进行了一次初始化加载，也就是把以前的数据进行了回滚，很幸运的就是我们的数据回滚这一次却是命中了极其庞大数量的索引策略。

而我们的缓存更改机制，以及缓存的持久化操作，为我们项目提供了更稳定的宕机基础。

好我的方案就是redis和分词器组合，每一个分词结果对应一个数据集合，当然Lucene的那个交集查询并没有比我们想象的高级多少，也是基于余弦定理出现的数据排比。（就回到第一篇文章的问题，余弦定理在自然语言处理中一次除法的速度快还是一次读取的速度快）