49彩票集团首页-49彩票集团官网|官网首页

49彩票集团让大家拥有最好的账号使用功能,49彩票集团是为大家带来更加方便的使用途径,是因为在49彩票集团娱乐的玩家们越来越多,发展成为最受欢迎的网上体育娱乐公司。

你也许收集了一些用户的数据,看看当数据库被

2020-04-03 作者:计算机网络   |   浏览(63)

文章整理自周正中在 GOPS2017 · 深圳站的演讲。高效运维社区致力于陪伴您的职业生涯,与您一起愉快的成长。作者简介

阅读原文请点击:
摘要: 标签 PostgreSQL , 数组 , GIN索引 , 任意字段组合查询 , 圈人 , ToB分析型业务 , 建模 背景 你也许在一家ToB的数据分析公司,你可能设计了一张表(包括用户标识,及若干已经统计好的的属性值),你也许收集了一些用户的数据,你也许要为客户提供报表,你也许需要为客户提供任意属性值的组合查询,并快速的返回结果给用户。

本文根据digoal(德哥)在〖2017 Gdevops全球敏捷运维峰会成都站〗现场演讲内容整理而成。

周正中(digoal)PostgreSQL中国社区发起人之一、杭州分会会长,PostgreSQL中国社区大学发起人之一,10余项数据库相关专利。就职于阿里云,ApsaraDB内核组。

标签

讲师介绍

前言

PostgreSQL , 数组 , GIN索引 , 任意字段组合查询 , 圈人 , ToB分析型业务 , 建模

digoal(德哥),现任职于阿里云数据库内核技术架构组。PostgreSQL中国社区发起人之一、常委、兼任社区大学校长,PostgreSQL中国社区杭州分会会长,PostgreSQL中国社区大学发起人之一。14项已授权专利。乐于分享,撰写技术类文章几千余篇,狂热技术分子,致力于PostgreSQL数据库在中国的技术推广与人才教育。

ostgreSQL这几年的发展非常迅猛,在国内掀起了一波PostgreSQL的热潮,但运维人才还是比较紧缺,所以在一些公司没有大面积铺开,不过不用担心,很多云厂商都提供了PostgreSQL的数据库服务。

背景

“超体”这个例子来源于一部电影,电影中探讨当人的脑细胞被开发到100%的时候会达到一个什么样的现象。同样的,今天我们以PostgreSQL为例,看看当数据库被开发至100%会产生什么,是不是可以解放程序猿的双手,节约50%的开发时间去撩妹?(¬∀¬)σ

阿里云的RDSPostgreSQL除了提供公有云服务,同时也对阿里巴巴集团提供内部的服务。接下来我会分享几个在阿里巴巴内部使用PostgreSQL的一些场景。大家可以想想思考一下,如果用其他数据库和技术手段怎么解决这些问题。

你也许在一家ToB的数据分析公司,你可能设计了一张表(包括用户标识,及若干已经统计好的的属性值),你也许收集了一些用户的数据,你也许要为客户提供报表,你也许需要为客户提供任意属性值的组合查询,并快速的返回结果给用户。

20%1、物联网、金融、日志、运营商网管、行为轨迹类数据

海量导购文实时去重精准广告投放TOB 实时画像任意字段组合任意字段模糊匹配1. 海量导购文实时去重1.1 导购业务介绍

这些需求应该是非常常见的ToB的数据平台公司的形态,头痛的问题无法建模,因为B端的需求无法捉摸,任意组合查询、要求实时响应。

20%的时候会是什么样子的?先来看一个场景,现在非常流行物联网的场景,包括金融、运营商网关,还有电商,然后很多的一些O2O的平台采集用户的信息。因为每一次手机上的操作,点击都会记录下来,以便后面做一些用户行为挖掘的动作。那么这些数据有什么样的特征?

首先是海量导购文实时去重。在日常生活中特别是妹子很喜欢看导购的推送消息(比如每日白菜价);特别是家庭主妇,在家里没事就浏览白菜价,如果家里有小孩的,小孩才一两个月,已经买到十几岁的衣服了,这和导购推送有密切关系。

你的客户数据也许有几十亿上百亿,客户数据也许有几百个属性,用户可能需要的是任意属性组合的结果。

行为数据的特征包括追加写,不停地写入,同时在时间和维度上跟你的堆存储存在一定的线性关系。行为数据的数据量是很大的,一个业务的日记录数以亿到百亿记。

这么多的导购文章,每一篇文章都会推很多的商品,如果你是一个用户每天翻看这些文章都是一样的商品,是很令人讨厌的。

