KADB向量化执行引擎

已于 2023-09-12 10:47:25 修改
阅读量137 收藏
点赞数
文章标签： 数据库 big data database
于 2023-09-12 10:45:58 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/liuzhiliang2010/article/details/121209545
版权


#**KADB向量化执行引擎技术**
**随着企业的发展和数字化转型，企业的数据量越来越大，
数字化转型的加速推进，使得业务数据爆炸性增长，海量数据已成为数字化时代最为典型的标志之一。**

**传统的集中式数据库已经不能满足决策者需要，为了满足大数据下的分析需求，分部署数据库出现了，早期的分部署式数据库如：Greenplum、vertica、gbase现在的Tidb、gaussdb、kadb等**

**KADB是北京人大金仓科技股份有限公司基于postgres数据库，借鉴Greenplum架构研发的一款分布式数据库，KADB完美集成了postgresXX能力和Greenplum的计算能，同时KADB还推出了全新的向量化执行引擎传统的QUERY执行器在处理表达式时，是一行一行的处理模式。
比如在处理(x+y)这个表达式时，首先读取一条记录的X值，然后读取这条记录的Y值，然后执行+操作符。然后将结果返回给上层node。
然而，向量化执行器，一个操作符可以处理多个值，比如(x+y) ，x, y并不是scalar值，而是一批值的向量，向量化执行的结果也不是scalar值，而是向量。 
相比传统的query引擎，向量化执行更适合处理大批量的数据。**

为了更好的理解和比较，我们采用最新的KADB来做一下不同执行引擎的测试

# 集群配置 #

| 集群角色 | 服务器数量|实例数量 | 服务器配置 |
| :----:| :----: |:----:  | :----: |
| 管理节点 | 2 |  |  CPU: E5-2620 v4 @ 2.10GHz 内存：256G 硬盘:STAT 7200 |
| 计算节点 | 6 |  8 |CPU: E5-2620 v4 @ 2.10GHz 内存：256G 硬盘:STAT 7200 |



# 数据量  #
采用标准的TPC_H程序生成测试数据

| TPC_H数据量  |  lineitem表数据条数 |  lineitem表大小|
| :----:| :----: |:----:|
|1GB    |  6百万  |652 MB|
|100GB  |  6亿    | 64 GB|
|1TB    |  60亿   | 652 GB


## 表结构 ##
采用TPC_H lineitem 表作为测试表，存储模式为列存。


    CREATE TABLE lineitem
    (L_ORDERKEY BIGINT,
    L_PARTKEY INT,
    L_SUPPKEY INT,
    L_LINENUMBER INTEGER,
    L_QUANTITY float,
    L_EXTENDEDPRICE float,
    L_DISCOUNT float,
    L_TAX  float,
    L_RETURNFLAG CHAR(1),
    L_LINESTATUS CHAR(1),
    L_SHIPDATE DATE,
    L_COMMITDATE DATE,
    L_RECEIPTDATE DATE,
    L_SHIPINSTRUCT CHAR(25),
    L_SHIPMODE CHAR(10),
    L_COMMENT VARCHAR(44))
    using ao_column;


<h1 align = "center">ORCA、PostgreSQL的JIT、向量化引擎 三种执行引擎对比</h1>

**ORCA、PostgreSQL的JIT、向量化引擎 三种执行引擎,其中ORCA是从Greenplum集成过来的，JIT是从PostgreSQL继承过来的，向量化引擎是KADB最新研发的。下面测试在不同数据量下三种执行引擎的效果。    注：数据都是通过标准TPC_H产生的数据**

