PolarDB 开源版通过 brin 实现千分之一的存储空间, 高效率检索时序数据

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
简介: PolarDB 的云原生存算分离架构, 具备低廉的数据存储、高效扩展弹性、高速多机并行计算能力、高速数据搜索和处理; PolarDB与计算算法结合, 将实现双剑合璧, 推动业务数据的 价值产出, 将数据变成生产力. 本文将介绍PolarDB 开源版通过 brin 实现千分之一的存储空间, 高效率检索时序数据

背景

PolarDB 的云原生存算分离架构, 具备低廉的数据存储、高效扩展弹性、高速多机并行计算能力、高速数据搜索和处理; PolarDB与计算算法结合, 将实现双剑合璧, 推动业务数据的
价值产出, 将数据变成生产力.

本文将介绍PolarDB 开源版通过 brin 实现千分之一的存储空间, 高效率检索时序数据

测试环境为macos+docker, polardb部署请参考:

原理

PolarDB 的普通表采用堆存储, 最小分配单位为block, 不够了就在文件末尾追加block.

所以根据时序数据的append only 、 时间字段递增特征. 一个block内的时间字段的值基本上是相邻的, 相邻的block时间值也相邻.

时序数据通常是按片搜索, 例如分钟、小时、天等粒度的片搜索和统计.

怎样高效、低成本的检索时序数据? PolarDB BRIN 块级别范围索引, 千分之一的存储, 实现btree同级别的片区搜索性能.

brin为什么省存储呢? 因为一片blocks, 只存储其索引字段的min,max,nullif的统计值. 所以非常节省空间.

模拟测试

1、建立时序表

create table tbl (id int, v1 int, v2 int, crt_time timestamp(0));  

2、写入500万条时序数据

insert into tbl select id, random()*10, random()*100, now()+(id||'second')::interval from generate_series(1,5000000) id;  

3、查询时序字段的边界值

postgres=# select min(crt_time), max(crt_time) from tbl;  
         min         |         max           
---------------------+---------------------  
 2022-12-21 08:47:19 | 2023-02-17 05:40:38  
(1 row)  

4、普通btree索引的测试, 占用空间等.

create index on tbl using btree (crt_time);  
postgres=# \dt+  
                    List of relations  
 Schema | Name | Type  |  Owner   |  Size  | Description   
--------+------+-------+----------+--------+-------------  
 public | tbl  | table | postgres | 249 MB |   
(1 row)  
  
postgres=# \di+  
                              List of relations  
 Schema |       Name       | Type  |  Owner   | Table |  Size  | Description   
--------+------------------+-------+----------+-------+--------+-------------  
 public | tbl_crt_time_idx | index | postgres | tbl   | 107 MB |   
(1 row)  
postgres=# explain (analyze,verbose,timing,costs,buffers) select count(*) from tbl where crt_time between '2022-12-30' and '2022-12-31';  
                                                                                QUERY PLAN                                                                                   
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------  
 Aggregate  (cost=32345.17..32345.18 rows=1 width=8) (actual time=19.311..19.317 rows=1 loops=1)  
   Output: count(*)  
   Buffers: shared hit=790  
   ->  Bitmap Heap Scan on public.tbl  (cost=532.68..32282.67 rows=25000 width=0) (actual time=5.786..13.871 rows=86401 loops=1)  
         Recheck Cond: ((tbl.crt_time >= '2022-12-30 00:00:00'::timestamp without time zone) AND (tbl.crt_time <= '2022-12-31 00:00:00'::timestamp without time zone))  
         Heap Blocks: exact=551  
         Buffers: shared hit=790  
         ->  Bitmap Index Scan on tbl_crt_time_idx  (cost=0.00..526.43 rows=25000 width=0) (actual time=5.723..5.724 rows=86401 loops=1)  
               Index Cond: ((tbl.crt_time >= '2022-12-30 00:00:00'::timestamp without time zone) AND (tbl.crt_time <= '2022-12-31 00:00:00'::timestamp without time zone))  
               Buffers: shared hit=239  
 Planning Time: 0.081 ms  
 Execution Time: 19.550 ms  
(12 rows)  

5、判断时间字段是否适合brin索引: 相关性为1, 表明这个字段有自增属性、而且边界清晰. 非常适合brin索引.

相关性的范围是-1到1, 越接近1或者-1都适合brin.

postgres=# select correlation from pg_stats where tablename='tbl' and attname='crt_time';  
 correlation   
-------------  
           1  
(1 row)  

6、测试brin索引, 观察其占用空间, 查询性能.

