在安全服务提供商Solutionary公司内部，数据的规模变得越来越大。用一般数据库技术处理这些数据是很困难的，所以他们使用了基于Java 的Hadoop技术以及MapR HBase。

在项目开始时，Solutionary的软件工程主管Scott Russmann曾经发现需要更大规模的Oracle和Real Application Clusters （RAC），但是这样做会大大提高单位CPU的成本。

Russmann说：“我们审视了更高级的持久化威胁，它就像大海捞针。结果，我们的存储需求在不断地增长。随着存储和处理需求的不断增长，CPU开销也会增长。”

正如他所描述的，这家公司在客户数据中心部署了自己的ActiveGuard安全软件，然后内部安全专家将使用这些软件来收集法医记录分析数据。然后，专家会把这些记录数据和其他与环境相关的数据进行关联和比对，从中发现一些指示安全威胁的模式。

在面对他所提到的“数据可用性难题”时，Russman和他的团队开始注意新出现的Hadoop分布式数据集群框架及其相关的MapR HBase NoSQL键值存储。

Russmann对这个软件的扩展性和性能有很高的评价，其中性能是一些HBase用户最努力想要实现的。他指出，MapR的性能改进对于应用程序的Hadoop和HBase都很有好处。

他说：“MapR的Hadoop文件系统挽救了我们的存储需求。现在，我们有一个横向可扩展存储机制和一个可扩展的处理器-存储比例。”

他指出，Oracle RAC现在用于存储与环境相关的数据和元数据，而MapR HBase则用于处理与环境相关的原始记录数据。根据Russmann观点，如果需要进一步的可伸缩性，Solutionary可以走在“Oracle RAC增长曲线”之前，同时保护客户不受新安全威胁的影响。

谁在使用 MapR HBase？

Russmann发现的第一个HBase性能问题（发现相同问题的不止他一个）是一个艰巨的任务，没有任何一个数据专家可以用一个早上就解决这个问题。最难的问题就是垃圾收集。按照Russmann话说就是：“Java的大内存管理是很有问题的，它的主要原因在于垃圾收集。”

与HDFS及其他基于Java的技术类似，HBase也可能在垃圾（无用软件对象）收集上出现问题。与C++相比，Java不需要程序员管理内存堆的清除工作，所以有时候会意外出现垃圾收集问题。但是，有时候标准的Java内存回收机制是不够的，特别是在大规模分布式环境中。

和其他人一样，Russmann已经发现，随着HBase操作的数据越来越多，堆的大小也会增加。当垃圾收集时间太长时，处理过程就可能会停止。程序员可以修复这个问题。但是，修复过程可能很复杂。Russmann倾向于使用MapR的方法执行垃圾收集，它可以彻底解决这个问题。

Java去哪儿了？

作为MapR公司CMO的Jack Norris 指出，MapR HBase性能提升是MapR M7数据管理平台更新的主要内容。MapR移除了底层中用于同时处理文件和表的存储层，同时重新设计了架构，使HBase应用程序直接运行在MapR平台上，而不使用数据压缩。

而且，MapR M7平台放弃了Java。MapR用C/C++编写了M7，因此去除了两个层次：Java虚拟机（JVM）和标准Java垃圾收集器。

以前，这种做法可能会激怒Java的缔造者——Sun公司。为了支持100%兼容性，我们必须“全部使用Java”，不能混搭其他语言，这是以前程序员经常采用的方法。现在不一样了，但是在Hadoop生态系统中添加这样的修改并不是没有争议的。

Hadoop的开源基础很大程度源于它的快速升级。Apache HBase项目的贡献者一直在致力于改进HBase的垃圾收集机制，他们指出，MapR的做法可以叫做“HBase”，但是已经不是“Apache HBase”了。

Norris指出，虽然Hadoop的市场由开源技术开创，但是它可以并且在很多时候需要在开源代码中加入一些创新，才能满足客户需求。这一直属于MapR Hadoop的组成部分，现在Cloudera和HortonWorks也因为HBase策略开始出现与Hadoop不同的特点而迅速发展。对于Solutionary开发的应用程序，立竿见影地解决问题会使它赢得胜利，但是随着Hadoop 生态系统变得不断成熟，MapR的策略也会最终得到验证。