部署DeepSeek模型,进群交流最in玩法!
立即加群
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >【TBase开源版测评】Hello, TBase

【TBase开源版测评】Hello, TBase

原创
作者头像
HappenLee
修改于 2020-08-30 13:57:23
修改于 2020-08-30 13:57:23
2.5K0
举报

笔者从业以来一直关注国产数据库的发展,以及各大公司在开源数据库领域的工作,很高兴能看到国产数据库在开源领域又填新丁:TBase。TBase已于2019年11月正式开源。2020年7月13日,TBase发布了开源版本2.1.0,该版本在多活分布式能力、性能、安全性、可维护性等多个关键领域得到全面的增强和升级。 PS:测评体验主要基于TBase最新的开源版本2.1.0。笔者本身从事的OLAP的数据库系统开发,所以本次测评会更多从分析型数据库的角度来审视TBase。由于笔者水平有限,文章难免有错漏之处,烦请斧正。

1.What's TBase ?

TBase是腾讯基于PostgreSQL研发的一个分布式HTAP数据库,适用于拥有海量数据、高并发、部分分析场景解决,以及分布式事务能力的应用场景。 从现有的资料来看,TBase本身在腾讯内部是经过业务长期迭代打磨的产品,目前在腾讯云上也提供商业化的版本销售。

1.1 TBase的架构

TBase的架构图
TBase的架构图

如图所示, TBase是一个典型的Shared Nothing的MPP数据库,它由三个部分组成:

  • GlobalTransactionManager(简称为 GTM), 是一个全局事务管理器,负责全局事务管理。同时它也作为一个GTS(时钟服务器)来发布全局的事务时间戳。
  • Coordinator Coordinator 是协调节点, 是数据库统一的对外入口。协调节点接受用户的SQL请求,解析SQL生成分布式执行计划。它存储系统的元数据,并不存储实际的业务数据,可以配合支持业务接入增长动态增加。
  • Datanode Datanode是数据节点,执行协调节点分发的执行计划,并分配资源执行该分布式执行计划。每个Data Node运行独立的PostgreSQL的节点,进行实际业务数据的存储。

2.TBase初体验

实践是检验真理的唯一标准,接下来我们直奔主题,开始TBase的试用体验。

2.1 编译安装

TBase的编译安装流程主要参考以下官方Wiki:

TBase_Quick_Start

整个TBase编译安装的过程和PostgreSQL-XC几乎大同小异,坦白说,相对来说这个过程对于没有PostgreSQL背景的新手来说还是略显复杂了。

这个中途还有一个小插曲,笔者在编译过程之中发现了一个PostgreSQL的编译Bug。PostgreSQL官方已经修复该编译Bug了,于是笔者也给TBase官方提交了修复PR,好在TBase的同学很快响应并进行了代码合入,感兴趣的同学可以参考这个链接:issues:72

这是笔者安装完成后集群的拓扑结构:

Host

Type

Port

192.168.1.116

GTM Primary

50001

192.168.1.115

GTM Replica

50001

192.168.1.116

CN1

30001

192.168.1.115

CN2

30001

192.168.1.116

DN1 Primary

40001

192.168.1.116

DN1 Replica

40000

192.168.1.115

DN2 Primary

40001

192.168.1.115

DN2 Replica

40000

3 深度测评

笔者将从多个方面,站在一个数据库使用者的角度来尝试测评TBase。管中窥豹,可见一斑,我们开始吧。

3.1 牛刀小试

先通过一些例子数据进行一些初体验。先建立如下表,并插入测试数据

代码语言:txt
AI代码解释
复制
 create table foo(
  id bigint, str text
) distribute by shard(id);

insert into foo values(1, 'tencent'), (2, 'shenzhen');

3.1.1 数据shard测试

看一看简单查询语句的执行计划

代码语言:txt
AI代码解释
复制
 explain select * from foo;
                          QUERY PLAN                           
