海量数据搜索的思考

后续完善。

背景

假设有1亿用户（10⁸），每个用户有1万张相片(10⁴)。从数据量和数据大小两个方面认识下。

• 数据量：共有10¹²条数据，100台机子存储，每台机子10¹⁰条数据（100亿）。
• 数据大小：每个用户的数据占2MB，共2*10⁸MB = 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

总共是10⁸个用户，每个用户10⁴条数据。使用200台机子存储，每台机器5*10⁵（50w）用户；单台机器上将数据分为100份，每份是一个完整的索引，维护5000用户（数据量5000*10⁴=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