69成人网,丝袜美腿诱惑,成人做爰视频www免费看网站

第一部分：字符集規范

【強制】數據庫字符集指定utf-8，并且只支持utf-8。

命令規范

【建議】庫名統一使用小寫方式，中間用下劃線（_）分割，長度62字節內
【建議】表名稱大小寫敏感，統一使用小寫方式，中間用下劃線（_）分割，長度64字節內

第二部分：建表規范

【強制】確保每個tablet大小為1-3G之間。舉例：假設表內單分區數據量在100G，按天分區,bucket數量100個。
【強烈建議】不要使用Auto Bucket ，按照自己的數據量來進行分區分桶，這樣你的導入及查詢性能都會得到很好的效果，Auto Bucket 會造成 tablet 數量過多，造成大量小文件的問題。
【強制】 5 億以上的數據必須設置分區分桶策略
1. 維度表：緩慢增長的，可以使用單分區，在分桶策略上使用常用查詢條件（這個字段數據分步相對均衡）分桶，
  1. 100M以內：1 buckets
  2. 100M-1G ：3-5 個 Buckets
  3. 大于1G-3G ： 5-7個 buckets
  4. 3-5G ： 7-10 個 buckets
2. 事實表
  1. 沒有辦法分區的，數據又緩慢增長的：單個tablet數據量保持在1-3G；比如5億數據大小在20G，bucket數量給20個
  2. 沒有辦法分區的，數據又較快增長的，沒辦法按照時間動態分區，可以適當放大一下你的bucket數量，按照你的數據保存周期（180天）數據總量，來估算你的bucket數量應該是多少，建議還是單個bucket大小在1-3G。
    1. 避免數據傾斜的問題
      1. 一個是對分桶字段進行加鹽處理，業務上查詢的時候也是要同樣的加鹽策略，這樣能利用到分桶數據剪裁能力
      2. 另外一個是數據隨機分桶，這種缺點是沒辦法利用數據分桶剪裁能力，數據分布會很均勻
【建議】 1000w-2 億以內數據為了方便可以不設置分區，直接用分桶策略。（不設置其實Doris內部會有個默認分區）
1. 參考上面第二點
【強制】 2000kw 以內數據禁止使用動態分區（動態分區會自動創建分區，而小表用戶客戶關注不到，會創建出大量不使用分區分桶）
1. 參考上面第二點
【強制】對于有大量歷史分區數據，但是歷史數據比較少，或者不均衡，或者查詢概率的情況，使用如下方式將數據放在特殊分區。
1. 對于歷史數據，如果數據量比較小我們可以創建歷史分區（比如年分區，月分區），將所有歷史數據放到對應分區里
2. 創建歷史分區方式FROM ("2000-01-01") TO ("2022-01-01") INTERVAL 1 YEAR

(
 PARTITION p00010101_1899 VALUES [('0001-01-01'), ('1900-01-01')),
 PARTITION p19000101 VALUES [('1900-01-01'), ('1900-01-02')),
...
 PARTITION p19000104_1999 VALUES [('1900-01-04'), ('2000-01-01')),
 FROM ("2000-01-01") TO ("2022-01-01") INTERVAL 1 YEAR,
 PARTITION p30001231 VALUES [('3000-12-31'), ('3001-01-01')),
 PARTITION p99991231 VALUES [('9999-12-31'), (MAXVALUE))
)

【強制】如果分桶字段存在30%以上的數據傾斜，則禁止使用Hash分桶策略，改使用random分桶策略
1. 參考上面第二點事實表部分
【建議】前綴索引的第一個字段一定是最長查詢的字段，并且需要是高基字段。這里面選取分區分桶外最長查詢且高基數的列
1. 前綴索引（36位）：第一個字段查詢性能最好，前綴索引碰見varchar類型的字段，會自動截斷前20個字符
  1. Int（4）+ Int（4） + varchar(50)，前綴索引長度只有28
  2. Int（4） + varchar(50) + Int（4），前綴索引長度只有24
  3. varchar(10) + varchar(50) ，前綴索引長度只有30
2. 最常用的查詢字段如果能放到前綴索引里盡可能放到前前綴索引里，如果不能，可以放到分桶字段里
  1. 分桶字段注意事項：這個一般是數據分布比較均衡的，也是經常使用的字段，最好是高基數字段
good case ：UNIQUE KEY(user_id, age) user_id最長被查詢，且數據分布比較散
bad case ：UNIQUE KEY(age,user_id ) age是低基數列，且可能存在數據傾斜
【強制】表的副本數必須為3
【建議】前綴索引中的字段長度盡可能明確，因為Doris只有前36個字節能走前綴索引
【強制】除了UNIQUE KEY和aggregate key要構建key的情況，否則不要基數（例如user_type）小于50的字段建立任何索引。因為Doris內置了字典類型優化。
1. 已經有了低基數優化了
2. Unique Key 是aggregate key 的一個特例，當aggregate key 的key 保持唯一其實就是Unqiue key 模型
【強制】BloomFilter索引必須在查詢條件是in或者=，并且是高基（5000以上）列上構建。
1. 數據基數在一半左右
2. 類似身份證號這種基數特別高并且查詢是等值（=）查詢，使用Bitmap索引能極大加速
3. Bloomfilter 使用場景：
  1. 首先BloomFilter適用于非前綴過濾。
  2. 查詢會根據該列高頻過濾，而且查詢條件大多是 in 和 = 過濾。
  3. 不同于Bitmap, BloomFilter適用于高基數列。比如UserID。因為如果創建在低基數的列上，比如 “性別” 列，則每個Block幾乎都會包含所有取值，導致BloomFilter索引失去意義。