# 1.数据量 1GB  #
## ORCA执行引擎 ##
    默认ORCA是开启的。
    postgres=# show optimizer;
     optimizer
    -----------
     on
    (1 row)
    postgres=# select
    postgres-# l_returnflag,
    postgres-# l_linestatus,
    postgres-# sum(l_quantity) as sum_qty,
    postgres-# sum(l_extendedprice) as sum_base_price,
    postgres-# sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
    postgres-# sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
    postgres-# avg(l_quantity) as avg_qty,
    postgres-# avg(l_extendedprice) as avg_price,
    postgres-# avg(l_discount) as avg_disc,
    postgres-# count(*) as count_order
    postgres-# from
    postgres-# lineitem_1g
    postgres-# where
    postgres-# l_shipdate <= date '1998-12-01' - interval '90 days'
    postgres-# group by
    postgres-# l_returnflag,
    postgres-# l_linestatus
    postgres-# ;
     l_returnflag | l_linestatus | sum_qty  |   sum_base_price   |   sum_disc_price   | sum_charge |  avg_qty   |
     avg_price  |   avg_disc   | count_order
    --------------+--------------+----------+--------------------+--------------------+--------------------+--------------------+----
    ----------------+----------------------+-------------
     N| F|   991417 | 1487504710.3799996 | 1413082168.0540998 | 1469649223.1943755 | 25.516471920522985 | 38284.467760848296 |  0.05009342667421628 |   38854
     A| F| 37734107 |  56586554400.73018 |  53758257134.86981 |  55909065222.82771 | 25.522005853257337 |  38273.12973462179 | 0.049985295838423954 | 1478493
     N| O| 74476040 | 111701729697.74016 | 106118230307.60542 | 110367043872.49702 |  25.50222676958499 |  38249.11798890832 |  0.04999658605376632 | 2920374
     R| F| 37719753 |  56568041380.90002 |  53741292684.60405 |  55889619119.83172 |  25.50579361269077 | 38250.854626099666 |  0.05000940583015323 | 1478870
    (4 rows)
    
    Time: 534.271 ms
    postgres=#
       
## JIT执行引擎 ##
    打开JIT执行引起调整相关参数强制走JIT执行引擎。
    set optimizer=off;(JIT不支持ORAC所以要先关闭ORAC)
    set jit to on;
    set jit_optimize_above_cost to 0;
    set jit_above_cost to 0;
    set jit_inline_above_cost to 0;
    postgres=# select
    l_returnflag,
    l_linestatus,
    sum(l_quantity) as sum_qty,
    sum(l_extendedprice) as sum_base_price,
    sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
    sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
    avg(l_quantity) as avg_qty,
    avg(l_extendedprice) as avg_price,
    avg(l_discount) as avg_disc,
    count(*) as count_order
    from
    lineitem_1g
    where
    l_shipdate <= date '1998-12-01' - interval '90 days'
    group by
    l_returnflag,
    l_linestatus
    ;
     l_returnflag | l_linestatus | sum_qty  |   sum_base_price   |   sum_disc_price   | sum_charge |  avg_qty   |
     avg_price  |  avg_disc   | count_order
    --------------+--------------+----------+--------------------+--------------------+--------------------+--------------------+----
    ----------------+---------------------+-------------
     A| F| 37734107 | 56586554400.730194 |  53758257134.86982 |  55909065222.82772 | 25.522005853257337 | 38273.129734621805 | 0.04998529583842396 | 1478493
     N| F|   991417 | 1487504710.3799999 | 1413082168.0540996 | 1469649223.1943755 | 25.516471920522985 |   38284.4677608483 | 0.05009342667421627 |   38854
     N| O| 74476040 | 111701729697.74011 | 106118230307.60542 | 110367043872.49704 |  25.50222676958499 |  38249.11798890831 | 0.04999658605376633 | 2920374
     R| F| 37719753 |  56568041380.90002 |  53741292684.60404 |  55889619119.83172 |  25.50579361269077 | 38250.854626099666 | 0.05000940583015323 | 1478870
    (4 rows)
    
    Time: 1251.055 ms (00:01.251)
    postgres=#
    
    



