高难度，自己开发中文全文索引系统。

Question

自己开发了一个中文全文索引系统，索引文件的存储有问题，我是一个词存在一个文件中，比如“中国”存在“zhong/guo/ix.txt”这个目录文件下，但问题是这样会产生非常多的文件（汉语词汇量+各种英语词汇），文件多达几百万个，超出我的想象，请问各位还有什么好的存储方式吗？

Answer 1

按首字的话单个ix.txt这个文件就会太大，影响查询速度吧

Answer 2

这就看你的选择了。其实文件大了不要紧，只要你有定位索引就没事，打开文件直接跳到指定位置即可。
lucene好像就是1G一个文件。
要注意文件数过大会给OS带来很大压力和硬盘空间的浪费，备份也很麻烦。

Answer 3

额，没你想象的那么严重了，Btree，hash都ok其实把一个输入法的码表会比你这个少很多吗？你这个总体上不会比输入法大出几个数量级的。ok，在同等数量级下，你真的感觉输入法会有多么的慢的让你难受吗

Answer 4

恩，以前用的都是现成的Dictionary，自己做个也不错

Answer 5

现在应该不用做全文检索了，因为lucene.net已经很成熟，

Answer 6

这里的问题不是索引叫什么，而是如何保存文件，具体的文件格式！一个“倒排索引”概念只是数据概念，没有说明如何在磁盘上保存动态的数据的问题（也就是根本没有说明是保存几百万个索引文件还是只用一个索引文件的问题）。
sp1234兄说的很对，牛人也，我的几百万个文件其实就是一个倒排索引架构，目前在三台服务器上运行，已经索引了上千万的文件，文件占用空间在每台14个G左右，关键词组合查询平均不超过1秒，但问题是文件空间占用确实过大（比sqlservger的全文索引文件大出2-3倍，单个索引文件用了些技巧，比如采用硬盘簇大小倍数计算，每个文件正好占用462,848个字节以节省空间），再就是文件太多对操作系统确实有影响，最大影响就是操作系统的文件缓存占用太多内存，以至于内存耗用太大（采用限制windows缓存的设置，但始终是个隐患），所以我也希望采用单文件结构，但开发起来比多文件结构复杂太多，比如单索引文件并发读写的锁结构，基本等于要实现一套sqlserver的读写锁体系才行，不然效率太低（并发200以上的数据提交速度）。
楼上好多同学对我的设计好像有点冷嘲热讽，但实际上我的设计方案是在时间紧张而又有一定硬件资源的情况下最好的选择了，现在有时间了，所以才来咨询下，确定下索引文件优化的方案。

Answer 7

也考虑过用现成的lucene，但一方面对其性能不是很了解，另一方面既然老板给钱给时间让写一个，那何乐而不为呢？即学习了知识，又能完成工作，一开始简单点，以后逐步完善，说不定什么时候能超过lucene呢？

Answer 8

是有点闭门造车，所以来寻求帮助了，以前只是看了下lucene的索引结构概述，具体的文件结构什么的都没看，这是不好的，现在我正准备下载lucene的源码研究下。

Answer 9

如果大多数文件内容都超过一个簇，其实几百万个文件也是可以的，windows目录的也是可以建立索引的，同样是类B树的实现。
如果文件内容大多比较少，不仅浪费硬盘空间，而且浪费系统缓存空间，导致命中率降低。