如果要快速响应,你的第一反应是不是对查询条件建立索引呢?

查询需求方面,需求方可能需要查一个群体性数据在某一个时间点发生的行为,这是时间区间查询的需求。第二个查询需求可能是分析需求,比如群体性的特征分析,这么大一个数据量的情况下,会要求插入快,因为插入慢的话就有丢数据的风险。

所以在导购平台就有一个很重要的工作,得过滤这些别人已经推荐过的商品,别人推荐过的商品你就不要再推荐了。

比如

存储的要求,要支持压缩,比如说我插的数据这么大的量不能压缩,在成本上可能是扛不住的,业务方想保留一年的数据,压缩与不压缩成本可能相差好几倍。

比如说每日白菜精选的文章里可能会涉及到几十个商品,整个导购平台可能会沉积上亿的文章,如果平均五十个商品的话,就会有五十亿个商品。当然里面有重叠,一篇文章里跟另外一篇文章可能有一两个重叠,这是没有关系的,但是你不能80%以上都重叠,这个重叠比例是需要可以设定的。

where col1=? and col2=? and col3<>? or col4=?; 
这样的SQL,你准备怎么做到实时响应呢?(col1,col2)建立索引,col4建立索引,这样是吗?

数据种类的需求。随着物联网的发展,终端采集的数据越来越多样化,传统的数字、字符串、时间是比较常见的,现在可能还会加入更多的类型,比如定位的信息,而且事件的发生有时间和空间的维度在里面,越来越多的用户需要支持更多的数据类型。

1.2 导购文审核发展历程

但是用户下次的请求肯又换条件了

2、PostgreSQL块级别索引– BRIN

因为店家会去做推广,就会有佣金,网络写手会为了佣金去写导购文章。但是为了防止出现盗文现象,就需要审核导购文章,最原始的做法是什么样的?比如我刚新建了这样一个导购平台,用户数也不是特别多,这时候请一些较为廉价的劳动力来帮你解决审核的问题,最早期的为劳动力密集型。

where col3=1 or col100=? 
是不是又要建col3, col100的索引呢?

我们看一下检索,假设一天产生几十个G的数据,用户想找到12点前后五分钟的数据在哪里,但想一想一天几百个GB的数据,索引有多大呢,那么什么方法可以减少索引的大小?

发展到第二代,用计算机帮你做这个事情,新提交一个文章的时候,要在上亿的文章里去辨别跟我刚刚提交的商品的重复率是什么样的,涉及的运算量非常大,因此并不能做到实时的审核,通常是隔天的。

你会发现根本没有办法优化,因为对应查询的索引组合可能是成千上万的。

在这里可以使用块级存储,比如一个数据块是一兆,这一兆的数据里面覆盖了某个字段从几点到几点的信息,块级索引只需要存储边界值、COUNT、SUM等信息,所以块级索引会变得很小很小。使用了块级别索引后你耗费的空间相比原来下降几百倍,如果一个数据块可以存两百条记录的话,你的索引会变成是原来两百分之一那么小,而检索的速度是没有受到影响的。

对于导购文章的编辑来说,这个效率是低下的,网络写手提交文章后,第二天才能告知有没有通过,才能发到网站上面,这样可能就错过了商家的营销时机。

PostgreSQL 对付任意字段检索的黑科技

从图上看单步插入的速度,比原来使用快了很多。

1.2.1 数据结构问题

我在之前写过一些关于任意字段查询的实践文章,广泛应用于广告营销平台的圈人,ToB的圈人,前端页面的任意组合筛选等场景。

接下来我们看一下看压缩的需求。压缩这一块,其实有很多的算法,有有损压缩和无损压缩。比如说旋转门的压缩,这个是来自于一个做电力的监控系统:

回到原始的数据去看,每一篇导购文章里面涉及到50个商品,按平均数来,商品使用一个数组来存储,这里面的每个数值对应的都是商品的 ID,每个记录会涉及到大概 50 个这样的值。

方法1,GIN复合索引

一个发电厂有很多的传感器,这些传感器每十毫秒就上传一个数据,数据量是非常庞大的。这里有一个旋转门压缩转盘,在这个数据库里面可以写一个UDF实现一个同样的功能。刚刚讲的这个功能,有一个非常典型的应用就是在阿里的菜鸟中有一个跟踪系统有用到这个产品里面的特性。

当用户提交一个新的导购文章来的时候,我们看到又有一堆的值进来,怎么做呢?

对需要参与查询的字段,建立GIN的复合索引。