## 向量化执行引擎 ##
    打开向量化执行引擎
    set optimizer = off ;(向量化也不支持ORAC所以也要先关闭ORAC)
    set enable_groupagg to off;
    set jit to off;
    set enable_vectorize_engine to on;
    postgres=# select
    l_returnflag,
    l_linestatus,
    sum(l_quantity) as sum_qty,
    sum(l_extendedprice) as sum_base_price,
    sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
    sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
    avg(l_quantity) as avg_qty,
    avg(l_extendedprice) as avg_price,
    avg(l_discount) as avg_disc,
    count(*) as count_order
    from
    lineitem_1g
    where
    l_shipdate <= date '1998-12-01' - interval '90 days'
    group by
    l_returnflag,
    l_linestatus
    ;
     l_returnflag | l_linestatus | sum_qty  |   sum_base_price   |   sum_disc_price   | sum_charge |  avg_qty   |avg_price  |   avg_disc   | count_order
    --------------+--------------+----------+--------------------+--------------------+--------------------+--------------------+--------------------+----------------------+-------------
     R| F| 37719753 |  56568041380.90002 |  53741292684.60406 |  55889619119.83171 |  25.50579361269077 | 38250.854626099666 | 0.050009405830153224 | 1478870
     A| F| 37734107 |  56586554400.73018 |  53758257134.86983 |  55909065222.82771 | 25.522005853257337 |  38273.12973462179 |  0.04998529583842394 | 1478493
     N| O| 74476040 | 111701729697.74014 | 106118230307.60542 |   110367043872.497 |  25.50222676958499 |  38249.11798890832 |  0.04999658605376632 | 2920374
     N| F|   991417 | 1487504710.3799996 | 1413082168.0540996 | 1469649223.1943755 | 25.516471920522985 | 38284.467760848296 |  0.05009342667421627 |   38854
    (4 rows)
    
    Time: 280.208 ms
    postgres=#
    
   
# 结果对比 #

| 执行引擎类型 | 时间 |
| :-----:| :----: |
| ORCA | 534.271 ms |
| JIT | 1251.055 ms  |
| 向量化 | 280.208 ms |

**从上面可以看出数据量为1GB时，向量化执行引擎是三种执行中用时最短的大概是GPORCA
执行引擎的2倍，是JIT的6倍。那随着数据量增长是否还会有这样的效果呢？下面我增加数据量进行测试。**

----------

# 2.数据量 100GB  #
## ORCA执行引擎 ##
    postgres=# show  optimizer;
     optimizer
    -----------
     on
    (1 row)
    
    Time: 0.204 ms
    
    postgres=# select
    postgres-# l_returnflag,
    postgres-# l_linestatus,
    postgres-# sum(l_quantity) as sum_qty,
    postgres-# sum(l_extendedprice) as sum_base_price,
    postgres-# sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
    postgres-# sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
    postgres-# avg(l_quantity) as avg_qty,
    postgres-# avg(l_extendedprice) as avg_price,
    postgres-# avg(l_discount) as avg_disc,
    postgres-# count(*) as count_order
    postgres-# from
    postgres-# lineitem_100g
    postgres-# where
    postgres-# l_shipdate <= date '1998-12-01' - interval '90 days'
    postgres-# group by
    postgres-# l_returnflag,
    postgres-# l_linestatus
    postgres-# ;
     l_returnflag | l_linestatus |  sum_qty   |   sum_base_price   |   sum_disc_price   | sum_charge |  avg_qty   | avg_price  |   avg_disc   | count_order
    --------------+--------------+------------+--------------------+--------------------+--------------------+--------------------+--------------------+----------------------+-------------
     A| F| 3775127758 |  5660776097194.451 |   5377736398183.81 |  5592847429515.931 | 25.499370423275426 |38236.11698430491 |  0.05000224353247317 |   148047881
     N| O| 7436302976 |  11150725681373.66 | 10593195308234.557 | 11016932248183.568 | 25.500009404374193 | 38237.227646361185 |  0.04999791831849612 |   291619617
     R| F| 3775724970 |  5661603032745.284 |  5378513563915.388 |  5593662252667.158 |  25.50006628406532 | 38236.697258452594 |  0.05000130434119794 |   148067261
     N| F|   98553062 | 147771098385.98004 | 140384965965.03406 | 145999793032.77475 | 25.501556956882876 |38237.19938880452 | 0.049985284338125296 | 3864590
    (4 rows)
    
    Time: 39110.600 ms (00:39.111)
    postgres=#
    





