数据结构压缩
这个故事是关于我们最近在Plumbr进行的容量优化任务。 一切始于将无害的要求添加到现有组合中。
您可能知道,Plumbr监视解决方案作为连接到服务器的Java代理分发。 只需少量添加即可跟踪一段时间内所有已连接的代理,以便可以实时回答以下问题:
- 我们有多久没有收到这个特定JVM的消息了?
- 另一个JVM的最后一次已知停机时间是什么?
当每个代理每秒发送一次心跳时,我们在服务器端需要做的就是跟踪所有心跳。 由于每个心跳都附加有唯一的时间戳,因此幼稚的解决方案就像将所有心跳扔到Set或Map中一样容易。 那么-简单,完成,接下来,请?
但是,一些快速的数学运算表明,最初的想法可能行不通。 考虑到:
- 时间戳记的类型很长 ,需要8个字节才能容纳
- 一年中有365 x 24 x 60 x 60 = 31,536,000秒
我们可以快速进行数学计算,发现单个JVM仅使用一年的原始数据就需要240MB 。 仅原始数据的大小就已经足够吓人了,但是当打包到HashSet时,结构的保留大小 爆炸到大约2GB ,而所有开销的java.util.Collection API实现都隐藏在它们的腹部 。
幼稚的解决方案已经无法解决,我们需要一个替代方案。 最初我们不必走得很远,因为在同一java.util包中,一个等待被发现的惊喜叫java.util.BitSet 。 根据该类的javadoc:
BitSet类实现一个按需增长的位向量。 位集合的每个分量都有一个布尔值。 BitSet的位由非负整数索引。 可以检查,设置或清除各个索引位。
那么,如果我们将从代理获取的心跳存储为由心跳时间戳索引的布尔值,该怎么办? Java中的时间戳表示为当前时间与UTC 1970年1月1日午夜之间的毫秒差。 知道这一点后,我们可以将UTC表示为2015年9月1日12:00 UTC,即数字1441108800。那么,如果当我们看到某个Agent在时间戳1441108800处向我们发送心跳信号时,我们会将索引1441108800的位置设置为true ,否则被保留为默认false ?
解决方案的问题隐藏在一个事实中,即BitSet中的位是用整数而不是long索引的。 为了继续进行此解决方案,我们将需要一种将整数映射到long而不丢失任何信息的方法。 如果似乎不可能,那么让我们回顾一下这样一个事实,即需要一秒而不是一毫秒的精度。 知道了这一点,我们可以将索引缩小1,000倍,并以秒而不是毫秒的精度标记时间。
但是仅使用整数就可以表示多少秒? 显然,Integer.MAX_VALUE足够大,足以表示从1970年1月1日到19.01.2038的每一秒。 除了制造2038年的问题外,它还应该足够好,对吗?
不幸的是,正如我们对餐巾纸的计算所得出的那样,一年的数据仍然需要约800MB的堆空间。 这是从最初的HashSet 2GB向正确方向迈出的一小步,但对于实际使用而言仍然太高了。
为了克服该问题,可能需要重新阅读/重新考虑“足以代表1970年1月1日的每一秒”的部分。 (不幸的)先生。 直到1995年,高斯林才发明了Java虚拟机。18年后,Plumbr自己看到了曙光。 因此,我们直到1970年才需要回顾历史,并且每个整数都有一堆零。 可以从01.01.2013开始,而不是从01.01.1970开始,并使用一个索引0对应于01.01.2013 00:00(UTC)。
重做我们的餐巾纸数学,并在实践中检查结果使我们成为赢家。 现在一年的数据量只能存储在20MB中 。 与原始2GB相比,我们将所需容量减少了100倍 。 由于现有的基础架构已经可以解决这个问题,因此已经处于舒适区域,因此我们没有在优化路径上走得更远。
故事的道德启示? 当您有需求时,请找出对应用程序性能的影响。 我的意思是性能的各个方面,因为不仅有延迟和吞吐量,还应该忘记容量。 并且–了解您的域名。 没有它,您将无法做出决策,如果仅仅配备了有关数据结构的智能书籍,这些决策就显得不安全且危险。
翻译自: https://www.javacodegeeks.com/2015/09/squeezing-data-into-the-data-structure.html
数据结构压缩