海量数据搜索的思考
后续完善。
背景
假设有1亿用户（108），每个用户有1万张相片(104)。从数据量和数据大小两个方面认识下。
- 数据量：共有1012条数据，100台机子存储，每台机子1010条数据（100亿）。
- 数据大小：每个用户的数据占2MB，共2*108MB = 200TB，200台机子存储，每台机子存储1TB。
初步印象
集群需要机器数量以百衡量；从海量数据中查询想要的结果需要架构分层、数据分治；海量数据的管理有成熟的分布式文件系统（hadoop/MFS）是否可以使用。
数据特点
数据可以分类，类与类之间的联合查询没有或者很少。每个用户只能查询自己的相片，或者能查看好友的相片，但不会对两人的相片进行联合查询。
实现方案
通用方案
basic server为最小数据管理单位，basic controller汇聚多份basic server，advance controller汇聚多份basic controller获得最终展示的数据。如果advance controller汇聚的数据过多，还可以增加一层basic controller。请求过多，advance controller/basic controller/basic server可以水平扩展。数据可以进行垂直/水平的拆分。
这个架构实现复杂、技术要求高、细节繁复、工程量大，短时间、少人数复制一个不太现实。
针对该背景的方案
数据可以分类，查询往往是在一个类内部查询，类之间没有联合查询或者很少。因此我们将hash进行到底，先给出一个能接受的hash方案，再来描述架构。
Hash
总共是108个用户，每个用户104条数据。使用200台机子存储，每台机器5*105（50w）用户；单台机器上将数据分为100份，每份是一个完整的索引，维护5000用户（数据量5000*104=5kw条，数据大小5000*2MB=10G）。每次搜索最终落在对5kw条数据的查询上，能够确保响应时间可以接受。
单台机器维护100张表是否可行？假设每天UV有100w，200台机器每台接收5000UV，100张表每张表接收50UV。所以一张表一天只被查询50次，一张表10G大小，对于62G内存的机器+SSD硬盘+特殊文件索引结构，响应时间应该是能保证的。
架构
具体实现方案1：
数据的存储使用HBase，查询采用lucene。牵涉到HBase和Lucene的改造。改写lucene的IndexReader/IndexWriter/Directory，直接将TF、IDF、TermVector、倒排、正排等信息以表格形式存储在HBase表。查询和建索引的实现都有hbase节点本地实现(hbase的coprocessor或者部署单独的server存取本地的Hbase)。
具体实现方案2：
Lucene+KV DB（MongoDB/Cassandra等）。
Master和node都有各自的hash算法，每层可以考虑缓存最近查询结果或索引。
参考技术
- HBasene:HBase as the backing store for the TF-IDF representations for Lucene，最后更新是2010，已经不再更新。https://github.com/akkumar/hbasene
- Solandra:Solr + Cassandra，最后更新2012，也不再升级版本。https://github.com/tjake/Solandra
- Lily:hadoop + hbase + solar，最后更新2014。https://github.com/NGDATA/lilyproject
对这三种已有技术的认识还不彻底，本文就不列对比了。方案二可以考虑在三种技术的基础上增加hash来实现。
参考
http://blog.csdn.net/whuqin/article/details/22402773
http://blog.csdn.net/poorzerg/article/details/18796021
http://www.javabloger.com/article/lily-hbase-solr-lucene-zookeeper.html