## JIT执行引擎 ##
    postgres=# set optimizer = off;
    SET
    Time: 310.773 ms
    postgres=# select
    l_returnflag,
    l_linestatus,
    sum(l_quantity) as sum_qty,
    sum(l_extendedprice) as sum_base_price,
    sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
    sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
    avg(l_quantity) as avg_qty,
    avg(l_extendedprice) as avg_price,
    avg(l_discount) as avg_disc,
    count(*) as count_order
    from
    lineitem_100g
    where
    l_shipdate <= date '1998-12-01' - interval '90 days'
    group by
    l_returnflag,
    l_linestatus
    ;
     l_returnflag | l_linestatus |  sum_qty   |  sum_base_price   |   sum_disc_price   | sum_charge |  avg_qty   | avg_price  |   avg_disc   | count_order
    --------------+--------------+------------+-------------------+--------------------+--------------------+--------------------+--------------------+----------------------+-------------
     A| F| 3775127758 | 5660776097194.451 |  5377736398183.811 |  5592847429515.931 | 25.499370423275426 |  38236.11698430491 |  0.05000224353247317 |   148047881
     N| F|   98553062 |   147771098385.98 | 140384965965.03403 | 145999793032.77478 | 25.501556956882876 |  38237.19938880451 | 0.049985284338125296 | 3864590
     N| O| 7436302976 | 11150725681373.66 | 10593195308234.559 | 11016932248183.568 | 25.500009404374193 | 38237.227646361185 |  0.04999791831849612 |   291619617
     R| F| 3775724970 | 5661603032745.282 |  5378513563915.389 |  5593662252667.159 |  25.50006628406532 |  38236.69725845258 |  0.05000130434119794 |   148067261
    (4 rows)
    
    Time: 58297.991 ms (00:58.298)
    postgres=#
    



## 向量化执行引擎 ##
    postgres=# set enable_groupagg to off;
    SET
    Time: 18.182 ms
    postgres=# set jit to off;
    SET
    Time: 0.556 ms
    postgres=# set enable_vectorize_engine to on;
    SET
    Time: 0.630 ms
    postgres=# select
    l_returnflag,
    l_linestatus,
    sum(l_quantity) as sum_qty,
    sum(l_extendedprice) as sum_base_price,
    sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
    sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
    avg(l_quantity) as avg_qty,
    avg(l_extendedprice) as avg_price,
    avg(l_discount) as avg_disc,
    count(*) as count_order
    from
    lineitem_100g
    where
    l_shipdate <= date '1998-12-01' - interval '90 days'
    group by
    l_returnflag,
    l_linestatus
    ;
     l_returnflag | l_linestatus |  sum_qty   |  sum_base_price   |   sum_disc_price   | sum_charge |  avg_qty   | avg_price  |   avg_disc   | count_order
    --------------+--------------+------------+-------------------+--------------------+--------------------+--------------------+--------------------+----------------------+-------------
     R| F| 3775724970 | 5661603032745.284 |  5378513563915.388 |  5593662252667.158 |  25.50006628406532 | 38236.697258452594 |  0.05000130434119794 |   148067261
     A| F| 3775127758 | 5660776097194.452 |   5377736398183.81 |  5592847429515.932 | 25.499370423275426 |  38236.11698430491 |  0.05000224353247317 |   148047881
     N| O| 7436302976 | 11150725681373.66 | 10593195308234.555 | 11016932248183.566 | 25.500009404374193 | 38237.227646361185 | 0.049997918318496114 |   291619617
     N| F|   98553062 |   147771098385.98 | 140384965965.03406 | 145999793032.77478 | 25.501556956882876 |  38237.19938880451 |  0.04998528433812528 | 3864590
    (4 rows)
    
    Time: 19781.192 ms (00:19.781)
    postgres=#
    
   
# 结果对比 #

| 执行引擎类型 | 时间 |
| :-----:| :----: |
| ORCA | 39110.600 ms |
| JIT | 58297.991 ms |
| 向量化 | 19781.192 ms|

**从测试结果来看，当数据量是100GB的时候，向量化执行引擎仍然是三种执行引擎里用时最短的，是ORCA2倍，是JIT的3倍，可以看出随着数据量的增长，JIT引擎的用时有所提升，但是和向量化引擎和ORCA引擎还是有差距，那么我们在增加数据量来看一下对比情况。**


----------