第二个场景为搜索类、多维度交互类的场景。比如说淘宝前端的页面,我们在做一些搜索的时候,我要找销量大于多少的,还是按照店铺名称找,还是按照商品名找,或者是按照商品的地区搜索等等。我们在搜索时有很多选择,但表设计好之后有几十个字段,每个字段都有可能是客户选择的选项,如果是针对每一个字段建索引的话,虽然你满足了用户的需求,但是会带来很大性能的插入和更新性能的损耗。同时用户可能是按照某一个字段做模糊的搜索。

我们需要去比对库里的每一条记录,看他们重叠的元素有多少个,比如说新上的文章推荐了十个商品,与历史导购文章中某记录重叠的有八个商品 ID,意味着你新上传的文章有 80% 跟其中的某一篇文章的商品是重叠的,审核结果是拒绝。

pic

在PostgreSQL数据库里面可以帮你做这件事情,它的原理非常简单,就是通过这种倒排的方法做索引,还有其它的方法比如通过空间索引(GiST),通过这种方法可以实现任意字段的检索。

1.2.2 PostgreSQL GIN索引应用

CASE如下:

现在许多开发者会使用JSON存取数据,当设计之初,也许无法固定结构设计,那么可以用到PostgreSQL的JSON的数据类型,JSON内容的检索与普通字段的检索方法一样,同样支持模糊查询。

在 PostgreSQL 里面有一个什么技术能够帮你高效实现应用场景呢?我们用了 GIN 索引,它就是一个倒排索引,在你的一条记录里,可以对数组去建索引,一个数组有50个商品,第一列是一个行号,解开之后一个行号对应这么多值,倒转一下会变成这个值对应的行号是什么,就是帮你做了翻转。

《任意组合字段等效查询, 探探PostgreSQL多列展开式B树 (GIN)》

典型的用户:在阿里里面一个是淘系用户,这个任意字段检索的特性用得比较多。还有万网和阿里云的官网。最后一个是相似的搜索,比如说一篇文章里面涉及到一百个商品,别人写的文章里面涉及50多个商品,你跟他有40个是重叠的,怎么搜出来?这个是通过相似索引搜出来的,它达到的效果也是很高的,可以在几个毫秒之内就在上亿的数据里面帮你搜索出与你提供的数据相似的数据。

有什么用呢?做完了翻转,用户上传了一篇新的导购文章,里面涉及到假设商品的 ID,我们看最左边的一列,1,3,101,198,上传这些商品 ID 上来,在索引上怎么搜索,比如说对1这个 ID,因为它有行号,里面对应的是数据块的 ID 加上这条记录在数据块的偏移,对应的号拿出来之后,在第一个数据块出现过,通过索引搜索出来,在第101个数据块里也出现过,数据库会帮你把每个数据块里的命中商品总数给记录下来,就变成了最下面的一行记录,213 422,什么意思呢?代表是在101这个数据块里有命中四个商品ID。

这个场景针对任意字段匹配的场景,PostgreSQL对于多个查询条件,内部会使用索引+bitmapAnd或bitmapOr来筛选BLOCK,得到中间结果。

3、高效率范围查询

1.2.3 多重过滤提高检索效率

+---------------------------------------------+   
|100000000001000000010000000000000111100000000| bitmap 1   
|000001000001000100010000000001000010000000010| bitmap 2   
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&   
|000000000001000000010000000000000010000000000| Combined bitmap   
+-----------+-------+--------------+----------+   
            |       |              |   
            v       v              v   
Used to scan the heap only for matching pages:   
+---------------------------------------------+   
|___________X_______X______________X__________|   
+---------------------------------------------+   
这种方法为什么快呢?

再看看第三个场景——范围数据。范围数据出现最多的地方是物联网。在物联网里面它的传感器要不停上报数据,但是比如说一些温度传感器,或者是湿度等等指标的传感器,它的范围波动是很小的。像电压的波动,可能一直就在220左右波动的,假如一个小时上来的数据全部在这个范围内波动,实际上在后台根本没必要每一个值都存下来,我可以直接存一个范围,假设你的偏差精确到99.9%在业务上是可以容忍的,这时候我完全不需要把每一个精确的值存下来。

比如设置了重复数4,通过索引可以直接拒绝发布。如果设置为=3那么只要提取出第49号数据块和第101的数据块的数据。进入第二道工序。

原因是GIN索引实现了内部bitmapAnd or bitmapOr,实际上等效于对每个字段建立单独的B-Tree索引(PostgreSQL对多个B-Tree索引也支持bitmapAnd, bitmapOr的合并)。

