Jackiesteed

www.github.com/jackiesteed

  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

大致分四个阶段吧, 纯内存索引, 因存cache+硬盘, 分布式索引, 大综合体.

 

为什么需要特殊的索引, 而不是直接查数据库然后计算? 因为搜索过程需要很多的计算, 而这些计算再加上从数据库里面拉去raw数据, 性能会很差, 所以一般会在服务宿主机器上构造索引, 以提高性能.

 

首先, 如果内存允许, 那么直接放在内存里面是最优的, 比如Lucene的RamDirectory, 就是直接把索引数据构造的内存里面.

而当数据量达到一定量级, 纯内存方式会暴露缺陷, 主要几点: 1,内存大小受限, 2, 服务重启需要重新全量构造索引, 3, gc问题会变得严峻.

所以, 当数据量在服务器内存(比如10G)可以cover的情况下,

 

如果内存不够用了, 那么就需要退而求其次使用硬盘. 这也是lucene的典型应用场景. 但是, 硬盘的io性能要差很多, 最好还是要有热数据在内存中进行cache, 二这就是Lucene的FsDirectory所做的事.

这样下来几十G的数据应该没问题. 当然如果仅仅谈存储的话, redis也可以是一个选择. lucene 使用硬盘和redis其实都是个外存的概念.

使用外存还有个额外的利好, 就是不需要总是重新全量构建索引.

 

如果外存也不够用, 比如淘宝网的所有商品的综合检索, 那么就需要做分布式设计了.

但是分布式架构是有比较重的运维成本, 所以除非必要不建议进入这一阶段.

关于分片, 可以业务分, 比如根据品类做不同的子搜索系统, 然后由一个综合搜索的前端来完成合并. 或者类似ElasticSearch, 直接将索引文件分片, 分发到不同的服务器节点上.

 

终极形式, 就是谷歌百度的搜索架构. 比如百度的搜索条的query会分发到 大搜索, 竞价系统, 知识图谱检索提供等子系统中, 而这几个子系统同样又是很复杂的分布式系统.

 

以上, 仅讨论了抽象一点的索引存储问题, 忽略了一些切实的性能, 可行性等问题, 但应该不会违背目前的搜索架构的事实.

posted on 2015-06-06 22:06  Jackiesteed  阅读(758)  评论(0编辑  收藏  举报