---------------------------------------------------------------
 Remote Fast Query Execution  (cost=0.00..0.00 rows=0 width=0)
   Node/s: dn001, dn002
   ->  Seq Scan on foo  (cost=0.00..18.80 rows=880 width=40)
(3 rows)

查询正常分配到两个数据节点之上了,这个符合shard分片的数据扫描逻辑。但是这里明明笔者表中只有两行数据,但是这里判别为了880行?

代码语言:txt
AI代码解释
复制
test=> analyze foo;
ANALYZE
test=> explain select * from foo;
                          QUERY PLAN                           
---------------------------------------------------------------
 Remote Fast Query Execution  (cost=0.00..0.00 rows=0 width=0)
   Node/s: dn001, dn002
   ->  Seq Scan on foo  (cost=0.00..20.02 rows=2 width=16)
(3 rows)

手动analyze之后,恢复正常了。

继续进行我们数据分片的体验,执行下列语句

代码语言:txt
AI代码解释
复制
test=> explain select * from foo where id = 1;
                          QUERY PLAN                           
---------------------------------------------------------------
 Remote Fast Query Execution  (cost=0.00..0.00 rows=0 width=0)
   Node/s: dn001
   ->  Seq Scan on foo  (cost=0.00..20.02 rows=1 width=16)
         Filter: (id = 1)

test=> explain select * from foo where id = 2;
                          QUERY PLAN                           
---------------------------------------------------------------
 Remote Fast Query Execution  (cost=0.00..0.00 rows=0 width=0)
   Node/s: dn001
   ->  Seq Scan on foo  (cost=0.00..20.02 rows=1 width=16)
         Filter: (id = 2)

我们可以看到过滤条件被分片裁剪了,同时只下推都了一个节点dn001上了,表现不错。

然后我们加大一些难度,我们将上两个查询的过滤条件作为or 拼接起来试一试:

代码语言:txt
AI代码解释
复制
test=> explain select * from foo where id = 2 or id = 1;
                          QUERY PLAN                           
---------------------------------------------------------------
 Remote Fast Query Execution  (cost=0.00..0.00 rows=0 width=0)
   Node/s: dn001, dn002
   ->  Seq Scan on foo  (cost=0.00..20.03 rows=2 width=16)
         Filter: ((id = 2) OR (id = 1))

囧rz,TBase没能感知到这个两个条件都应该在同一个节点上,一股脑的推到所有节点上了,看来Tbase的Shard逻辑与查询规划的优化还有提升的空间。

小结

Tip 1:由于TBase是基于COST模型进行优化的,所以对应查询性能敏感的语句,尽量在使用前进行analyze.

Tip 2:TBase在数据分片列上只能选择单列,这个是笔者无法理解的。本身通过Hash分区就是计算hash值,原则上多列和单列实现上应该没有二致。所以在使用时,大家尽量选择区分度较大的列作为分片列。

Tip 3:目前看起来TBase的优化器感知数据分片的能力还是有所欠缺的,期许改进。

3.1.2 Join 小测

对一个数据库来说,Join 的查询规划是及其考验其优化器实现功力的一项重要内容,我们来看看TBase的表现吧。

再次建立一张新的空表:

代码语言:txt
AI代码解释
复制
 create table foo1(
  id bigint, str text
) distribute by shard(id);

尝试执行表foofoo1的join,这里通过分区列id作为等值join的条件

代码语言:txt
AI代码解释
复制
 explain select * from foo, foo1 where foo.id = foo1.id;
                              QUERY PLAN                               
-----------------------------------------------------------------------
 Remote Fast Query Execution  (cost=0.00..0.00 rows=0 width=0)
   Node/s: dn001, dn002
   ->  Hash Join  (cost=20.04..42.23 rows=9 width=56)
         Hash Cond: (foo1.id = foo.id)
         ->  Seq Scan on foo1  (cost=0.00..18.80 rows=880 width=40)
         ->  Hash  (cost=20.02..20.02 rows=2 width=16)
               ->  Seq Scan on foo  (cost=0.00..20.02 rows=2 width=16)

