<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          數(shù)倉(cāng)調(diào)優(yōu)|阿里資深技術(shù)專家數(shù)倉(cāng)調(diào)優(yōu)經(jīng)驗(yàn)分享(下)

          共 5346字,需瀏覽 11分鐘

           ·

          2021-11-14 08:22


          隨著云原生數(shù)據(jù)倉(cāng)庫(kù)AnalyticDB for MySQL(下文統(tǒng)一簡(jiǎn)稱:AnalyticDB)在阿里集團(tuán)各個(gè)業(yè)務(wù)線、社會(huì)上各行各業(yè)的推廣應(yīng)用,我們沉淀了一些最佳實(shí)踐,現(xiàn)在筆者整理在這里,供大家參考,希望對(duì)大家有幫助。本篇文章總結(jié)了AnalyticDB表的設(shè)計(jì)的最佳經(jīng)驗(yàn)、數(shù)據(jù)寫(xiě)入的最佳經(jīng)驗(yàn)、高效查詢的最佳實(shí)踐,以及一些常見(jiàn)的問(wèn)題。

          說(shuō)明:
          1.在閱讀這篇文章之前,歡迎點(diǎn)擊“閱讀原文”了解AnalyticDB的產(chǎn)品官方文檔,以提前適當(dāng)了解AnalyticDB;
          2.本文寫(xiě)的最佳實(shí)踐主要針對(duì)AnalyticDB3.0,AnalyticDB2.0在原理上也同樣適用;
          3.本文是全網(wǎng)首發(fā)|阿里資深技術(shù)專家數(shù)倉(cāng)調(diào)優(yōu)經(jīng)驗(yàn)分享(上)的后續(xù)內(nèi)容,第一次關(guān)注的讀者歡迎先閱讀上篇。



          05 業(yè)務(wù)行業(yè)線上的最佳實(shí)踐

          (一)營(yíng)銷業(yè)務(wù)使用場(chǎng)景


          隨著互聯(lián)網(wǎng)流量成本的增加,花大價(jià)錢(qián)砸流量的時(shí)代成為歷史,客戶廣告營(yíng)銷越來(lái)越講究精細(xì)化運(yùn)營(yíng),越來(lái)越依賴對(duì)已有的客戶數(shù)據(jù)做實(shí)時(shí)的、精準(zhǔn)的分析,提高廣告的轉(zhuǎn)化率。在對(duì)人群的營(yíng)銷方面,一般存在以下典型的場(chǎng)景:


          典型的系統(tǒng)架構(gòu):

          核心表建表語(yǔ)句如下:

          CREATE?TABLE?db.order (
          ??order_id,
          ??user_id,
          ??shop_vip,
          ??last_trade_time,
          ??last_cart_time,
          ??member_grade,
          ??seller_zone,
          ??member_credits,
          ??clustered key?index_mmsi(`user_id`)
          )
          DISTRIBUTED?BY?HASH(order_id)
          PARTITION?BY?VALUE(DATE_FORMAT(last_trade_time, '%Y%m%d')) LIFECYCLE 30
          COMMENT?'訂單信息表';

          備注:采用order_id作為分布鍵,確保數(shù)據(jù)均勻分布,不會(huì)出現(xiàn)傾斜。同時(shí)由于需要頻繁的按照user_id查詢或者關(guān)聯(lián),將user_id用作聚集索引。


          1.人群透視


          人群透視是指根據(jù)用戶的各種標(biāo)簽,來(lái)選取特定的人群。通常情況下,以用戶或者用戶行為的表作為事實(shí)表,用戶的各類標(biāo)簽/屬性作為維度表,采用星型模型,用事實(shí)表來(lái)JOIN各個(gè)維度表,做多維分析(有時(shí)也可能會(huì)采用數(shù)據(jù)冗余的反范式方式,以犧牲數(shù)據(jù)存儲(chǔ)為代價(jià),將事實(shí)表構(gòu)建為一張大寬表,目的是省去分析時(shí)的多表關(guān)聯(lián))。正是因?yàn)橛脩舴治鰳?biāo)簽的不確定性,采用傳統(tǒng)的數(shù)據(jù)庫(kù)(傳統(tǒng)數(shù)據(jù)庫(kù)的索引是不能無(wú)限制的創(chuàng)建的)是無(wú)法做到這種不定維度的分析的,那么AnalyticDB就是解決該類問(wèn)題的最佳方案。典型的SQL如下:

          SELECT
          ??t2.buyer_id,
          ??t3.seller_id,
          ??t1.shop_vip,
          ??t1.last_trade_time,
          ??t1.last_cart_time,
          ??t1.member_grade,
          ??t1.seller_zone,
          ??t1.member_credits,
          ??sum(t1.pay_amount)
          FROM
          ??db.order t1
          ??JOIN?db.dimension_table1 t2 ON?t1.user_id= t2.buyer_id
          ??JOIN?db.dimension_table2 t3 ON?t1.user_id= t3.seller_id
          WHERE
          ??t1.is_market_target IN('4')
          ??AND?t1.seller_zone = 1019
          ??AND?t1.attributes IN('6742081')
          ??AND?t3.buyer_id = ‘xxxx’
          ??and?t3.tseller_id = ‘yyyy’
          group?by
          ??t2.buyer_id,
          ??t3.seller_id,
          ??t1.shop_vip,
          ??t1.last_trade_time,
          ??t1.last_cart_time,
          ??t1.member_grade,
          ??t1.seller_zone,
          ??t1.member_credits;

          其中的order表可能是萬(wàn)億級(jí)別,巨量數(shù)據(jù)的多維、多表關(guān)聯(lián)在線實(shí)時(shí)分析對(duì)底層分析系統(tǒng)的能力要求極高。


          2.人群圈選


          人群圈選和人群透視類似,更多的時(shí)候可能是圈選具體的人群數(shù)量,而不是具體的明細(xì)數(shù)據(jù),這時(shí)更多使用到AnalyticDB的聚合計(jì)算能力,即根據(jù)各個(gè)不定的維度進(jìn)行COUNT DISTINCT或者GROUP BY的操作。典型的SQL語(yǔ)句如下:

          SELECT?count(1) AS?cnt
          ??FROM(
          SELECT?DISTINCT?t1.buyer_id
          ??FROM(
          SELECT?buyer_id
          ??FROM?db.order
          ?WHERE?seller_zone= 11111
          ???AND?seller_id= 121211121
          ???AND?algorithm_crowd IN('84')) t1
          ?JOIN(
          SELECT?user_id AS?buyer_id
          ??FROM?db.dimension_table1) t2
          ??????ON?t1.buyer_id= t2.buyer_id
          JOIN(
          SELECT?user_id AS?seller_id
          ??FROM?db.dimension_table2) t3
          ??????ON?t1.buyer_id= t3.seller_id
          ) t;

          3.人群投放

          人群投放是指按照一定的促銷渠道,將營(yíng)銷信息投放到上面圈選的人群中,比如短信投放、門(mén)戶網(wǎng)站的廣告投放等。不同渠道的數(shù)據(jù)可以使用不同OSS來(lái)存放,而AnalyticDB可以方便地將庫(kù)內(nèi)數(shù)據(jù)Dump到OSS或者其他的下游產(chǎn)品上,而且Dump的效率非常高,很好地提高了用戶人群投放的效率。在ADB2.0中的典型SQL如下:

          CREATE?TABLE?output?WITH(oss_dump_endpoint= 'xxxxxx.oss-internal.aliyun-inc.com', oss_dump_bucket_name= 'xxxx',
          ?????????????????????????oss_dump_file_name= 'xx_prod/20190710/63218721',
          ?????????????????????????oss_dump_is_overwrite= true,
          ?????????????????????????oss_dump_compatibility_mode= false,
          ?????????????????????????oss_dump_access_key_id= 'xxxxxxxxx',
          ?????????????????????????oss_dump_access_key_secret= 'xxxxxxxxxxxxxxxxxxxx',
          ?????????????????????????oss_dump_row_del= '\r\n',
          ?????????????????????????oss_dump_col_del= '\t', table_type= 'oss_dump', dump_charset_code= 'UTF-8',
          ?????????????????????????oss_dump_table_header= 'false', return_dump_result_count= true) as
          SELECT?DISTINCT?t1.buyer_id
          ??FROM(
          SELECT?buyer_id
          ??FROM?db.order
          ?WHERE?last_cart_time>= 20190610
          ???AND?last_cart_time< 20190710
          ???AND?is_market_target IN('1')
          ???AND?seller_zone= 1018
          ???AND?seller_id= 3687815378) t1
          JOIN(
          SELECT?user_id AS?buyer_id
          ??FROM?db.dimension_table) t2
          ON?t1.buyer_id= t2.buyer_id
          LIMIT?1000;

          (二)監(jiān)控大屏類場(chǎng)景

          由于AnalyticDB支持實(shí)時(shí)寫(xiě)入,而且實(shí)時(shí)寫(xiě)入的數(shù)據(jù)又能進(jìn)行比較復(fù)雜的實(shí)時(shí)分析,因此在一些監(jiān)控大屏、監(jiān)控大盤(pán)、實(shí)時(shí)看板等場(chǎng)景中有著非常廣泛的應(yīng)用。
          典型的系統(tǒng)架構(gòu)如下:


          上游生產(chǎn)數(shù)據(jù)通過(guò)Flink、DTS、精衛(wèi)或者Dataworks等工具實(shí)時(shí)寫(xiě)入到AnalyticDB中,在AnalyticDB中進(jìn)行實(shí)時(shí)在線分析,然后在報(bào)表展現(xiàn)工具做大屏顯示。

          該類的業(yè)務(wù),對(duì)數(shù)據(jù)的時(shí)效要求很高,特別是對(duì)數(shù)據(jù)的實(shí)時(shí)寫(xiě)入要求很高,不僅實(shí)時(shí)寫(xiě)入的數(shù)據(jù)量大,且要求寫(xiě)入后實(shí)時(shí)可見(jiàn),還要能快速地分析。因此在表的設(shè)計(jì)時(shí)要特別注意。本文總結(jié)了此類場(chǎng)景的幾點(diǎn)注意事項(xiàng):

          • 表要設(shè)置主鍵。主鍵用于排重,一旦有重復(fù)的數(shù)據(jù)寫(xiě)入可以直接覆蓋,參考之前上篇:全網(wǎng)首發(fā)|阿里資深技術(shù)專家數(shù)倉(cāng)調(diào)優(yōu)經(jīng)驗(yàn)分享(上)。
          • 表要設(shè)計(jì)二級(jí)分區(qū)。一來(lái)該類數(shù)據(jù)往往量比較大,需要采用二級(jí)分區(qū)做數(shù)據(jù)的生命周期管理,自動(dòng)淘汰過(guò)期的數(shù)據(jù);二是實(shí)時(shí)寫(xiě)入的數(shù)據(jù)可以根據(jù)二級(jí)分區(qū)來(lái)構(gòu)建索引,這樣只需要增量數(shù)據(jù)構(gòu)建索引,大大提高了構(gòu)建索引的效率,有了索引后,數(shù)據(jù)的查詢也就能快很多。
          • 在特別大量的數(shù)據(jù)寫(xiě)入情況下,往往CPU的消耗也比較厲害,需要合理控制構(gòu)建索引任務(wù)的并發(fā)度和時(shí)間,以避免和大流量寫(xiě)入峰值重合,而加重對(duì)實(shí)時(shí)寫(xiě)入的影響。

          典型的SQL如下:

          CREATE?TABLE?tb__record_info
          (
          ??a_info_id bigint?NOT?NULL?AUTO_INCREMENT,
          ??domain?varchar?NOT?NULL,
          ??region varchar?NOT?NULL,
          ??ip varchar?NOT?NULL,
          ??result_ts varchar?NOT?NULL,
          ??time_stamp timestamp?NOT?NULL?DEFAULT?CURRENT_TIMESTAMP?ON?UPDATE?CURRENT_TIMESTAMP,
          ??key?idx_domain(domain),
          ??key?idx_time(time_stamp),
          ??primary key?(a_info_id, domain, time_stamp)
          )
          DISTRIBUTE?BY?HASH(domain)
          PARTITION?BY?VALUE(DATE_FORMAT(time_stamp,'%Y%m%d')) LIFECYCLE 60;


          (三)游戲行業(yè)的使用場(chǎng)景


          游戲領(lǐng)域的競(jìng)爭(zhēng)變得更加激烈,在互聯(lián)網(wǎng)高速增長(zhǎng)的同時(shí),流量成本不斷升高,市場(chǎng)營(yíng)銷開(kāi)始往精細(xì)化發(fā)展。游戲廠商對(duì)于渠道、用戶和游戲表現(xiàn)的評(píng)估需要更加細(xì)化和準(zhǔn)確的數(shù)據(jù),希望利用優(yōu)秀的數(shù)據(jù)分析工具來(lái)幫助團(tuán)隊(duì)更全面的分析市場(chǎng)和用戶的趨勢(shì),同時(shí)玩家的游戲行為和喜好也在慢慢變化,如何能夠及時(shí)發(fā)現(xiàn)這些變化并針對(duì)性的調(diào)整產(chǎn)品和游戲設(shè)計(jì)也是非常重要的,因此提出了如下業(yè)務(wù)要求:

          • 提供全面的游戲運(yùn)營(yíng)指標(biāo)分析功能:全面提高游戲開(kāi)發(fā)者的日常數(shù)據(jù)運(yùn)營(yíng)工作效率,不僅提供付費(fèi)用戶、付費(fèi)率、付費(fèi)金額和ARPU等運(yùn)營(yíng)指標(biāo),還強(qiáng)化了付費(fèi)用戶的留存率、回訪率、用戶生命周期價(jià)值等更加精細(xì)化的運(yùn)營(yíng)指標(biāo),游戲開(kāi)發(fā)者可以更加深入,更加有效率地掌握游戲運(yùn)營(yíng)狀態(tài)。
          • 提供有效的渠道效果分析,使每分錢(qián)都花在刀刃上:實(shí)時(shí)的分渠道數(shù)據(jù)統(tǒng)計(jì)可以監(jiān)測(cè)到不同渠道用戶的增長(zhǎng)、活躍、留存狀況以及充值狀況,更加全面、快速地分析出投資回報(bào)率,讓開(kāi)發(fā)者對(duì)渠道的評(píng)估更加準(zhǔn)確。
          • 針對(duì)付費(fèi)用戶追蹤分析,了解付費(fèi)用戶的習(xí)慣:針對(duì)付費(fèi)用戶群,通過(guò)簡(jiǎn)單易懂的數(shù)據(jù)分析模型和圖表,跟蹤付費(fèi)用戶的留存、流失、回訪和充值數(shù)據(jù),更好地反映付費(fèi)用戶在整個(gè)生命周期的關(guān)鍵行為和價(jià)值。
          • 細(xì)致分析玩家游戲行為,改進(jìn)產(chǎn)品體驗(yàn),提高游戲收益:關(guān)卡、道具、消費(fèi)行為分析的功能可以了解道具和物品在使用過(guò)程中使用和消耗的總量以及趨勢(shì),開(kāi)發(fā)者可以借此來(lái)做到恰到好處的數(shù)值平衡設(shè)計(jì),也可充分利用數(shù)據(jù)分析的結(jié)果優(yōu)化游戲內(nèi)付費(fèi)商品的收益。

          AnalyticDB可以支持如下典型場(chǎng)景。


          1.活躍分析


          游戲產(chǎn)品日活DAU/月活MAU等均為評(píng)價(jià)該款游戲是否被玩家廣泛接受的一個(gè)非常重要的指標(biāo)。


          DAU計(jì)算的SQL示例如下:

          SELECT?count(DISTINCT?uid) AS?count?
          FROM?login_log
          WHERE?timestamp?>=
          AND?timestamp???<=
          AND?qita1 =
          AND?qita2 = ;

          基于上述的基本統(tǒng)計(jì),可以對(duì)玩家的活躍狀態(tài)做更多的探索,比如:
          • 活躍賬號(hào)分析
            • 按照日期分析,常見(jiàn)的DAU/WAU/MAU等
            • 按照渠道分析,比如分包渠道或者廣告渠道等
          • 在線分析
            • 平均在線玩家數(shù)
            • 峰值在線玩家數(shù)
          • 玩家行為分析
            • 人均游戲次數(shù),即所選日期內(nèi),總游戲次數(shù) / 游戲人數(shù)(該數(shù)值無(wú)法完全精確統(tǒng)計(jì),僅供參考)
            • 人均游戲時(shí)長(zhǎng)分析等


          2.來(lái)源分析


          游戲玩家來(lái)源分析里面,新增設(shè)備分析用來(lái)預(yù)測(cè)該款游戲的生命周期和拉新效率等,也是評(píng)價(jià)該款游戲是否被玩家廣泛接受的一個(gè)非常重要的指標(biāo)。


          新增設(shè)備、新增玩家等計(jì)算的SQL示例如下:

          SELECT?Count(*) AS?count?FROM??
          (
          ????SELECT?deviceid
          ????FROM?login_log
          ????WHERE??channel_id = ‘X’
          ????AND?timestamp?>= ‘XXX’
          ????AND?timestamp?<= ‘YYY’
          ????GROUP??BY?deviceid
          ) AS?d1
          ????LEFT?JOIN?
          (
          ????SELECT?deviceid
          ????FROM???login_log
          ????WHERE??channel_id = ‘X’
          ????AND?timestamp?< ‘YYY’
          ) AS?d2
          ON?d1.deviceid = d2.deviceid
          WHERE??d1.deviceid IS?NULL;


          3.留存分析


          留存指標(biāo)在某些方面反映了游戲產(chǎn)品的質(zhì)量和保留玩家的能力,也在另一方面反映了渠道與游戲目標(biāo)用戶的契合度及渠道質(zhì)量。所以對(duì)留存指標(biāo)的分析顯得更為重要。


          玩家留存率等計(jì)算的SQL示例如下:

          SELECT
          ??channel_id,
          ??count(
          ????DISTINCT?IF?(
          ??????datediff(payorder_riqi, login_riqi) = 0,
          ??????user_id,
          ??????NULL
          ????)
          ??) AS?'liucun_1',
          ??count(
          ????DISTINCT?IF?(
          ??????datediff(payorder_riqi, login_riqi) = 1,
          ??????user_id,
          ??????NULL
          ????)
          ??) AS?'liucun_2',
          ??count(
          ????DISTINCT?IF?(
          ??????datediff(payorder_riqi, login_riqi) = 2,
          ??????user_id,
          ??????NULL
          ????)
          ??) AS?'liucun_3',
          ??count(
          ????DISTINCT?IF?(
          ??????datediff(payorder_riqi, login_riqi) = 3,
          ??????user_id,
          ??????NULL
          ????)
          ??) AS?'liucun_4',
          ??count(
          ????DISTINCT?IF?(
          ??????datediff(payorder_riqi, login_riqi) = 4,
          ??????user_id,
          ??????NULL
          ????)
          ??) AS?'liucun_5',
          ??count(
          ????DISTINCT?IF?(
          ??????datediff(payorder_riqi, login_riqi) = 5,
          ??????user_id,
          ??????NULL
          ????)
          ??) AS?'liucun_6',
          ??count(
          ????DISTINCT?IF?(
          ??????datediff(payorder_riqi, login_riqi) = 6,
          ??????user_id,
          NULL
          ????)
          ??) AS?'liucun_7',
          ??count(
          ????DISTINCT?IF?(
          ??????datediff(payorder_riqi, login_riqi) = 14,
          ??????user_id,
          ??????NULL
          ????)
          ??) AS?'liucun_15'
          FROM
          ??pay_order p
          ??LEFT?JOIN?login_log l ON?p.uid = l.uid
          WHERE
          ??payorder_riqi >= '2019-01-17'
          ??AND?payorder_riqi <= '2019-01-24'
          GROUP?BY
          ??`channel_id`
          ORDER?BY
          ??`liucun_1`?DESC;



          06? FAQ


          1.磁盤(pán)占用大小包含哪些數(shù)據(jù)?為什么會(huì)觸發(fā)磁盤(pán)滿鎖定?

          磁盤(pán)占用量主要包括數(shù)據(jù)和索引兩部分。
          索引在構(gòu)建過(guò)程中,會(huì)臨時(shí)額外占用少量空間,期間可能會(huì)有少量數(shù)據(jù)膨脹。
          用戶可以使用如下SQL語(yǔ)句查詢磁盤(pán)占用量(說(shuō)明:該指標(biāo)是延遲統(tǒng)計(jì)的,每小時(shí)統(tǒng)計(jì)一次):SELECT (SUM(data_length)+SUM(index_length))/1024/1024/1024 AS '數(shù)據(jù)空間(GB)' FROM information_schema.tables;用戶還可以使用如下SQL語(yǔ)句查詢當(dāng)前日志占用空間:show binary logs返回結(jié)果中的adb-bin.log表示binlog,adb-system.log表示系統(tǒng)日志。
          當(dāng)單節(jié)點(diǎn)磁盤(pán)使用量超過(guò)80%則會(huì)觸發(fā)鎖定。
          單節(jié)點(diǎn)磁盤(pán)使用量過(guò)高可能有兩種原因:一是一級(jí)分區(qū)鍵選擇不合理導(dǎo)致某些節(jié)點(diǎn)數(shù)據(jù)傾斜;二是數(shù)據(jù)分布比較平均,總體使用量過(guò)大。用戶可以根據(jù)控制臺(tái)頁(yè)面的存儲(chǔ)水位判斷是否存在表分區(qū)傾斜。

          2.是否支持磁盤(pán)大小擴(kuò)縮,是否支持節(jié)點(diǎn)數(shù)擴(kuò)縮?節(jié)點(diǎn)數(shù)擴(kuò)縮需要多久?

          目前磁盤(pán)使用ECS云盤(pán),只支持?jǐn)U容。節(jié)點(diǎn)數(shù)支持?jǐn)U縮,數(shù)量范圍與實(shí)例初始規(guī)格相關(guān),控制臺(tái)變配頁(yè)面可以看到當(dāng)前實(shí)例節(jié)點(diǎn)數(shù)變配范圍。節(jié)點(diǎn)數(shù)擴(kuò)縮會(huì)在節(jié)點(diǎn)間進(jìn)行部分?jǐn)?shù)據(jù)遷移。

          3.如何進(jìn)一步提高寫(xiě)入性能?

          盡可能使用批量寫(xiě)入的方式;使用Dataworks進(jìn)行數(shù)據(jù)同步時(shí),注意并發(fā)任務(wù)數(shù)和寫(xiě)入批大小是否過(guò)??;盡可能精簡(jiǎn)地設(shè)置主鍵;盡可能均衡地選擇寫(xiě)入表的分區(qū)鍵。

          4.如何選擇合適的一級(jí)分區(qū)鍵?

          AnalyticDB內(nèi)部將數(shù)據(jù)拆分為若干個(gè)一級(jí)分區(qū),通常情況下一個(gè)AnalyticDB實(shí)例內(nèi)部大概有100數(shù)量級(jí)左右的一級(jí)分區(qū)。在進(jìn)行查詢時(shí)不同的一級(jí)分區(qū)并發(fā)進(jìn)行。因此一級(jí)分區(qū)鍵最重要的一點(diǎn)是需要保證數(shù)據(jù)盡可能的均勻,否則會(huì)出現(xiàn)長(zhǎng)尾查詢,拖慢整體查詢進(jìn)度。
          不同的表如果一級(jí)分區(qū)鍵相同,那么這些表在執(zhí)行以一級(jí)分區(qū)鍵為Join Key的JOIN時(shí)可以大幅度減少數(shù)據(jù)Shuffle。因此在保證數(shù)據(jù)均勻的前提下,相同的一級(jí)分區(qū)鍵可以加速JOIN。

          5.如何選擇合適的二級(jí)分區(qū)鍵?

          二級(jí)分區(qū)是對(duì)一級(jí)分區(qū)的進(jìn)一步拆分,一般是在時(shí)間維度上進(jìn)行。但是不建議二級(jí)分區(qū)分的太多,建議單表二級(jí)分區(qū)數(shù)量不要超過(guò)100個(gè)。假設(shè)一張訂單表單天增量百萬(wàn)左右,需要保留10年的數(shù)據(jù)。由于一個(gè)AnalyticDB集群,通常情況下,有大約100個(gè)一級(jí)分區(qū)。若該表按日進(jìn)行分區(qū),則單個(gè)二級(jí)分區(qū)的數(shù)據(jù)量大小約為1萬(wàn)左右,遠(yuǎn)低于我們的建議值。因此用月或者年作為二級(jí)分區(qū)比較合適。
          AnalyticDB支持修改二級(jí)分區(qū)的生命周期。示例ALTER TABLE lineitem PARTITIONS 12表示將lineitem的二級(jí)分區(qū)個(gè)數(shù)修改為12。需要注意的是,二級(jí)分區(qū)個(gè)數(shù)的修改是后臺(tái)異步執(zhí)行的,執(zhí)行BUILD TABLE lineitem可以加速分區(qū)修改任務(wù)。

          6.二級(jí)分區(qū)的過(guò)期策略是怎樣的?

          目前二級(jí)分區(qū)的過(guò)期策略是,依據(jù)大小排序,只保留最大的N個(gè)二級(jí)分區(qū),其余分區(qū)將會(huì)被淘汰,其中N為生命周期的大小。假設(shè)表A當(dāng)前擁有3個(gè)二級(jí)分區(qū),分別是202001、202002、202003,其生命周期個(gè)數(shù)為3,那么,當(dāng)分區(qū)值為202004的數(shù)據(jù)寫(xiě)入時(shí),202001分區(qū)就會(huì)被淘汰。需要注意的是分區(qū)淘汰是異步執(zhí)行的,如果需要盡快把過(guò)期的二級(jí)分區(qū)淘汰掉,可以通過(guò)執(zhí)行 build table ?table_name 的方式觸發(fā)過(guò)期的二級(jí)分區(qū)淘汰機(jī)制。
          此外在使用二級(jí)分區(qū)時(shí)也要注意臟數(shù)據(jù)帶來(lái)的誤淘汰問(wèn)題,如果此時(shí)表A分別寫(xiě)入了分區(qū)值為300001、300002、300003的三條臟數(shù)據(jù),那么分區(qū)淘汰策略也會(huì)被觸發(fā),整表將只剩下分區(qū)值最大的三條臟數(shù)據(jù)。

          7.聚集索引是什么,什么情況下適合使用聚集索引?

          聚集索引就是讓數(shù)據(jù)根據(jù)若干字段進(jìn)行排序。通過(guò)排序,將值相同或者相近的數(shù)據(jù)在物理上存儲(chǔ)在一起。
          如果查詢一定會(huì)帶有某個(gè)字段,比如電商賣家透視平臺(tái)
          賣家id就可以為聚集索引,保證數(shù)據(jù)的Locality
          ,進(jìn)而讓性能得到量級(jí)的提升。
          目前只支持一個(gè)聚集索引,但一個(gè)聚集索引可以包含多列。目前除非對(duì)非常分散的數(shù)據(jù)進(jìn)行點(diǎn)查,否則聚集索引對(duì)性能的幫助很少。

          8.主鍵如何選擇,是否能夠修改主鍵?

          主鍵一般用于數(shù)據(jù)的去重。主鍵的長(zhǎng)度與去重的效率成反比,因此非常不建議使用較長(zhǎng)的String,建議使用1~3個(gè)長(zhǎng)整型字段作為主鍵。
          此外需要注意的是,主鍵需要包含一級(jí)分區(qū)鍵和二級(jí)分區(qū)鍵。目前不支持主鍵的修改。

          9.如何自己指定索引?

          AnalyticDB默認(rèn)是全字段索引,一般不需要自己維護(hù)索引。
          查看表索引的方法:SHOW INDEX FROM tablename如果想要刪除某個(gè)索引可以使用:ALTER TABLE tablename DROP KEY keyname。其中keyname可以通過(guò)上面的語(yǔ)句查詢。注意:刪除索引可能會(huì)導(dǎo)致查詢變慢。
          如果想要自己指定索引,使用KEY關(guān)鍵字:KEY key_name (column_name)。例如:CREATE TABLE tablename (id bigint,c1 varchar,key id_idx(id)) DISTRIBUTE BY HASH(id);。

          10.直接用MySQL的建表DDL可以在AnalyticDB中執(zhí)行建表嗎?

          可以,具體行為是這樣的:

          如果DDL中有主鍵,用主鍵作Distribute Key。

          如果DDL中沒(méi)有主鍵,會(huì)自動(dòng)創(chuàng)建一個(gè)字段__adb_auto_id__,然后使用__adb_auto_id__作主鍵和分區(qū)鍵。


          11.可以直接在AnalyticDB 3.0中執(zhí)行AnalyticDB 2.0的建表語(yǔ)句嗎?

          可以,AnalyticDB 3.0已經(jīng)兼容了AnalyticDB 2.0的建表語(yǔ)句。



          推薦閱讀

          全網(wǎng)首發(fā)|阿里資深技術(shù)專家數(shù)倉(cāng)調(diào)優(yōu)經(jīng)驗(yàn)分享(上)

          重磅發(fā)布|云原生數(shù)據(jù)倉(cāng)庫(kù)AnalyticDB技術(shù)架構(gòu)升級(jí),大幅降低存儲(chǔ)成本


          點(diǎn)擊“閱讀原文”查看AnalyticDB更多信息

          瀏覽 43
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          評(píng)論
          圖片
          表情
          推薦
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  六月婷婷六月 | 97色婷婷五月 | 亚洲最新视频在线免费播放不卡网站 | 时逼高清视频免费少妞 | 婷婷丁香五月小说 |