海量数据统计的方法？

仅就此例，可以在author表里面放一个文章数量的字段作为冗余，发文章的时候+1，这样就不需要统计了。。。

HashMap对500W的数据量是没法操作！本人已经测试过！最合理的方法通过SQL的统计操作方法！

以空间换时间。

感觉楼主提问的方法不够专业,应用的场景描述得不够详细.整个应用应该不光只是在算法上,也许数据库优化一下,硬件提升一下,最后算法再做一下文章就可以解决问题.感觉楼主是不是专了牛角尖.而且大家提供了这么多方法也没有个测试结果的反馈!!!!

我提一个想法,可不可以300w数据分块多线程处理再合并结果,好想上面也有人提过的.

谢谢各位的回复，可能我没有说清楚。
现在我能很快（大概0.1s）的取到符合条件的结果集，以及结果集中需要统计的字段的值（比如“作者”字段），问题是统计这些作者各自出现了多少次存在效率问题，所以需要一种结构在遍历所有取到的“作者”时能快速的存储以及统计，当然，还有这种结构最好能快速的合并（多个节点数据的汇总）。应用和数据库没有关系，那只是个例子。

恕我冒昧，要在搜索结果集里用遍历的方式来统计，是走不通的，算法都错了，数据结构再好都解决不了根本问题。你没发现每次做的事情都是在结果集里统计某某文章的作者是谁吗，然后一遍又一遍地统计？

兄弟，你的词语有多少个？ 据我所知， 用Trie树应当是最快的方法。

可以使用google的MapReduce.

看了lz的这段话，感觉搂住的问题应该是这样的吧？如果有什么不对的，还请指出。
1) 先找出含有某个关键词的所有文章。比方说找出了1000篇。
2) 然后找出这1k篇文章的作者的其它信息，比方说：在整个数据中，每个作者共有多少篇文章。

------------------------------
如果我说错了，下面的就不用看了。
其实这种东西说白了，就是倒排，只是说可能需要自己的倒排机制。而不能用lucene等。因为，lucene是一种通用的机制，而不是针对某种特殊情况而来的。

第1)，通过关键词找文章，这步是少不了的。
第2),这步也是少不了的。唯一能优化的是。

建立一套自己的索引机制，比方说：在1步的同时，就把第2步的信息都反映出来。

可能还有点不好理解。举个例子。如果说用hashMap做。
Map<String, Document>，这是通过关键词找到document的方式。
那么，我们直接把user的信息放到document中。

class Document {
    UserInfo userinfo;    

}

UserInfo {
    int writeDocNum;
    ...
}

这样的话，就可以满足需求了。
但是如果是这样的话，前期的计算过程是很复杂的。相当于是把检索的一部分业务放到了加载里面去。

作者的系统架构可能有点问题，不要指望一次运算解决所有问题。