如果老板让你统计一个实时的数据流中元素出现的频率，并且准备随时回答某个元素出现的频率，不需要的精确的计数，那该怎么办？
直觉告诉我们可能需要一个巨大的 HashMap 来统计各个元素的出现频率，但由于不同的元素的个数可能非常大，以至于是个天文数字，要求的内存可能会非常大，从而不切实际。同时，又要求我们实时计算，实时回答，当HashMap的冲突很高时，最坏的情况的时间复杂度可能无法满足实时的要求。
加上前面要求不需要精确的计数，这么说来，必须寻找新的算法。
那么，Count-Min Sketch 就是用来解决此类问题的算法。
这个算法的技巧是：
不存储所有的不同的元素，只存储它们Sketch的计数。
基本的思路是这样的：
创建一个长度为 x 的数组，用来计数，初始化每个元素的计数值为 0；
对于一个新来的元素，哈希到 0 到 x 之间的一个数，比如哈希值为 i，作为数组的位置索引；
这是，数组对应的位置索引 i 的计数值加 1；
那么，这时要查询某个元素出现的频率，只要简单的返回这个元素哈希望后对应的数组的位置索引的计数值即可。
考虑到使用哈希，会有冲突，即不同的元素哈希到同一个数组的位置索引，这样，频率的统计都会偏大。
如何优化？
使用多个数组，和多个哈希函数，来计算一个元素对应的数组的位置索引；
那么，要查询某个元素的频率时，返回这个元素在不同数组中的计数值中的最小值即可。
是不是很美妙？显然，这个改进的算法比原始的算法精确多了，但还是会有冲突，但是冲突少多了。
这个算法的特点是：
只会估算偏大，永远不会偏小；
只需要固定大小的内存和计算时间，和需要统计的元素多少无关；
对于低频的元素，估算值相对的错误可能会很大。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