# 3.  数据量 1TB  #
## ORCA执行引擎 ##

    postgres=# show  optimizer;
     optimizer
    -----------
     on
    (1 row)
    
    Time: 0.204 ms
    
    postgres=# select
    postgres-# l_returnflag,
    postgres-# l_linestatus,
    postgres-# sum(l_quantity) as sum_qty,
    postgres-# sum(l_extendedprice) as sum_base_price,
    postgres-# sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
    postgres-# sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
    postgres-# avg(l_quantity) as avg_qty,
    postgres-# avg(l_extendedprice) as avg_price,
    postgres-# avg(l_discount) as avg_disc,
    postgres-# count(*) as count_order
    postgres-# from
    postgres-# lineitem_100g
    postgres-# where
    postgres-# l_shipdate <= date '1998-12-01' - interval '90 days'
    postgres-# group by
    postgres-# l_returnflag,
    postgres-# l_linestatus
    postgres-# ;
     l_returnflag | l_linestatus |   sum_qty   |   sum_base_price   |   sum_disc_price   | sum_charge |  avg_qty   | avg_price  |   avg_disc   | count_order
    --------------+--------------+-------------+--------------------+--------------------+--------------------+--------------------+--------------------+----------------------+-------------
     N| F|  1009474721 |  1513655546292.845 |  1437964915505.205 1495505427205.7922 | 25.501252901992732 |38237.82021433879 | 0.050007751109846676 |39585299
     A| F| 38663494247 |  57975897720343.05 |  55077056575228.49 |  57280139974700.33 | 25.499902314719474 |38237.09567046249 |  0.05000115197512918 |  1516221269
     N| O| 76132027266 | 114160174445769.75 | 108452120147030.14 | 112790257632072.64 | 25.500031386008317 |38237.36390505108 |  0.04999960482532665 |  2985566022
     R| F| 38663342979 |  57975227940306.44 | 55076481003328.086 |  57279552747411.33 | 25.500078164568315 |38237.067210909765 |  0.04999968871567838 |  1516204881
    (4 rows)
    
    Time: 340687.305 ms (05:40.687)

 


## JIT执行引擎 ##
    postgres=# set optimizer = off ;
    SET
    Time: 21.191 ms
    postgres=# select
    postgres-# l_returnflag,
    postgres-# l_linestatus,
    postgres-# sum(l_quantity) as sum_qty,
    postgres-# sum(l_extendedprice) as sum_base_price,
    postgres-# sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
    postgres-# sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
    postgres-# avg(l_quantity) as avg_qty,
    postgres-# avg(l_extendedprice) as avg_price,
    postgres-# avg(l_discount) as avg_disc,
    postgres-# count(*) as count_order
    postgres-# from
    postgres-# lineitem_1t
    postgres-# where
    postgres-# l_shipdate <= date '1998-12-01' - interval '90 days'
    postgres-# group by
    postgres-# l_returnflag,
    postgres-# l_linestatus
    postgres-# ;
    
     l_returnflag | l_linestatus |   sum_qty   |   sum_base_price   |   sum_disc_price   | sum_charge |  avg_qty   | avg_price |   avg_disc   | count_order
    --------------+--------------+-------------+--------------------+--------------------+--------------------+--------------------+-------------------+----------------------+-------------
     A| F| 38663494247 | 57975897720343.055 |   55077056575228.5 | 57280139974700.336 | 25.499902314719474 |38237.0956704625 | 0.050001151975129186 |  1516221269
     N| F|  1009474721 |  1513655546292.845 |  1437964915505.205 | 1495505427205.7922 | 25.501252901992732 |38237.82021433879 |  0.05000775110984667 |39585299
     N| O| 76132027266 | 114160174445769.75 | 108452120147030.16 | 112790257632072.62 | 25.500031386008317 |38237.36390505108 | 0.049999604825326636 |  2985566022
     R| F| 38663342979 |  57975227940306.43 |  55076481003328.08 |  57279552747411.33 | 25.500078164568315 |38237.06721090976 | 0.049999688715678385 |  1516204881
    (4 rows)
    
    Time: 1625708.799 ms (27:05.709)
    
    