【強制】bitmap索引必須在一定基數范圍內構建，太高或者太低的基數都不合適
1. 這種索引更多的適合正交查詢
2. 適用場景：
  1. 適用于低基數的列上，建議在100到100,000之間，如：職業、地市等。重復度過高則對比其他類型索引沒有明顯優勢；重復度過低，則空間效率和性能會大大降低。特定類型的查詢例如count、or、and 等邏輯操作因為只需要進行位運算
3. Bitmap 索引支持類型：
  1. bitmap 索引支持的數據類型如下:
    - TINYINT
    - SMALLINT
    - INT
    - BIGINT
    - CHAR
    - VARCHAR
    - DATE
    - DATETIME
    - LARGEINT
    - DECIMAL
    - BOOL
【強制】億級別以上數據，如果有模糊匹配，使用倒排索引或者是 NGram Bloomfilter
【建議】如果某個范圍數據在分區分桶和前綴索引中都不好設計，可以考慮引入倒排索引加速。
【強制】單表物化視圖不能超過6個
1. 單筆物化視圖是實時構建
2. 在unique 模型上物化視圖只能起到 Key 重新排序的作用，不能做數據的聚合，因為Unqiue模型的聚合模型是replace
【建議】建議使用JSON數據類型代替字符串類型存放JSON數據的使用方式

第三部分：數據變更規范

【強制】應用程序不可以直接使用delete后者update語句變更數據，使用CDC的upsert方式來實現。
1. 低頻操作上使用，比如 Update 幾分鐘更新一次
2. 如果使用 Delete 一定帶上分區條件
【強制】DBA執行delete后者update語句時必須帶分區條件
【強制】禁止使用INSERT INTO tbl1 VALUES ("1"), ("a");這種方式寫入數據。
【建議】特殊大的ETL操作，簡單單獨在Session中設置超時時間
1. SELECT/*+ SET_VAR(query_timeout = 1*/ sleep(3); 類似這樣通過Hint方式去設置Session 會話變量，不要設置全局的系統變量

第四部分：數據查詢規范

【強制】in 中條件超過 2000 后，必須修改為子查詢
【強制】禁止使用REST API（Statement Execution Action）執行大量SQL查詢，改接口僅僅用于集群維護。
【建議】一次insert into select 數據超過1億條后，建議拆分為多個insert into select語句執行，分成多個批次來執行。
1. 如果真的是要這樣執行，在集群資源相對空閑的時候可以通過調整并發度來加快的數據導入速度
  
  2.0 以后版開啟了Pipeline 就不需要設置并發度了
```
  set parallel_fragment_exec_instance_num = 8 或者 16 建議是你CPU內核的一半
  insert into new_tbl select * from old_tbl
```
【強制】query查詢條件返回結果在5w條以上，使用JDBC Catalog或者OUTFILE方式導出。不然大量FE上數據傳輸將占用FE資源，影響集群穩定性
1. 如果你是交互式查詢，建議使用分頁方式（offset limit），分頁要加Order by
2. 如果是數據導出提供給第三方使用，建議使用 outfile 或者 export 方式
【建議】query查詢如果有大量的數據傳輸需求，建議部署observer節點并在該該節點執行查詢（私有化部署）
1. 建議的方式是 1 FE(Follower) + 多個 OBserver（FE）方式，讀寫分析，所有的寫連接 Follower，所有的讀連接Observer
【建議】盡量不要使用OR 作為 JOIN條件
【建議】大量數據排序（5億以上）后返回部分數據，建議先減少數據范圍在執行排序，否則大量排序會影響性能。

select * from kunpeng_risk_record krr where krr.event_occur_time_date between '2023-10-01 00:00:00' and '2023-10-25 23:59:59' and krr.partner_code = 'liveme' order by krr.sequence_id desc limit 20;

例如將 from table order by datatime desc limit 10 優化為from table where datatime='2023-10-20' order by datatime desc limit 10
【強制】2個以上大于3億的表 JOIN 使用 Colocate JOIN
1. Colocate Join 的使用參照：Colocation Join - Apache Doris
【強制】億級別大表禁止使用select * 查詢，查詢時需要明確要查詢的字段
1. SQL Block方式禁止這種操作
2. 如果是高并發點查，建議開啟行存
3. 表屬性級別
```
"enable_unique_key_merge_on_write" = "true",
"store_row_column" = "true"
      
be.conf
disable_storage_row_cache 是否開啟行緩存， 默認不開啟
```
1. 使用PrepareStatement模板
【強制】億級以上表數據查詢必須帶分區分桶條件

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

Doris 數倉使用規范（經驗版）

Doris 數倉使用規范（經驗版）

第一部分：字符集規范

第二部分：建表規范

第三部分：數據變更規范

第四部分：數據查詢規范

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

Doris 數倉使用規范（經驗版）

第一部分：字符集規范

第二部分：建表規范

第三部分：數據變更規范

第四部分：數據查詢規范

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频