本章節主要從命名、TAG、FIELD、查詢等方面介紹GeminiDB Influx使用上的一些規范和建議，用于解決常見的使用錯誤，低效，難以維護等問題。
術語定義
- 規則：使用時必須遵守的約定。
- 建議：使用時必須考慮的約定。
名詞解釋
- RP：Retention Policy，即數據保留策略，包含數據保留時長，備份個數等信息。
- 數據對象：數據庫、RP、MEASUREMENT、TAG、FIELD。
命名
規則
a. 數據庫對象的名稱需要以小寫字母開頭，使用字母或者數字組合，長度不能超過32個字節。
b. 數據庫對象的名稱長度：<數據庫名>.<RP名稱>.<MEASUREMENT名稱> 總長度不能超過120個字符。
c. 數據庫對象的名稱不能使用系統保留關鍵字。
系統保留關鍵字詳情如下：ALL,ALTER,ANY,AS,ASC,BEGIN,BY,CREATE,CONTINUOUS,DATABASE,DATABASES,DEFAULT,DELETE,DESC,DESTINATIONS,DIAGNOSTICS,DISTINCT,DROP,DURATION,END,EVERY,EXPLAIN,FIELD,FOR,FROM,GRANT,GRANTS,GROUP,GROUPS,IN,INF,INSERT,INTO,KEY,KEYS,KILL,LIMIT,SHOW,MEASUREMENT,MEASUREMENTS,NAME,OFFSET,ON,ORDER,PASSWORD,POLICY,POLICIES,PRIVILEGES,QUERIES,QUERY,READ,REPLICATION,RESAMPLE,RETENTION,REVOKE,SELECT,SERIES,SET,SHARD,SHARDS,SLIMIT,SOFFSET,STATS,SUBSCRIPTION,SUBSCRIPTIONS,TAG,TO,USER,USERS,VALUES,WHERE,WITH,WRITE,WARM
d. 數據庫對象的名稱不能使用中文和特殊字符(["].$,/\0*?~#:|')。
e. 數據庫名稱不能使用_internal、_kapacitor、_heimdall、_vision、opentsdb等系統使用的數據庫名。
建議
a. TAG名稱越短越好，每個TAG名稱都有索引，索引都會在內存中，名字越短，越節省資源。
b. TAG KEY和FIELD KEY命名不要相同。
TAG
規則
a. 對其使用InfluxQL函數（MAX、MIN、COUNT等）的字段，作為FIELD存儲**。**
b. TAG只支持字符串類型，如果存儲的值不是字符串類型，作為FIELD存儲**。**
建議
a. 使用TAG區分數據比使用MEASUREMENT名稱區分性能更好**。**
b. 根據需求設計TIME精度，精度越低性能越好**。**
c. 經常作為查詢條件的字段，作為TAG存儲。
d. 對其使用GROUP BY的字段，作為TAG存儲**。**
FIELD
- 規則： 每個FIELD類型必須保持一致。
- 建議： FIELD不宜太多，每個FIELD的計算都會單獨計算，太多當執行模糊查詢會導致查詢失敗。
查詢
規則
a. 禁止執行SELECT * FROM進行查詢。
b. 查詢語句必須帶上時間范圍限制。
c. 業務上線前，一定要對數據庫進行性能壓測，評估業務峰值場景下，對數據庫的負載情況。
建議
a. 執行查詢時，只選擇需要返回的字段，不需要的字段不要返回。
b. 查詢時間范圍越小，查詢性能越好。
c. 查詢時TAG值越精確查詢性能越好。盡量是單時間線查詢，即指定所有的TAG值，或者盡量指定越多的TAG值。
d. 在查詢中的group by time intervals后增加fill(none), fill(none)作用為：對于沒有數據點的時間間隔，不返回任何時間戳和值。針對稀疏數據場景，能大幅降低查詢返回結果數據量。
e. 在使用嵌套查詢時將時間范圍的查詢條件放在最外層的查詢語句中。
刪除
建議： 不要使用DELETE方法刪除數據，建議根據需求設置合理的RP，通過RP自動刪除數據。
其他方面
- 規則 ：根據業務具體時間線規模、客戶端連接數、保留策略數量選擇對應的實例規格，規格詳情請參考1.3 數據庫實例規格。
超規格使用，可能會導致不可預知的問題；嚴重時有可能導致數據庫不可用。
- 建議： 使用ELB連接數據庫，詳情請參見3.3.2.1 通過負載均衡地址連接實例（推薦）。
- 建議： 如果開啟了冷存儲，在一個時間段的數據已經轉冷后，不建議再寫入該時間段的數據，否則會引起未知問題。