是一个普通的Hash Join,但是空表的条目数依旧判别为了880条,笔者尝试analyze之后也无改变。TBase是基于CBO进行优化的,如果表的信息不准确,那边很难进行到正确的查询规划。这里的Hash Join左右表的选择是错误的,很难得到一个高效率的查询结果。

再次尝试执行表foofoo1的join,这里通过非分区列str作为等值join的条件:

代码语言:txt
AI代码解释
复制
test=> explain select * from foo, foo1 where foo.str = foo1.str;
                                             QUERY PLAN                                             
----------------------------------------------------------------------------------------------------
 Remote Subquery Scan on all (dn001,dn002)  (cost=20.04..42.23 rows=9 width=56)
   ->  Hash Join  (cost=20.04..42.23 rows=9 width=56)
         Hash Cond: (foo1.str = foo.str)
         ->  Seq Scan on foo1  (cost=0.00..18.80 rows=880 width=40)
         ->  Hash  (cost=120.06..120.06 rows=2 width=16)
               ->  Remote Subquery Scan on all (dn001,dn002)  (cost=100.00..120.06 rows=2 width=16)
                     ->  Seq Scan on foo  (cost=0.00..20.02 rows=2 width=16)

出现了Remote SubQuery, 可见非分区列的join是更为消耗资源,也是更慢的。

然后我们加大一些难度,重新建立一张空的新表foo2,执行下列查询:

代码语言:txt
AI代码解释
复制
explain select * from foo, foo1, foo2 where foo.str = foo1.str and foo.id = foo1.id and foo1.id = foo2.id;
                                    QUERY PLAN                                     
-----------------------------------------------------------------------------------
 Remote Fast Query Execution  (cost=0.00..0.00 rows=0 width=0)
   Node/s: dn001, dn002
   ->  Hash Join  (cost=45.47..67.61 rows=4 width=96)
         Hash Cond: (foo2.id = foo.id)
         ->  Seq Scan on foo2  (cost=0.00..18.80 rows=880 width=40)
         ->  Hash  (cost=45.46..45.46 rows=1 width=56)
               ->  Hash Join  (cost=20.05..45.46 rows=1 width=56)
                     Hash Cond: ((foo1.str = foo.str) AND (foo1.id = foo.id))
                     ->  Seq Scan on foo1  (cost=0.00..18.80 rows=880 width=40)
                     ->  Hash  (cost=20.02..20.02 rows=2 width=16)
                           ->  Seq Scan on foo  (cost=0.00..20.02 rows=2 width=16)

TBase规划出了两级的Hash Join查询,并且优先进行了大小表的查询,同时也能感知到join条件列之中的shard列信息,这个多表查询的规划结果符合我们的预期。

小结

Tip 1:通过Shard列进行Join能够大大优化实际生成的查询规划,所以尽量进行Shard列的Join查询.

3.2 星型模型测试

通过上节的简单测试,可以反馈出部分TBase的表现了。接下来我们引入更为专业的星型模型测试对TBase进行测评。

关于星型模型

SSB(Star Schema Benchmark)是一个经典的基于现实商业应用的数据库模型,业界公认的一个OLAP的测试标准。

SSB基准测试包括:

事实表:lineorder

维度表:dates, customer,part, supplier

涉及了多个纬度的数据库查询能力的反馈,它能很好的展现出数据库在分析上的能力,所以我们依托与它的数据来产出数据。关于星型模型的具体使用方式可以参考如下链接:Star Schema Benchmark,SSB生成的数据是CSV格式的,这部分可以通过copy命令导入TBase。

3.2.1 多核并行计算能力测试

星型模型测试是一个典型的OLAP的测试数据集合,对一个数据库系统的多核并行计算能力有很高的要求,我们来看看TBase的表现。

我们以SSB的Query 1.1作为基准,由于TBase是默认开启并行执行的,我们先将TBase的多核并行的关闭,并查看该查询的执行计划:

