为什么网站百度搜不到,wordpress下载站用什么模板,加新tag wordpress,网站链接交易HyperLogLog
引言
在开始之前#xff0c;先思考一个常见的业务问题#xff1a;如果负责开发维护一个大型的网站#xff0c;有一天老板找产品经理要网站每个网页每天的UV数据#xff0c;然后来开发这个统计模块#xff0c;需要如何实现#xff1f;
如果统计PV非常好办先思考一个常见的业务问题如果负责开发维护一个大型的网站有一天老板找产品经理要网站每个网页每天的UV数据然后来开发这个统计模块需要如何实现
如果统计PV非常好办给每个网页一个独立的Redis计数器即可这个计数器的key后缀加上当天的日期。这样每次一个请求incrby一次最终就可以统计出所有的PV数据。
但是UV不一样他要去重同一个用户一天之内的多次访问请求只能计数一次这就要求每一个网页请求都需要带上用户ID。无论是登录用户还是未登录用户都需要一个唯一ID来标识。也许你已经想到了一个简单的方案那就是为每一个页面设置一个独立的set集合来存储所有当天访问过此页面的用户ID当一个请求过来时使用sadd将用户ID塞进去即可通过scard可以取出这个集合的大小这个数字就是这个页面的UV数据。
但是如果页面的访问量非常大比如一个爆款页面几千万的UV此时就需要一个很大的set集合来统计这非常浪费空间。如果这样的页面很多那么所需要的存储空间是惊人的。为了这样一个去重功能耗费如此多的存储空间其结果必然是不值得。其实老板需要的数据不需要太精确105w和106w这两个数字对于老板们来说并没有多大区别因此需要探讨一种更好的解决方案。
因此本文主要讨论Redis提供的HyperLogLog来解决这个问题。HyperLogLog提供不精确的去重计数方案其标准误差是0.81%这样的精确度足够满足很多UV需求。
使用方法
HyperLogLog提供了两个指令pfadd和pfcount一个是增加计数一个是获取计数。pfadd用法和set集合的sadd一样来一个用ID就将用户ID塞进去即可。pfcount和scard用法一样直接获取计数值。
127.0.0.1:6379 pfadd codehole user1
(integer) 1
127.0.0.1:6379 pfcount codehole
(integer) 1
127.0.0.1:6379 pfadd codehole user2
(integer) 1
127.0.0.1:6379 pfcount codehole
(integer) 2
127.0.0.1:6379 pfadd codehole user3 user4 user5 user6
(integer) 6简单试了一下发现还蛮精确的一个没多一个也没少接下来使用脚本灌入更多的数据看看是否还可以继续精确下去如果不能精确差距有多大。
public class PfTest {public static void main(String[] args) {Jedis jedis new Jedis();for (int i 0; i 100000; i) {jedis.pfadd(codehole, user i);long total jedis.pfcount(codehole);if (total ! i 1) {System.out.printf(%d %d\n, total, i 1);break;}}jedis.close();}
}当加入10w数据的时候输出结果为99723差了277按照百分比是0.277%。当再次运行这个脚本的时候输出结果仍然是99723redis运行过一次已经存在数据的情况下说明他确实具备去重功能。 pfmerge
HyperLogLog除了上面的pfadd和pfcount之外还提供了第三个指令pfmerge,用于将多个pf计数值累加在一起形成一个新的pf值。比如在网站中我们有两个内容差不多的页面需要将这两个页面的数据进行合并其中页面的UV访问量也需要合并那么这个时候pfmerge就可以派上用场。
布隆过滤器
引言
上文讲述了使用HyperLogLog数据结构来进行估数可以解决很多精确度不高的统计需求。但是如果我们想知道某一个值是不是已经在HyperLogLog结构里面了他就无能为力他只提供pfadd和pfcount方法没有提供pfcontains方法。
举个使用场景我们在使用新闻客户端看新闻时他会给我们不停的推荐新的内容他每次推荐时要去重去掉那些已经看过的内容。新闻客户端的推荐系统如何实现推送去重
很容易想到服务器记录了用户看过的所有历史记录当推荐系统推荐新闻时会从每个用户的历史记录里进行筛选过滤掉那些已经存在的记录。问题是当用户量很大每个用户看过的新闻又很多的情况下这种方式推荐系统的去重工作在性能上跟得上吗 实际上如果历史记录存储在关系数据库里去重就需要频繁的对数据库进行exists查询当系统并发量很高时数据库是很难扛住压力的。
如果将如此多的历史记录全部缓存起来那得浪费多大存储空间。而且这个存储空间是随着时间线性增长很难长时间撑的住。但是不缓存的话性能又跟不上此时该如何解决。
这时布隆过滤器Bloom Filter闪亮登场他就是专门用来解决去重问题的。他在起到去重的同时在空间上还能节省90%以上只是稍微有点不精确也就是有一定的误判概率。
布隆过滤器是什么
布隆过滤器可以理解为一个不怎么精确的set结构当使用它的contains方法判断某个对象是否存在时他可能会误判。但是布隆过滤器也不是特别不精确只要参数设置的合适他的精确度可以控制的相对足够精确只会有小小的误判概率。
当布隆过滤器说某个值存在时这个值可能不存在当他说不存在时那就肯定不存在。套在上面的使用场景中布隆过滤器能准确过滤掉那些已经看过的内容那些没有看过的新内容他也会过滤掉极小一部分但是绝大多数心能容他都能准确识别。这样就可以完全保证推荐给用户的内容都是无重复的。
Redis中的布隆过滤器
Redis官方提供的布隆过滤器到了Redis4.0提供了插件功能之后才正式登场。布隆过滤器作为一个插件加载到Redis Server中给Redis提供了强大的布隆去重功能。
布隆过滤器基本使用
布隆过滤器有三个基本指令bf.add添加元素bf.exists查询元素是否存在他的用法和set集合的sadd和sismember差不多。bf.add一次只能添加一个元素如果想要一次添加多个就需要用到bf.madd指令。同样如果需要一次查询多个元素是否存在就需要使用bf.mexists指令。
127.0.0.1:6379 bf.add codehole user1
(integer) 1
127.0.0.1:6379 bf.add codehole user2
(integer) 1
127.0.0.1:6379 bf.add codehole user3
(integer) 1
127.0.0.1:6379 bf.exists codehole user1
(integer) 1
127.0.0.1:6379 bf.exists codehole user2
(integer) 1
127.0.0.1:6379 bf.exists codehole user4
(integer) 0代码测试
public class BloomTest {public static void main(String[] args) {Client client new Client();client.delete(codehole);for (int i 0; i 100000; i) {client.add(codehole, user i);boolean ret client.exists(codehole, user (i 1));if (ret) {System.out.println(i);break;}}client.close();}
}运行后可以看到输出214即到第214的时候就出现了误判。那么如何测量误判率呢我们先随机出一堆字符串然后切分为2组将其中一组塞入布隆过滤器然后判断另外一组的字符串存在与否取误判的个数和字符串总量一半的百分比作为误判率。
代码如下 pom中添加依赖 dependencygroupIdredis.clients/groupIdartifactIdjedis/artifactIdversion3.9.0/version/dependencydependencygroupIdcom.redislabs/groupIdartifactIdjrebloom/artifactIdversion2.2.2/version/dependencypackage example;
import io.rebloom.client.Client;
import redis.clients.jedis.Jedis;class BloomRedis {private Client client;private Jedis jedis;private int capacity 20000;// 容错率,只能设置0 error rate range 1 不然直接会异常private double errorRate 0.01;public BloomRedis() {jedis new Jedis(127.0.0.1, 6379);client new Client(jedis);}public void count(String key) {if (!jedis.exists(key)) {client.createFilter(key, capacity, errorRate);}int realCapacity 20000;for (int i 0; i realCapacity; i) {client.bfInsert(key, String.valueOf(i));}System.out.println(存入元素为{ realCapacity });// 统计误判次数int count 0;// 我在数据范围之外的数据测试相同量的数据判断错误率是不是符合我们当时设定的错误率for (int i capacity; i realCapacity * 2; i) {if (client.exists(key, String.valueOf(i))) {count;}}System.out.println(误判元素为{ count });// 删除过滤器client.delete(key);}
}
class ExampleTest {public static void main(String[] args) {BloomRedis bloomRedis new BloomRedis();bloomRedis.count(codehole);}
}输出结果
存入元素为{20000}
误判元素为{174}设置处理容量为20000容错率为0.01的情况下输出结果最终错误率为0.0087。
一组其他测试数据
//当realCapacity为5000,capacity 20000错误率为0
//当realCapacity为10000,capacity 20000错误率为0
//当realCapacity为20000,capacity 20000错误率为0.08
//当realCapacity为40000,capacity 20000错误率为0.5
//当realCapacity为40000,capacity 80000错误率为0注意事项
布隆过滤器的initial_size估计的越大会浪费存储空间估计的过小就会影响准确率用户在使用之前一定要尽可能的精确估计好元素数量还需要加上一定的冗余空间以避免实际元素可能会高出估计值很多。 布隆过滤器的error_rate越小需要的存储空间越大对于不需要过于精确的场合error_rate设置稍大一点也无伤大雅。比如在新闻去重上而言误判率高一点只会让小部分文章不能让合适的人看到。文章的整体阅读量不会因为这点误判率就带来巨大的改变。
布隆过滤器原理 每个布隆过滤器对应到Redis的数据结构里面就是一个大型的位数组和几个不一样的无偏hash函数。所谓无偏就是能够把元素的hash值算的比较均匀。
向布隆过滤器中添加key时会使用多个hash函数对key进行hash算的一个整数索引值然后对位数组长度进行取模运算得到一个位置。每个hash函数都会算得一个不同的位置再把位数组的这几个位置都置为1就完成了add操作。
向布隆过滤器询问key是否存在时跟add一样也会把hash的几个位置对一个值进行多次hash每次hash计算得出在位数组中的一个索引多个hash得到多个索引每个索引位置在位数组中都是1那这个值就是存在都算出来看看位数组中这几个位置是否都为1.只要有一个为0那么说明布隆过滤器这个key不存在。如果都是1这不能说明这个key一定存在只是极有可能存在因为这些位置为1可能是因为其他的key存在所致。
使用时不要让实际元素大于初始化大小当实际元素开始超出初始化大小时应该对布隆过滤器进行重建重新分配一个size更大的过滤器。再将所有的历史元素批量add进去这就要求我们在其他的存储器中记录所有的历史数据。因为error_rate不会因为数量超出就急剧增加这就给我们重建过滤器提供了较为宽松的时间。
空间占用估计
布隆过滤器有两个参数第一个是预计元素的数量n第二个是错误率f。公示根据这两个输入得到两个输出第一个输出是位数组的长度1也就是需要的存储空间大小bit第二个输出是hash函数的最佳数量k。hash函数的数量也会直接影响到错误率最佳的数量会有最低的错误率。 k 0.7 * (1/n) f 0.6185 ^ (1/n) 从公式中可以看出 位数组相对越长1/n,错误率 f 越低这个和直观上理解一致。位数组相对越长1/n,hash函数需要的最佳数量也越多影响计算效率。当一个元素平均需要1个字节8bit的指纹空间时1/n 8错误率大约为0.02.错误率为10%一个元素需要的平均指纹空间为4.792个bit大约为5 bit.错误率为1%一个元素需要的平均指纹空间为9.585个bit大约为10 bit。错误率为 0.1%一个元素需要的平均指纹空间为 14.377 个 bit大约为 15 bit。 此时也许会想如果一个元素需要占据15个bit那相对set集合的空间优势是不是就没有那么明显了这里需要明确的是set会存储每个元素的内容而布隆过滤器仅仅存储元素的指纹。元素的内容大小就是字符串的长度他一般会有多个字节甚至是几十个字节每个元素还需要一个指针被set集合来引用这个指针又会占去4个字节或者8个字节取决于系统是32bit还是64bit。而指纹空间只有接近2个字节所以布隆过滤器的优势还是非常明显的。
推荐使用布隆过滤器计算需要提供的存储空间。
实际元素超出时误判率会怎样变化
当实际元素超出预计元素时误判率变化需要引用下述计算公式。引入参数 t 表示实际元素和预计元素的倍数 t。
f (1-0.5^t )^k. #极限近似k是hash函数的最佳数量
当t增大时错误率 f 也会跟着增大分别选择错误率为 10%1%0.1%的k值观察他的曲线 从这个图中可以看出曲线还是比较陡峭的 错误率为10%时倍数比为2时错误率就会升至40%这就比较危险了 错误率为1%时倍数比为2时错误率升至15%。 错误率为0.1%倍数比为2时错误率升至5%。 布隆过滤器的其他应用
在爬虫系统中我们需要对URL进行驱虫已经爬过的网页就可以不用爬了但是URL太多了几千万几个亿。如果用一个集合装下这些URL地址那是非常浪费空间的这时候就可以考虑使用布隆过滤器他可以大幅降低去重存储消耗只不过也会使得爬虫系统错误少量的页面。
布隆过滤器在NoSql数据库领域使用非常广泛我们平时用到的Hbase、Cassandra还有LevelDB、RocksDB内部都有布隆过滤器结构布隆过滤器可以显著降低数据库IO请求数量当用户来查询某个row时可以先通过内存中的布隆过滤器过滤掉大量不存在的row请求然后再去磁盘进行查询。
邮箱系统的垃圾邮件过滤功能也普遍用到了布隆过滤器因为用了这个过滤器所以平时也会遇到某些正常的邮件被放进了垃圾邮箱目录中这个就是误判所致概率很低。
