大致分四个阶段吧, 纯内存索引, 因存cache+硬盘, 分布式索引, 大综合体.
为什么需要特殊的索引, 而不是直接查数据库然后计算? 因为搜索过程需要很多的计算, 而这些计算再加上从数据库里面拉去raw数据, 性能会很差, 所以一般会在服务宿主机器上构造索引, 以提高性能.
首先, 如果内存允许, 那么直接放在内存里面是最优的, 比如Lucene的RamDirectory, 就是直接把索引数据构造的内存里面.
而当数据量达到一定量级, 纯内存方式会暴露缺陷, 主要几点: 1,内存大小受限, 2, 服务重启需要重新全量构造索引, 3, gc问题会变得严峻.
所以, 当数据量在服务器内存(比如10G)可以cover的情况下,
如果内存不够用了, 那么就需要退而求其次使用硬盘. 这也是lucene的典型应用场景. 但是, 硬盘的io性能要差很多, 最好还是要有热数据在内存中进行cache, 二这就是Lucene的FsDirectory所做的事.
这样下来几十G的数据应该没问题. 当然如果仅仅谈存储的话, redis也可以是一个选择. lucene 使用硬盘和redis其实都是个外存的概念.
使用外存还有个额外的利好, 就是不需要总是重新全量构建索引.
如果外存也不够用, 比如淘宝网的所有商品的综合检索, 那么就需要做分布式设计了.
但是分布式架构是有比较重的运维成本, 所以除非必要不建议进入这一阶段.
关于分片, 可以业务分, 比如根据品类做不同的子搜索系统, 然后由一个综合搜索的前端来完成合并. 或者类似ElasticSearch, 直接将索引文件分片, 分发到不同的服务器节点上.
终极形式, 就是谷歌百度的搜索架构. 比如百度的搜索条的query会分发到 大搜索, 竞价系统, 知识图谱检索提供等子系统中, 而这几个子系统同样又是很复杂的分布式系统.
以上, 仅讨论了抽象一点的索引存储问题, 忽略了一些切实的性能, 可行性等问题, 但应该不会违背目前的搜索架构的事实.