代码语言:txt
AI代码解释
复制
postgres=# set max_parallel_workers_per_gather = 0;
SET
postgres=# explain SELECT SUM(LO_EXTENDEDPRICE*LO_DISCOUNT) AS
REVENUE
FROM  LINEORDER, DATES
WHERE  LO_ORDERDATE = D_DATEKEY
AND D_YEAR = 1993
AND LO_DISCOUNT BETWEEN 1 AND 3
AND LO_QUANTITY < 25;
                                                   QUERY PLAN                                                    
-----------------------------------------------------------------------------------------------------------------
 Finalize Aggregate  (cost=238924.50..238924.51 rows=1 width=32)
   ->  Remote Subquery Scan on all (dn001,dn002)  (cost=238924.49..238924.50 rows=1 width=0)
         ->  Partial Aggregate  (cost=238824.49..238824.50 rows=1 width=32)
               ->  Hash Join  (cost=193.03..238824.49 rows=223594 width=16)
                     Hash Cond: (lineorder.lo_orderdate = dates.d_datekey)
                     ->  Seq Scan on lineorder  (cost=0.00..232481.09 rows=782887 width=20)
                           Filter: ((lo_discount >= 1) AND (lo_discount <= 3) AND (lo_quantity < 25))
                     ->  Hash  (cost=290.47..290.47 rows=730 width=4)
                           ->  Remote Subquery Scan on all (dn001,dn002)  (cost=100.00..290.47 rows=730 width=4)
                                 ->  Seq Scan on dates  (cost=0.00..183.90 rows=730 width=4)
                                       Filter: (d_year = 1993)

通过查询计划我们可以看到,TBase没有进行Parallel的操作。

我们再重新开启多核并行,再次观察TBase的查询计划:

代码语言:txt
AI代码解释
复制
postgres=# set max_parallel_workers_per_gather = 2;
SET
postgres=# explain SELECT SUM(LO_EXTENDEDPRICE*LO_DISCOUNT) AS
REVENUE
FROM  LINEORDER, DATES
WHERE  LO_ORDERDATE = D_DATEKEY
AND D_YEAR = 1993
AND LO_DISCOUNT BETWEEN 1 AND 3
AND LO_QUANTITY < 25;
                                                           QUERY PLAN                                                    
       
-------------------------------------------------------------------------------------------------------------------------
-------
 Parallel Finalize Aggregate  (cost=175540.41..175540.42 rows=1 width=32)
   ->  Parallel Remote Subquery Scan on all (dn001,dn002)  (cost=175540.29..175540.40 rows=1 width=0)
         ->  Gather  (cost=175440.29..175440.40 rows=1 width=32)
               Workers Planned: 2
               ->  Partial Aggregate  (cost=174440.29..174440.30 rows=1 width=32)
                     ->  Parallel Hash Join  (cost=193.03..173974.47 rows=93164 width=16)
                           Hash Cond: (lineorder.lo_orderdate = dates.d_datekey)
                           ->  Parallel Seq Scan on lineorder  (cost=0.00..171218.79 rows=326203 width=20)
                                 Filter: ((lo_discount >= 1) AND (lo_discount <= 3) AND (lo_quantity < 25))
                           ->  Parallel Hash  (cost=290.47..290.47 rows=730 width=4)
                                 ->  Parallel Remote Subquery Scan on all (dn001,dn002)  (cost=100.00..290.47 rows=730 wi
dth=4)
                                       ->  Seq Scan on dates  (cost=0.00..183.90 rows=730 width=4)
                                             Filter: (d_year = 1993)
(13 rows)

开启并行执行之后,TBase在Query 1.1上有15%左右的性能提升,由于笔者仅有两台虚拟机作为集群,相信在更多数据节点的加持下,并行化的效果会更加显著:

非并行

并行

查询耗时

2109.242 ms

1776.838 ms

小结

Tip 1:在能开启多核并行执行的场景下,尽量开启,能够优化TBase的查询效率。但是需要注意监控多查询并发执行时数据库系统的压力变化。

3.2.2 非join查询转化join能力