## 向量化执行引擎 ##
    set optimizer = off ;
    set enable_groupagg to off;
    set jit to off;
    set enable_vectorize_engine to on;
    postgres=# select
    postgres-# l_returnflag,
    postgres-# l_linestatus,
    postgres-# sum(l_quantity) as sum_qty,
    postgres-# sum(l_extendedprice) as sum_base_price,
    postgres-# sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
    postgres-# sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
    postgres-# avg(l_quantity) as avg_qty,
    postgres-# avg(l_extendedprice) as avg_price,
    postgres-# avg(l_discount) as avg_disc,
    postgres-# count(*) as count_order
    postgres-# from
    postgres-# lineitem_1t
    postgres-# where
    postgres-# l_shipdate <= date '1998-12-01' - interval '90 days'
    postgres-# group by
    postgres-# l_returnflag,
    postgres-# l_linestatus
    postgres-# ;
     l_returnflag | l_linestatus |   sum_qty   |   sum_base_price   |   sum_disc_price   | sum_charge |  avg_qty   | avg_price  |   avg_disc   | count_order
    --------------+--------------+-------------+--------------------+--------------------+--------------------+--------------------+- -------------------+----------------------+-------------
     R| F| 38663342979 |  57975227940306.44 |  55076481003328.08 |  57279552747411.33 | 25.500078164568315 |38237.067210909765 |   0.0499996887156784 |  1516204881
     A| F| 38663494247 |  57975897720343.05 |   55077056575228.5 |  57280139974700.35 | 25.499902314719474 |38237.09567046249 |  0.05000115197512918 |  1516221269
     N| O| 76132027266 | 114160174445769.75 | 108452120147030.16 | 112790257632072.62 | 25.500031386008317 |38237.36390505108 |  0.04999960482532665 |  2985566022
     N| F|  1009474721 | 1513655546292.8452 | 1437964915505.2053 | 1495505427205.7922 | 25.501252901992732 |38237.82021433879 | 0.050007751109846656 |39585299
    (4 rows)
    
    Time: 935449.207 ms (15:35.449)

   
# 结果对比 #

| 执行引擎类型 | 时间 |
| :-----:| :----: |
| ORCA | 340687.305 ms |
| JIT | 1625708.799 ms |
| 向量化 | 135449.207 ms |


**当数据量达到1TB的时候向量化引擎仍然是最快的，与ORCA相比依然有着2~3倍的提升，与JIT相比提升就更大了。所以从以上的测试可以看出KADB新增的向量化引擎大大提高了计算的效率，虽然目前还存在一些限制条件但是在未来，向量化引擎将大大提升数据库的性能。**


