如果項目的功能模塊中用到對時間特性比較敏感的數(shù)據(jù)，例如性能監(jiān)控班挖，趨勢走向等需求時衷模，InfluxDB將會是一個不錯的選擇，雖然其很強很彪悍朋凉，但只有在使用的過程中遵循一定規(guī)范與原則州丹，才能發(fā)揮其良好的特性。
本文會先介紹一些InfluxDB的基本概念杂彭，然后列出一些在設計Schema時應該注意的問題墓毒，最后列出一些常見的優(yōu)化方式。
基本介紹
概念
Database: 數(shù)據(jù)庫名亲怠，在 InfluxDB 中可以創(chuàng)建多個數(shù)據(jù)庫所计，不同數(shù)據(jù)庫中的數(shù)據(jù)文件是隔離存放的，存放在磁盤上的不同目錄团秽。
Retention Policy: 存儲策略主胧，用于設置數(shù)據(jù)保留的時間，每個數(shù)據(jù)庫剛開始會自動創(chuàng)建一個默認的存儲策略 autogen习勤，數(shù)據(jù)保留時間為永久讥裤，之后用戶可以自己設置腾窝，例如保留最近2小時的數(shù)據(jù)奴璃。插入和查詢數(shù)據(jù)時如果不指定存儲策略，則使用默認存儲策略夸溶，且默認存儲策略可以修改吴旋。InfluxDB 會定期清除過期的數(shù)據(jù)损肛。
Measurement: 對于傳統(tǒng)數(shù)據(jù)庫的表，例如 cpu_usage 表示 cpu 的使用率荣瑟。
Tag sets: tags 在 InfluxDB 中會被建立索引治拿，且放在內存中。如果某種數(shù)據(jù)經(jīng)常用來被作為查詢條件笆焰，可以考慮設為Tag
Field: 記錄值劫谅，是查詢的主要對象，例如value值等
Point:代表一條記錄
Series:tag key 與tag value的唯一組合
Timestamp: 每一條數(shù)據(jù)都需要指定一個時間戳嚷掠，在 TSM 存儲引擎中會特殊對待捏检，以為了優(yōu)化后續(xù)的查詢操作。
操作
由于Tag與Field的不同特性不皆，在編寫SQL進行查詢時贯城，Tag與Field支持不同的操作，總結如下:
Tag
只能使用Tag進行Group
只能使用Tag進行正則表達式操作
Field
只能使用Field進行函數(shù)操作霹娄，例如sum()
只能使用Field進行比較操作
如果需要使用int,float,boolean類型進行存儲,只能使用Field
Schema 設計總結
不要把數(shù)據(jù)放到measurement名稱中能犯。
例如 不要讓measurement名稱看起來是這樣的：
cpu.server1.us_west
1
應該改成
cpu,host=server1,region=us_west
1
不要把數(shù)據(jù)放到Tag value中
例如 不要讓measurement名稱看起來是這樣的：
cpu,host=server1.us_west
1
應該改成
cpu,host=server1,region=us_west
1
不要使用取值范圍很廣的數(shù)據(jù)作為tag,例如uuid,hash等等
如果實在有這方面的需求鲫骗，考慮一下幾點建議
切成多個shard,并分到多個實例上
使用tag 前綴進行區(qū)分
使用field
使用集群
Tag Key不要與Field的名稱相同
Tags的數(shù)量不要太少
database的數(shù)量不要太多
當database的數(shù)量達到千萬級別時，會出現(xiàn)打開文件過多踩晶，占用內存過多等問題执泰。
優(yōu)化
常見的優(yōu)化方式如下
控制series的數(shù)量
Series會被索引且存在內存中，如果量太大會對資源造成過多損耗渡蜻，且查詢效率也得不到保障坦胶。
可以通過以下方式查詢series的數(shù)量：
influx -database 'cloudportal' -execute 'show series' -format 'csv'|wc -l
1
通過以下方式查詢tag values的數(shù)量：
influx -database 'cloudportal' -execute 'SHOW TAG VALUES FROM six_months.collapsar_flow WITH KEY = dip' -format 'csv'|wc -l
1
數(shù)量是否合適可以參考以下標準：
- 機器配置
類型 CPU RAM IOPS
Low 2-4 cores 2-4G 500
Moderate 4-6 cores 8-32G 500-1000
High 8+ cores 32+G 1000+
- 配置對應的Series數(shù)量
機器配置 每秒寫Field 每秒查詢數(shù)量 Series數(shù)量
Low <5 K <5 <100k
Moderate < 250 K <25 <1million
High >250 K >25 >1million
- 控制Tag Key,與Tag Value值的大小
- 使用批量寫
如果使用HTTP一次寫一條記錄，或許還沒有太大的負擔晴楔，但是如果用HTTPS的進行一條一條的寫顿苇，在加密/解密上的資源損耗會非常的大。如果不能使用HTTP,則推薦使用UDP協(xié)議 - 使用Continuous Queries 進行數(shù)據(jù)匯聚
對于查詢時間范圍較大且數(shù)據(jù)粒度要求不是非常高的數(shù)據(jù)税弃，可以考慮使用CQ進行數(shù)據(jù)匯總纪岁，并對匯總結果進行查詢 - 使用恰當?shù)臅r間粒度
在數(shù)據(jù)存儲的時候默認使用納秒。而對于很多業(yè)務操作而言则果，可能只需要精確到秒級別幔翰。這種情況對于存儲資源以及查詢性能都會有一定的影響。想法如果業(yè)務需要毫秒級別的精確程度西壮，而存的時候使用了秒級別的數(shù)據(jù)遗增，此時查詢又會出現(xiàn)數(shù)據(jù)的丟失 - 存儲的時候盡量對Tag進行排序
- 無關的數(shù)據(jù)寫不同的database
- 根據(jù)數(shù)據(jù)情況，調整shard的duration
默認7天創(chuàng)建一個款青，如果查詢的時間范圍較大做修，會打開多個shard文件，對于數(shù)據(jù)量不大抡草，且查詢范圍可能較大的數(shù)據(jù)饰及，可以將shard duration時間設置的長一點 - 存儲分離
將WAL目錄與data目錄分別映射到不同的磁盤上，以減少讀寫操作的相互影響
作者：小Alpha
來源：CSDN
原文：https://blog.csdn.net/eric_sunah/article/details/76274188
版權聲明：本文為博主原創(chuàng)文章康震，轉載請附上博文鏈接燎含！