在数据库之中,能够将非join查询转换为join是考验数据库优化器的一项重要的观察指标。一起来看看TBase的表现吧:

我们以SSB的Query 1.1作为基准,将这个查询做一个小的修改,改为查询发生在1992年一月的所有订单,所以我们执行以下查询:

代码语言:txt
AI代码解释
复制
postgres=# explain SELECT SUM(LO_EXTENDEDPRICE*LO_DISCOUNT) AS
REVENUE
FROM  LINEORDER
WHERE  LO_ORDERDATE in (select D_DATEKEY from DATES where D_DATEKEY >= 19920101 and D_DATEKEY <= 19920131)
AND LO_DISCOUNT BETWEEN 1 AND 3
AND LO_QUANTITY < 25;
                                                          QUERY PLAN                                                     
-------------------------------------------------------------------------------------------------------------------------
------
 Parallel Finalize Aggregate  (cost=173497.39..173497.40 rows=1 width=32)
   ->  Parallel Remote Subquery Scan on all (dn001,dn002)  (cost=173497.27..173497.39 rows=1 width=0)
         ->  Gather  (cost=173397.27..173397.38 rows=1 width=32)
               Workers Planned: 2
               ->  Partial Aggregate  (cost=172397.27..172397.28 rows=1 width=32)
                     ->  Parallel Hash Semi Join  (cost=197.34..172361.34 rows=7186 width=16)
                           Hash Cond: (lineorder.lo_orderdate = dates.d_datekey)
                           ->  Parallel Seq Scan on lineorder  (cost=0.00..171218.79 rows=326203 width=20)
                                 Filter: ((lo_discount >= 1) AND (lo_discount <= 3) AND (lo_quantity < 25))
                           ->  Parallel Hash  (cost=297.16..297.16 rows=53 width=4)
                                 ->  Parallel Remote Subquery Scan on all (dn001,dn002)  (cost=100.00..297.16 rows=53 wid
th=4)
                                       ->  Seq Scan on dates  (cost=0.00..196.68 rows=53 width=4)
                                             Filter: ((d_datekey >= 19920101) AND (d_datekey <= 19920131))

从查询计划上看,原先的in操作符被改写为了Semi Join。显然通过Semi Join来进行查询执行是比in更为高效的,这里TBase完成的符合咱们的预期。

接下来把in改为not in,重新来看看TBase的表现吧

代码语言:txt
AI代码解释
复制
postgres=# explain SELECT SUM(LO_EXTENDEDPRICE*LO_DISCOUNT) AS
REVENUE
FROM  LINEORDER
WHERE  LO_ORDERDATE not in (select D_DATEKEY from DATES where D_DATEKEY >= 19920101 and D_DATEKEY <= 19920131)
AND LO_DISCOUNT BETWEEN 1 AND 3
AND LO_QUANTITY < 25;
                                                            QUERY PLAN                                                   
-------------------------------------------------------------------------------------------------------------------------
----------
 Parallel Finalize Aggregate  (cost=179582.48..179582.49 rows=1 width=32)
   ->  Parallel Remote Subquery Scan on all (dn001,dn002)  (cost=179582.36..179582.48 rows=1 width=0)
         ->  Gather  (cost=179482.36..179482.47 rows=1 width=32)
               Workers Planned: 2
               ->  Partial Aggregate  (cost=178482.36..178482.37 rows=1 width=32)
                     ->  Parallel Seq Scan on lineorder  (cost=196.81..177666.85 rows=163101 width=16)
                           Filter: ((NOT (hashed SubPlan 1)) AND (lo_discount >= 1) AND (lo_discount <= 3) AND (lo_quanti
ty < 25))
                           SubPlan 1
                             ->  Remote Subquery Scan on all (dn001,dn002)  (cost=0.00..196.68 rows=53 width=4)
                                   ->  Seq Scan on dates  (cost=0.00..196.68 rows=53 width=4)
                                         Filter: ((d_datekey >= 19920101) AND (d_datekey <= 19920131))

