Teradataで大規模なテーブルを作成するためのベストプラクティス

Question

私は変更しようとしている1億の行を持つテーブルを持っていますので、それを効果的に管理し、クエリできます。毎月、テーブルには約100万行の新しい行があります。 私はそれが正常に行を均等に分配し、範囲パーティションを正しく設定したと思っていましたが、その一つは日付ですが、現在の日付にテーブルを変更して新しいパーティションを追加しようとしたとき、

変更する必要があるかどうかわかりません。私の理解では、PIとパーティションに参加している各フィールドは索引を付ける必要があり、それらの索引や統計を維持するには時間と空間が必要ですが、解析エンジンの統計を収集する必要があります。

私はパーティションの変更を避けるために数年の範囲を延長することを考えましたが、Teradataはその習慣を推奨していないことも読んでいます。

他に何を試してください。

CREATE SET TABLE STAGE.PartD 
    DATABLOCKSIZE = 1048064 BYTES 
    (
     Efctv_uniq_id CHAR(13) NOT NULL, 
     Cntrct_num CHAR(5) NOT NULL COMPRESS ('H2407','H2416','H2417','H2419','H2422','H2425','H2450','H2456','H2457','H2458','H2459','H2462','H5703','S0522','S4802','S5597','S5601','S5617','S5644','S5660','S5743','S5768','S5803','S5810','S5820','S5884','S5921','S5932','S5960','S5967','S7694'), 
     Pbp_id SMALLINT NOT NULL COMPRESS (1 ,2 ,24 ,25 ,42 ,50 ,59 ,83 ,94 ,370 ,122 ,123 ,145 ,162 ,247), 
     Hicn VARCHAR(20) NOT NULL, 
     Cardhldr_id VARCHAR(20) COMPRESS '', 
     Ptnt_date_of_birth DATE FORMAT 'YY/MM/DD' COMPRESS , 
     Ptnt_gender_cd CHAR(1) NOT NULL COMPRESS ('0','1','2'), 
     Date_of_srvc DATE FORMAT 'YY/MM/DD' NOT NULL, 
     Paid_dt DATE FORMAT 'YY/MM/DD' COMPRESS , 
     Product_srvc_id VARCHAR(19) NOT NULL COMPRESS ('~','62175011843','00088222033'), 
     Srvc_prvdr_id_qlfyr CHAR(2) NOT NULL COMPRESS ('01','07','99'), 
     Srvc_prvdr_id VARCHAR(15) NOT NULL, 
     Fill_num BYTEINT NOT NULL COMPRESS (0 ,1 ,2 ,3 ,4 ,5 ,6 ,7 ,8 ,9 ,10 ,11 ,12 ,13 ,14), 
     Dspnsng_stus CHAR(1) NOT NULL COMPRESS ' ', 
     Cmpnd_cd CHAR(1) COMPRESS '1', 
     Daw_prod_slctn_cd CHAR(1) COMPRESS '0', 
     Qty_dspnsd CHAR(10) NOT NULL COMPRESS ('0000004000','0000010000','0000014000','0000015000','0000020000','0000028000','0000030000','0000031000','0000045000','0000056000','0000060000','0000090000','0000100000','0000120000','0000180000'), 
     Days_suply SMALLINT COMPRESS (0 ,3 ,5 ,7 ,10 ,14 ,15 ,20 ,25 ,28 ,30 ,31 ,34 ,90), 
     Prscrb_id_qlfyr CHAR(2) COMPRESS (' ','01','12'), 
     Prscrb_id VARCHAR(15) NOT NULL COMPRESS '', 
     Drug_cvrg_stus_cd CHAR(1) COMPRESS (' ','C','E','O'), 
     Adjsmt_del_cd CHAR(1) COMPRESS (' ','A','D'), 
     Non_stand_frmt_cd CHAR(1) COMPRESS (' ','B','C','X'), 
     Prcng_excptn_cd CHAR(1) COMPRESS (' ','M','O'), 
     Uniq_id CHAR(13) NOT NULL, 
     FinalVersionInd CHAR(1), 
     LoadID SMALLINT NOT NULL) 
PRIMARY INDEX pi (Efctv_uniq_id ,LoadID) 
PARTITION BY (RANGE_N(LoadID BETWEEN 1 AND 10000 EACH 1), 
          RANGE_N(Date_of_srvc BETWEEN DATE '2007-01-01' AND ADD_MONTHS((DATE),(-1)) EACH INTERVAL '1' MONTH)) 
UNIQUE INDEX ui (Efctv_uniq_id ,LoadID) 
INDEX Efctv_uniq_id (Efctv_uniq_id) 
INDEX Date_of_srvc (Date_of_srvc) 
INDEX LoadID (LoadID); 

ステージング環境でUIが必要なので、同じデータが2回以上読み込まれることはありません。私はその環境の中でテーブルからそのインデックスを取り出しました。

avgCurrentPermは722027691、maxPeakPermは730772992、skewFactorは0.094412です。

ありがとうございました。

PRIMARY INDEX pi (Efctv_uniq_id ,LoadID) 
PARTITION BY ( 
RANGE_N(LoadID BETWEEN 644 AND 10000 EACH 1), 
RANGE_N(Date_of_srvc BETWEEN DATE '2007-01-01' AND DATE '2030-01-01' 
EACH INTERVAL '1' MONTH)); 

シーイング： avgCurrentPerm 377035904 maxPeakPerm 377372160 skewFactor 0.089105

及びこれらの統計情報を収集：

COLLECT STATS 
COLUMN (PARTITION), 
COLUMN (loadid), 
COLUMN (Efctv_uniq_id), 
COLUMN (Date_of_srvc) 
ON STAGE.PartD; 

---

---

はそれを変更しました210と私は、現在の日付を使用してユニークなインデックスとパーティションの範囲を作成することは悪い考えであるという印象を受けていますか？

Answer 1

私の理解では、各フィールドがPIに参加し、 パーティションが

ハズレをインデックス化する必要があり、パーティショニング/ PIカラムの追加インデックスが役に立たないということです。

また、INSERT/UPDATEではなくMERGEに切り替えると、USIは必要ありません。

最後に、より良いADDのRANGE避けるために、2030年までDate_of_srvcを定義します（テーブルの変更を実行するための推奨を取得したのですか？）