建立Influxdb數據庫時,咱們能夠看到下面選項,每一個選項的含義就是本文要描述的:html
Influxdb內部數據的存儲能夠使用不一樣的存儲引擎。當前0.8.7版本支持的是LevelDB, RocksDB, HyperLevelDB, 和 LMDB。算法
這幾個數據庫都是kv類型的數據庫,相關信息以下:數據庫
LevelDB 是一個google實現的很是高效的kv數據庫,目前的版本1.2可以支持billion級別的數據量了。
LevelDB 是單進程的服務,性能很是之高,在一臺4核Q6600的CPU機器上,每秒鐘寫數據超過40w,而隨機讀的性能每秒鐘超過10w。
此處隨機讀是徹底命中內存的速度,若是是不命中 速度大大降低
LevelDB 只是一個 C/C++ 編程語言的庫, 不包含網絡服務封裝, 因此沒法像通常意義的存儲服務器(如 MySQL)那樣, 用客戶端來鏈接它. LevelDB 本身也聲明, 使用者應該封裝本身的網絡服務器.編程
RocksDB 是一個來自 facebook 的可嵌入式的支持持久化的 key-value 存儲系統,也可做爲 C/S 模式下的存儲數據庫,但主要目的仍是嵌入式。RocksDB 基於 LevelDB 構建。服務器
HyperLevelDB 是 HyperDex 開發的一個數據存儲引擎,改進自 Google 的 LevelDB 以知足 HyperDex 的業務須要。
HyperLevelDB 主要在 LevelDB 上改進了:
1. 改進並行機制,使用更細粒度的內部鎖控制來提供多 writer 線程的高吞吐量
2. 改進數據壓縮網絡
LMDB 是一個快而小的 key-value 數據存儲服務,是由 OpenLDAP 項目的 Symas 開發的。使用內存映射文件,所以讀取的性能跟內存數據庫同樣。其大小受限於虛擬地址空間的大小。編程語言
Influxdb 官方試驗了這三個引擎,發現RocksDB性能好,因此Influxdb的默認存儲引擎是RocksDB。oop
Influxdb 的數據存儲能夠支持多碎片存儲,每一個碎片能夠是一種存儲引擎,以下圖,一個數據庫能夠有多個碎片。性能
每一個碎片存儲都有下面屬性,跟上面圖的內容項對應:大數據
{ "name": "high_precision", "database": "pauls_db", "retentionPolicy": "7d", "shardDuration": "1d", "regex": "/^[a-z].*/", "replicationFactor": 1, "split": 1 }
在配置參數中, 咱們能夠看到 "database": "pauls_db" 標示 每一個碎片存儲都只能屬於一個特定的數據庫,一個數據庫能夠有多個 Shard Space。
"retentionPolicy": "7d" 表示數據被保存的時間(最少保存時間), 圖中的 Retention 就是這個, 下圖是系統界面中,對這個時間的設置, inf 標示永久。
"shardDuration": "1d", 表示 多長時間作次清理。
shardDuration 的值應該小於 retentionPolicy, 大於咱們查詢時的group by time() 的值。
上面配置的例子中 "retentionPolicy": "7d", "shardDuration": "1d", 會致使咱們保存 7-8 天的數據, 天天都會清理,把7天前的數據清理掉一次。
"replicationFactor": 1, 每一個存儲碎片保存到幾臺服務器的設置;
"split": 1 給定的時間間隔內,有多少個存儲碎片。
注意,這裏有下面一個隱含的關係: replicationFactor * split == 服務器的數量。
數據被分配到那個碎片空間是基於下面的算法:
使用 shard spaces 的最佳實踐是把高精度,大數據的數據 每一個時間段寫一個 shard spaces 。在使用時把他們再合成一塊兒。
參考資料:
Influxdb Storage Engines
http://influxdb.com/docs/v0.8/advanced_topics/sharding_and_storage.html