liuzhiliang2010
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
人大金仓KADB
m0_73245452的博客
04-20 415
它们不需要通过master进行数据库的备份恢复，每个segment和master并行备份/恢复自己的数据，这样master就不会再成为瓶颈，从而大幅提高备份/恢复的速度。所以这种方式更适合用在数据迁移的场景中.比如把postgre数据库（或者netezza）的数据迁移到greenplum中，或者在不同架构的KADB数据库间进行数据迁移，比如4节点的服务的数据，向8节点的服务迁移。对应pg_dump备份的结果，如果数据库出现故障，或者要进行数据移植，需要进行数据恢复，要使用工具pg_restore。
KADB学习之表管理
liuzhiliang2010的博客
12-26 918
分布式处理中将会存在本地和分布式协作的操作，当不同的表使用相同的分部键的时候，大部分的排序、连接关联操作工作将会在本地完成，本地操作往往比分布式操作快上5倍，但是采用随机分布的策略无法享受到这个优势。kadb采用的是分布存放数据的架构，有三种分布方式：distributed by (key)，采用的是hash算法，distributed randomly，采用的是随机算法；使用时间分区的时候建议采用最细粒度的平面分区而不是多层级的分区，平面分区有更佳的查询速度，多级分区有更好的查询计划分析时间。
KADB软件下载包.zip
08-24
包括服务器端安装包 KingbaseAnalyticsDB-3.0-同城双活操作指南 KingbaseAnalyticsDB-3.0-数据库性能调优指南.pdf
炫“库”行动-人大金仓有奖征文-金仓分析型数据库KADB的备份和恢复（一）-串行备份和恢复
liuzhiliang2010的博客
10-11 572
KADB 是北京人大金仓信息技术股份有限公司基于开源的greenplum数据库研发的一款分布式关系型数据库，全称是KingbaseAnalyticsDataBase。 作为一款分布式关系型数据库KADB提供了两种备份工具：一种是pg_dump，另一种是gpbackup。 pg_dump是从postgresql继承过来的工具，它只能通过MASTER节点采用串行方式备份数据库。 具体的参数说明可以通过执行 pg_dump --help获取 用法: pg_dump [OPTION]... [..
专治无耻的tadb.exe，kadb.exe等各种XXXadb.exe
lsmfeixiang的专栏
12-28 3682
这是一篇我个人在EOE发的blog《专治无耻的tadb.exe，kadb.exe等各种XXXadb.exe》，由于eoe的blog系统实在是无言以对，我就把eoe上面的帖子以及blog是都转到csdn上来，原帖地址：http://www.eoeandroid.com/blog-781265-47967.html 用自己电脑想学点东西，但是adb进程总是被各种xxxadb.exe进程抢占，
云数据库方案设计(1).doc
01-08
云数据库方案设计 云数据库的云化改造 面向云化环境，数据库在多个方面需要进行改造，包括快捷的安装部署，提供数据 库的动态伸缩和资源隔离，以及监控、迁移、备份等一体化管理，以适应云环境中自动 安装部署、一体...
云数据库方案设计.doc
01-08
云数据库方案设计 云数据库的云化改造 面向云化环境，数据库在多个方面需要进行改造，包括快捷的安装部署，提供数据 库的动态伸缩和资源隔离，以及监控、迁移、备份等一体化管理，以适应云环境中自动 安装部署、一体...
国产数据库替代案例PPT
02-18
新疆农信选择人大金仓的KADB，解决了原有Netezza架构在处理高密度、结构化数据批量分析和流水型业务时的性能和服务问题。此外，中国银行采用TiDB替换MySQL，利用其API规避压力，实现了10000+指标数量、18TB数据量和...
云数据库方案设计.docx
07-12
- 多种部署方式：支持单机、主备、负载均衡以及KADB集群部署。通过外部配置文件映射，根据用户需求自动规划配置内容，实现灵活的集群部署。 2. **在线伸缩** - 云数据库应支持在线资源调整，如CPU、内存、磁盘。...
金仓分析型数据库KADB使用建议
littlegirll的专栏
09-18 329
例如：在分析场景下，事实表一般记录对象的基本信息，有几十个属性，是个宽表（车牌号码、车型、发动机号码、底盘号码、使用单位、责任人、加油卡号、保险公司、路桥费缴纳日期、二保时间、车类型、上传照片），我们每次对车辆信息进行分析时，会考虑车辆信息事实表和省份这个维度进行关联分析，查询在某一省份中的车牌号码情况。因为相同数据类型的数据，其在数据格式，数据存储方式等方面的特性是一致的，那么就可以对应选择相应的压缩算法，对表的每一列可以选择不同的压缩算法达到最优的压缩比。索引选择度是一列中的唯一值数量除以表中的行数。
炫“库”行动-人大金仓有奖征文-金仓分析型数据库KADB管理节点主备节点的自动切换
liuzhiliang2010的博客
10-13 555
KADB是北京人大金仓信息技术股份有限公司基于开源的greenplum数据库研发的一款分布式关系型数据库，全称是KingbaseAnalyticsDataBase。 KADB采用的是MPP架构：包括两个管理节点(master)和若干计算节点(segment) 主要功能： 管理节点：集群入口，负责接受SQL和分配SQL操作以及负责协调整个集群 计算节点：存储数据，执行来自管理节点分配的操作任务 两个管理节点一主一备，由主管理节点提供服务，备节点做冷备，当主管理节点发生故障时，由备节...
KADB学习之常用函数
liuzhiliang2010的博客
12-19 426
是北京人大金仓信息技术股份有限公司基于开源的greenplum数据库研发的一款分布式关系型数据库，全称是KingbaseAnalyticsDataBase。1.6、时间戳加和减指定的年、月、天、时、分、秒数。1.4、时间加和减指定的小时、分钟、秒数。手动执行常用系统操作函数测试语句集；1.2、日期加和减指定年、月、天数。1.3、两个时间的加和减计算。1.1、两个日期的减计算。1.5、两个时间戳减计算。学习kadb的常用函数。一、创建测试表和数据。
炫“库”行动-人大金仓有奖征文-金仓分析型数据库KADB分区表的使用
liuzhiliang2010的博客
10-11 712
KADB 是北京人大金仓信息技术股份有限公司基于开源的greenplum数据库研发的一款分布式关系型数据库，全称是KingbaseAnalyticsDataBase。 分区表在KADB中一种重要的功能，一种好的分区策略可以通过只读取满足查询所需的分区来降低被扫描的数据量。每个分区在每一个计算节点上都是一个单独的物理文件或文件集合（这种情况出现在列寸表上）。就像在 宽列存表中读取一整行比从堆表读取同一行需要更多时间一样，在分区表中读取所有分区比从非分区表中读取相同 的数据要求更多的时间。同时KADB还可以利
KADB学习之表空间的使用
最新发布
liuzhiliang2010的博客
12-27 394
是北京人大金仓信息技术股份有限公司基于开源的greenplum数据库研发的一款分布式关系型数据库，全称是KingbaseAnalyticsDataBase。3,2、使用表空间（在表空间内创建测试表）3、手动执行DML测试语句集；1、在所有节点创建表空间目录。学习kadb的表空间的使用。2、连接测试数据库；
KADB集群问题调查分析
littlegirll的专栏
08-25 57
从每天的日志文件大小看，集群的一个segment实例一天产生的日志文件大小约为800GB，是导致集群数据目录空间使用过快的原因。上述命令打印126节点的/data目录下，master实例（对应数据目录：master），segment实例（对应数据目录：primary），master实例备份目录（master_backup）分别占用的空间大小。集群数据空间和日志空间共用一个数据目录、master实例和segment实例在节点上混合部署，导致日志占用数据的空间，master节点的备份信息占用数据的空间。
mysql调优：执行计划、optimizer_trace 查看执行流程、调优
SHOUGOUGOU的专栏
03-31 445
SQL执行计划 1、如何查看sql的执行计划 在需要执行的查询SQL前添加一个关键字“EXPLAIN” EXPLAIN中的列 （1）id 1、标识select所属的行，sql语句中有多少个select就有多少个id，并且id的顺序是按照select出现的顺序增长的 2、id越大，越先执行 3、id相同，从上往下执行 4、id为NUll的最后执行 (2) select_type 显示对应行是简单还是复杂select，SIMPLE值表明没有子查询或Union，如果有子查询，那么最.
Postgresql连接状况及优化
白开水的博客
12-23 2336
查看所有连接项目： select * from pg_stat_activity; 登录不上去时，可以选择kill掉idle的进程（不良反应上不可知） select pid from pg_stat_activity where state='idle' 性能优化主要选项 选项 默认值 说明 是否优化 原因 max_connections 100
教你sql分析OPTIMIZER_TRACE
qq_40021015的博客
12-22 731
optimizer_trace变量 1.通过SHOW VARIABLES LIKE ‘optimizer_trace’，可以看到变量的Value是enabled=off,one_line=off，即默认是禁止的。 2.enabled代表功能是否开启，one_line的值是控制输出格式的，如果为on那么所有输出都将在一行中展示。 3.通过语句SET optimizer_trace=“enabled=on”;来开启 4.OPTIMIZER_TRACE是表（表和变量，名字一样但是大小不一样），其是在informa
MySQL8.0 优化器介绍（一）
GreatSQL2021的博客
03-29 202
线上，遇到一些sql性能问题，需要手术刀级别的调优。optimizer_trace是一个极好的工具，已经有很多资料介绍optimizer_trace怎么使用与阅读。有必要再介绍一下我们平时不太能注意到，但是又对sql性能起着绝对作用的优化器。优化器是啥？在sql整个生命周期里处于什么样的位置，起到什么样的作用，cmu15445 课程(https://15445.courses.cs.cmu.edu/fall2022/notes/14-optimization.pdf)中对此有一些直观的描述。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值