显然,这一次TBase的表现就没有那么智能了。在显然不存在NULL值的情况下,此时选择Anti Join是更为好的执行计划选择。

小结

Tip 1:希望TBase能将Semi Join转换的兄弟Anti Join也能一起支持起来。

3.2.3 复制表关联查询

TBase支持Brocast Join,也就是复制表的Join。可以将小表以多个副本的方式分散到集群之中。每个节点上都有对应表的全量数据,这样能避免额外的网络开销,并带来可观Join的性能提升。SSB之中,除了Order表作为事实表较为庞大之外,其他的维度表都可以作为复制表存在,所以我们来试一试这个功能。

先在非复制表的情况下进行查询执行:

代码语言:txt
AI代码解释
复制
REVENUE
FROM  LINEORDER, DATES
WHERE  lo_custkey = d_holidayfl
AND D_YEAR = 1993;
   revenue   
-------------
 24304858700
(1 row)

Time: 3239.929 ms (00:03.240)

接下来笔者选取了Date表作为复制表,重建它,并重新导入数据。然后重新运行上面的查询:

代码语言:txt
AI代码解释
复制
postgres=# SELECT SUM(LO_EXTENDEDPRICE*LO_DISCOUNT) AS
REVENUE
FROM  LINEORDER, DATES
WHERE  lo_custkey = d_holidayfl
AND D_YEAR = 1993;
   revenue   
-------------
 24304858700
(1 row)

Time: 1535.882 ms (00:01.536)

我们可以看到,相对与没有使用复制表的查询,性能提升了接近50%,这样的性能提升还是非常可观的。

非复制表

复制表

查询耗时

3239.929 ms

1535.882 ms

小结

Tip 1:复制表虽然带来了可观的性能提升,同时也引入了较高的存储和数据更新的代价,所以在生产环境之中应该谨慎评估使用。

Tip 2: TBase可以考虑更为激进的复制表方案,例如类似Clickhouse的内存引擎,将复制表直接存在内存之中。

Tip 3: 同样的Brocast Join也可通过分区表实现,只不过需要引入右表的网络传输开销,在右表较小的情况下,未必是不可接受的方案。

4 总结

Tbase作为国产开源数据库的新成员,还是给笔者带来了一些不同解决问题的思路。通过基于基于PostgreSQL的生态,给它的使用和开发都带来了极大的便利性。但是同时TBase也存在一些问题:

  • 开源社区不活跃,文档匮乏。:在整个测评进行过程之中,笔者很多问题的解决都是通过搜索PostgreSQL的文档。这对于毫无PostgreSQL使用经验的新手来说是非常不友好的。希望TBase能够加强文档建设,同时利用好开源社区的力量,实现和云版本的互相促进的优势。
  • 开源版本功能不全:TBase没有提供类似TiSaprk的工具,同时也不支持列存储,在OLAP的应用上并没有优势。同时由于缺少了OSS平台,这会给在实际生产环境之中的使用带来极大的困难。
  • 部分功能较为难以应用: 一些功能存在比较古怪的情况,新建表的条目数目总是880行,尝试analyze之后也没有相应的变化等。笔者限于机器有限,没有进行冷热数据的测评。这部分需要修改配置文件对数据节点进行重启,这个逻辑看起来是不合理的,希望后续能进行改进。