存取范围,涉及到范围类型,也是一个比较有趣的特性,比如说1到2,这种数值经常做什么样的检索呢?今天所有的传感器上报的数据里面,哪些是100-200之间的数据,按照原来的设计两个字段索引做搜索,是可以实现的,但是效率比较差,如果使用范围索引来做的话,实测性能提升20多倍。GiST对范围数据做聚类划分,搜索时可以快速定位到需要搜索的范围。

刚才讲的是做的第一层过滤,第二层过滤是帮你定位到两个数据块了,然后你去每一条检查,因为每个数据块涉及的记录也就是几百条,整个下来效率就非常高。

bitmapand,or原理如下:

范围数据类型,典型应用场景是物联网,以及智能DNS。智能DNS会根据你IP的来源落到某一个范围里,再去索引你到最近的库里面去。

1.2.4 仿真数据测试结果

《PostgreSQL bitmapAnd, bitmapOr, bitmap index scan, bitmap heap scan》

接下来讲一个比较有意思的场景,求数据差集,用到数据库的递归查询特性。比如说一张表是一亿数据的,用车辆ID这个场景说明。业务背景是商用车辆的轨迹跟踪,在一家企业里面,假设有一百万辆商用的车辆,一天可能上传几亿的轨迹数据上来,但用户想查今天没有出勤的车辆,怎么查?使用递归的方法可以做到0.几毫秒,也是非常有意思的事情。而传统的方法,使用left join,需要几秒。

根据真实数据的特征,构建一批仿真数据。

GIN的复合索引这种方法可以满足以上需求,但是,当数据量非常庞大或者列非常多时,GIN索引会比较大。

递归查询,典型的用户比如说区块链,还有ERP系统里面有很多的关系,特别是一个大数据,小数据的清洗。

被推荐的商品数总量:超过1千万,每一篇导购文章平均下来涉及的商品,从历史数据来看是11到50个商品,一篇文章会推11到50个商品给你。

方法1 优化技巧

40%

热点商品:是说非常大的店铺给的佣金非常高,很多人愿意去写文章推荐这种商品,这是热点商品。

建议可以拆成多张表(例如随机拆分,或者按强制条件拆分)。降低GIN索引的大小,同时还可以利用PostgreSQL 10的多表并行特性,提升查询性能。

当数据库发挥到40%功能的时候看一下是什么样的。

在一千万的商品里占到了2%的样子,我们来看热点商品被推荐的次数,比如说在整个6千万的推荐文章里面,有一千万的文章是推荐热点商品,接下来看一下效果。

PostgreSQL并行计算特性

1、数据库端编程

49彩票集团,1.2.5 PostgreSQL优化时效测试

PostgreSQL支持单表多核并行,也支持多表的并行查询

我们用传统的方法去写一个应用时,肯定就是让数据库做该做的东西,我要的时候告诉你要查出什么样的数据,但是一来一回,耗费在网络上的开销就变得特别大。特别是在银行这种系统里面,开户一开就是1个小时过去了,里面可能跟数据库交互多少次,那如果说这个时候你把这个程序逻辑写到数据库里面去的话,实际很多场景里面也在用的,特别是银行这些事务处理非常复杂,同时要求数据可靠性、一致性很高的场景用得比较多。所以实际上存储过程在银行、运营商用得比较多。

这些测试对应的就是实际的应用场景,一篇新的文章上来之后,多快的时间能够告诉你有没有人跟你重叠,如果你是普通商品的话,过滤39个跟你重复的,我就把文章替掉,不让你发布了。

单表并行,指一条SQL,在处理单张表的数据时,可以使用多个CPU进行运算。

一种方法是在外面用程序做,跟数据库交互若干次,另一种方法是跟数据库交互很少的次数,就是你把逻辑放到数据库中,我们来看一下可以达到什么样的效果?

如果一篇文章里推的都是热点商品,因为被推荐的次数多,记录所涉及的数据块更多,因此一级过滤出来的数据块比较多,二级过滤做的就比较多,但是也能够达到15个毫秒。

多表并行,指的是一条SQL涉及到多张表的处理(例如APPEND SCAN)时,可以并行的处理多个表的SCAN。

我们测试过万兆网的场景,做事物的处理,20条Query使用交互式的方式,还有使用逻辑全部放在数据库这一端做的,他们出来的差别可以看一下,使用逻辑数据库可以达到100万的QBS,如果把数据库放到云端的不同主机的话,数据库延迟可能更大,所以如果业务对延迟响应苛刻、并且业务逻辑允许的情况下,建议你放到数据库里面。

本文由49彩票集团发布于计算机网络,转载请注明出处:你也许收集了一些用户的数据,看看当数据库被

关键词: