【译】mahout in action 3.2 加速聚集

非常高兴的是，Mahout已经重新创造了“java数组对象”。这只是万里长征的第一步。我们提及到规模是重要的吗？可能，你已经被说服，我们将会面对处理巨大数量的数据，和不寻常响应。

这个reduced的内存需求，由PreferenceArray和它的实现，带来的复杂性是值得的。削减内存需求的百分之七十五不只是节约一对M字节。在一个合理的规模上，它节约了10分之一G内存。这可能是在你现存的硬盘上是否装配之间的不同。这是是否必须投资大量的RAM和可能的一个新的64-bit系统之间的不同。那是一个小的，但真正节能的技术，非常重要。

3.2.1 FastByIDMap 和 FastIDSet
当你听到Mahout recommenders大量的使用如map和set的典型的数据结构时将不会感到奇怪，但是不要使用如TreeSet和HashMap的普通的Java实现。相反，遍历这个实现和API你将会找到FastByIDMap和FastIDSet。它们是像Map和set一样的程序，但是是被明确的详细说明，并只提供Mahout recommenders需要的程序。它们减少内存占用而不是在性能上显著的增加。

这里没有一个像java中的Collections。但是，它们在一个大范围的环境内，为有效的目的而精心设计。它们不能对未来的使用做出更多的假设。Mahout的需要对可得到的用法有更加特殊，更强的假设。主要不同是：

。如同HashMap，FastByIDMap 是 hash-based。它使用线性探索而不是分离链接来处理hash collisions。这避免了一个额外的Map.Entry对象的每个入口的需要；如我们所讨论的，Objects占用了令人惊奇的内存数量。

。Keys和members在Mahout recommenders中总是长的基元，而在objects中则不是。使用长的keys节约内存并提高性能。

。Set的实现不是使用下面的一个Map来实现的。

。FastByIDMap可以像一个cache一样起作用，因为它有一个“maximum size”的概念；超过这个尺寸，当增加了新的entries时，infrequently-used entries将会被删除。

存储的不同是有意义的：与HashSet 的84个字节相比，FastIDSet平均每个member需要大约14个字节。与HashMap 的每个入口的84个字节再次比较，FastByIDMap每个入口占用28个字节。这显示当一个人对用法做了更强的假设时，有意义的改善是可能的：主要在内存需求上。考虑到为recommender系统提供的讨论中的数据量，这些习惯的实现不仅仅证明了它自己。所以，这些类用在哪里？