最后,祝福TBase无论是开源还是云上的版本能够不断迭代成熟,为国产数据库的发展提供动力。共勉~~

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
【Tbase开源版测评】基于PostgreSQL的国产开源数据库初体验
之前本人主要使用过oracle,mysql,greenplum,tdsql,tidb等数据库。头一次接触基于PostgreSQL的国产开源数据库,如果如下内容有错误的地方,还希望各位朋友批评指正。
卖菜小弟
2020/08/15
2.9K4
【TBase开源版测评】深度测评TBase的shard分片和冷热分离存储特性
GlobalTransactionManager(简称 GTM), 是全局事务管理器,负责全局事务管理。GTM 上不存储业务数据。
charleyyang
2020/07/20
2.8K1
【TBase开源版测评】深度测评TBase的shard分片和冷热分离存储特性
开源TBase编译部署详细步骤
很多学员想学习TBase数据库,但是苦于没有企业版的授权文件,在编译部署开源版本的时候又遇到诸多问题,因此我写下这篇文章供大家参考。
腾讯云数据库 TencentDB
2020/12/23
2.8K0
开源TBase编译部署详细步骤
【TBase开源版测评】轻松愉快去O选项:TBase
部门的项目原先基于Oracle进行存储、DM层OLAP计算、后端接口访问,而Oracle只是单机+从库的部署方式,经过一段时间的使用,存储与性能都有捉襟见肘之处,另外也想节省成本,决定响应去O的大潮。
gregorywang
2020/09/01
1.8K1
Postgresql源码(132)分布式行锁的原理分析
PG中的行锁在上一片中做了分析《Postgresql源码(131)行锁的原理分析》,本篇对分布式PG(PGXL)中的行锁做一些分析。(版本:Postgres-XL 10alpha2)
mingjie
2024/05/24
2010
Postgresql源码(132)分布式行锁的原理分析
微信支付用的数据库开源了
腾讯TBase是一款腾讯自研高性能HTAP数据库,提供高性能的OLTP和OLAP能力,同时保证可扩展全局一致性分布式事务(ACID),为用户提供高一致性的分布式数据库服务和高性能的数据仓库服务。一方面解决了传统数据库扩展不足、数据sharding之后数据库事务的严格一致性难题、数据安全、跨地域容灾等问题,同时具备了高性能事务处理、数据治理、混合负载支持等能力。 在OLTP方面,TBase采用MVCC+全局时钟+2PC+SSI的方式来实现全局一致性分布式事务,同时引入大量性能优化的设计来减少全局事务带来的开
腾讯云数据库 TencentDB
2019/11/18
8670
微信支付用的数据库开源了
进阶数据库系列(九):PostgreSQL 执行计划
了解 PostgreSQL 执行计划对于程序员来说是一项关键技能,执行计划是我们优化查询,验证我们的优化查询是否确实按照我们期望的方式运行的重要方式。
民工哥
2023/08/22
1K0
进阶数据库系列(九):PostgreSQL 执行计划
PostgreSQL 查询语句开发写不好是必然,不是PG的锅
当时指出了一些问题,基于时间的原因知道有问题,但没有说出具体的问题,当时也提到这样写语句,数据库基本上无法走执行计划,因为没有统计分析。
AustinDatabases
2024/01/26
1740
PostgreSQL  查询语句开发写不好是必然,不是PG的锅
Postgresql_根据执行计划优化SQL
postgres查询规划过程中,查询请求的不同执行方案是通过建立不同的路径来表达的,在生成许多符合条件的路径之后,要从中选择出代价最小的路径,把它转化为一个计划,传递给执行器执行,规划器的核心工作就是生成多条路径,然后从中找出最优的那一条。
用户7353950
2022/06/23
9400
PostgreSQL执行计划数据结构
其中,相关子查询概念是内部依赖于外部,外部每次执行一次内部都执行一次,都是外部先执行,然后内部再执行,子查询需要外部传入值。而非相关子查询是内部查询独立于外部查询,仅需要执行一次并将结果作为外部查询条件使用。数据结构Plan中initPlan成员即为非相关子查询的链表指针。从上面的例子中可以知道子查询仅执行一次且独立于外部查询,所以他的执行计划中有InitPlan节点。其关系参考下图。
yzsDBA
2021/05/17
9740
PostgreSQL执行计划数据结构
PostgreSql的Explain命令详解
PostgreSQL为每个收到的查询设计一个查询规划。选择正确的匹配查询结构和数据属性的规划对执行效率是至关重要要的,所以系统包含一个复杂的规划器来试图选择好的规划。你可以使用EXPLAIN命令查看查询规划器创建的任何查询。阅读查询规划是一门艺术,需要掌握一定的经验,本节试图涵盖一些基础知识。
hbbliyong
2019/05/25
2.3K0
【TBase开源版测评】分布式数据自动shard分片
本次我们根据TBase测评操作指引说明文档体验分布式数据自动shard分片,命令和使用方式基本上跟PostgreSQL没有区别,给我们这些原来使用过PostgreSQL数据库的人能很快的上手使用。
用户7622706
2020/08/02
1.1K1
【TBase开源版测评】体验安装
本次我们参考官方教程(https://github.com/Tencent/TBase/wiki/1%E3%80%81TBase_Quick_Start )体验在虚拟机上安装TBaseV2。整个安装过程还是比较流畅的,对有过集群安装经验的人员来说,参考文档在安装过程中做了相应的调整还是可以完成安装的。但如果对于一个新手或是对postgresl数据库不太熟悉的人来说,安装文档还是有些地方说得不够详细的。
胖子辉
2020/08/02
1.4K1
[译]理解PG如何执行一个查询-2
Limit算子用于限制结果集的大小。PG使用limit算子进行limit和offset处理。Limit算子将输入集前x行去掉,返回接着的y行,再将剩下的丢弃。如果查询中包括offset,x表示offset的数量,否则x为0.如果查询中包含Limit,y表示limit数量,否则y是输入集的大小。
yzsDBA
2022/04/27
1.9K0
[译]理解PG如何执行一个查询-2
PostgreSQL 14中提升Nested Loop Joins性能的enable_memoize
最近在PG14中发现新增一个配置参数enable_memoize,通过此参数可以提升嵌套循环连接的性能,有人测试性能竟然能提升1000倍!
yzsDBA
2021/11/18
1.6K0
TBase数据节点在线扩容原理解析
对于Share-Nothing架构的分布式数据库来说,如何将数据均匀的分布到各个节点、在线扩容,以获取更大的存储容量和更高的并发访问量。成为各大分布式数据库系统的一大挑战,今天我将对腾讯云数据库TBase的数据节点在线扩容方案做一个简单的分享。
腾讯云数据库 TencentDB
2020/10/09
3K0
POSTGRESQL 怎么通过explain 来分析SQL查询性能
explain select a.first_name,a.last_name,a.last_update,fa.film_id from film_actor as fa right join actor as a on fa.actor_id = a.actor_id where fa.actor_id < 6;
AustinDatabases
2021/09/02
4.5K0
打造次世代分析型数据库(八):高效数据导入导出方案
作者介绍 ceciliasu(苏翠翠),腾讯云数据库工程师,加入腾讯以来持续从事分布式数据库内核研发工作,曾负责TDSQL PG版、CDW PG快速扩容能力设计和研发。目前主要参与CDW PG数据库内核研发相关工作,负责外部数据快速导入工具的设计和研发。 原生数据导入导出方式以及存在的问题 使用原生COPY导入数据相当耗时,这是因为在CN上执行COPY导入数据是一个串行执行的过程,所有数据都需要经过CN处理分发给不同DN入库,所以CN是瓶颈,它只适合小数据量的导入。 图表 1 COPY数据流向示意图 TD
腾讯云大数据
2022/11/11
7880
打造次世代分析型数据库(八):高效数据导入导出方案
Postgresql源码(116)提升子查询案例分析
对于SQL:select * from student, (select * from score where sno > 2) s where student.sno = s.sno;
mingjie
2023/11/23
3420
Postgresql源码(116)提升子查询案例分析
PostgreSQL技术大讲堂 - 第31讲:SQL调优技巧
PostgreSQL从小白到专家,是从入门逐渐能力提升的一个系列教程,内容包括对PG基础的认知、包括安装使用、包括角色权限、包括维护管理、、等内容,希望对热爱PG、学习PG的同学们有帮助,欢迎持续关注CUUG PG技术大讲堂。
用户5892232
2023/11/01
3660
PostgreSQL技术大讲堂 - 第31讲:SQL调优技巧
推荐阅读
相关推荐
【Tbase开源版测评】基于PostgreSQL的国产开源数据库初体验
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档