drop index tbl_crt_time_idx;  
  
  
create index on tbl using brin (crt_time);  
  
      
postgres=# explain (analyze,verbose,timing,costs,buffers) select count(*) from tbl where crt_time between '2022-12-30' and '2022-12-31';  
                                                                                QUERY PLAN                                                                                   
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------  
 Aggregate  (cost=33599.60..33599.61 rows=1 width=8) (actual time=26.022..26.025 rows=1 loops=1)  
   Output: count(*)  
   Buffers: shared hit=642  
   ->  Bitmap Heap Scan on public.tbl  (cost=33.38..33387.41 rows=84878 width=0) (actual time=0.937..18.871 rows=86401 loops=1)  
         Recheck Cond: ((tbl.crt_time >= '2022-12-30 00:00:00'::timestamp without time zone) AND (tbl.crt_time <= '2022-12-31 00:00:00'::timestamp without time zone))  
         Rows Removed by Index Recheck: 14079  
         Heap Blocks: lossy=640  
         Buffers: shared hit=642  
         ->  Bitmap Index Scan on tbl_crt_time_idx  (cost=0.00..12.16 rows=100402 width=0) (actual time=0.420..0.421 rows=6400 loops=1)  
               Index Cond: ((tbl.crt_time >= '2022-12-30 00:00:00'::timestamp without time zone) AND (tbl.crt_time <= '2022-12-31 00:00:00'::timestamp without time zone))  
               Buffers: shared hit=2  
 Planning Time: 0.168 ms  
 Execution Time: 26.162 ms  
(13 rows)  
  
  
  
postgres=# \di+  
                             List of relations  
 Schema |       Name       | Type  |  Owner   | Table | Size  | Description   
--------+------------------+-------+----------+-------+-------+-------------  
 public | tbl_crt_time_idx | index | postgres | tbl   | 48 kB |   
(1 row)  

结论符合预期:

  • brin占用空间只有btree的2000分之一大小, 但是在进行范围条件搜索时, brin索引性能相当于btree, 扫描更少的数据块得到同级别的性能.

参考

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
19天前
|
关系型数据库 分布式数据库 PolarDB
电子书阅读分享《PolarDB开发者大会:拥抱开源 | 成就开源PolarDB开发者大会:拥抱开源 | 成就开源》
电子书阅读分享《PolarDB开发者大会:拥抱开源 | 成就开源PolarDB开发者大会:拥抱开源 | 成就开源》
12 3
|
19天前
|
关系型数据库 分布式数据库 PolarDB
电子书阅读分享《PolarDB开发者大会:PolarDB在线数据实时分析加速》
电子书阅读分享《PolarDB开发者大会:PolarDB在线数据实时分析加速》
13 3
|
19天前
|
关系型数据库 分布式数据库 PolarDB
电子书阅读分享《PolarDB开发者大会:PolarDB在线数据实时分析加速》
电子书阅读分享《PolarDB开发者大会:PolarDB在线数据实时分析加速》
16 1
|
21天前
|
关系型数据库 分布式数据库 PolarDB
电子书阅读分享《PolarDB开发者大会:PolarDB在线数据实时分析加速》
电子书阅读分享《PolarDB开发者大会:PolarDB在线数据实时分析加速》
13 1
|
21天前
|
关系型数据库 分布式数据库 PolarDB
电子书阅读分享《PolarDB开发者大会:拥抱开源 | 成就开源》
电子书阅读分享《PolarDB开发者大会:拥抱开源 | 成就开源》
|
22天前
|
关系型数据库 分布式数据库 PolarDB
电子书阅读分享《PolarDB开发者大会:拥抱开源 | 成就开源》
电子书阅读分享《PolarDB开发者大会:拥抱开源 | 成就开源》
17 4
|
24天前
|
关系型数据库 分布式数据库 PolarDB
电子书阅读分享《PolarDB开发者大会:拥抱开源 | 成就开源》
电子书阅读分享《PolarDB开发者大会:拥抱开源 | 成就开源》
11 1
|
29天前
|
人工智能 算法 关系型数据库
PolarDB for AI助力菜鸟实现一站式数据智能
菜鸟通过应用PolarDB for AI,实现云资源成本降低了50%
127 2
|
30天前
|
关系型数据库 MySQL 数据处理
MySQL vs. PostgreSQL:选择适合你的开源数据库
在当今信息时代,开源数据库成为许多企业和开发者的首选。本文将比较两个主流的开源数据库——MySQL和PostgreSQL,分析它们的特点、优势和适用场景,以帮助读者做出明智的选择。
|
1月前
|
弹性计算 关系型数据库 数据库
开源PostgreSQL在倚天ECS上的最佳优化实践
本文基于倚天ECS硬件平台,以自顶向下的方式从上层应用、到基础软件,再到底层芯片硬件,通过应用与芯片的硬件特性的亲和性分析,实现PostgreSQL与倚天芯片软硬协同的深度优化,充分使能倚天硬件性能,帮助开源PostgreSQL应用实现性能提升。

热门文章

最新文章

相关产品

  • 云原生数据库 PolarDB