1樓：順哲
如果你的儲存策略RP的保留是90天，那麼你的分片shard的時長在一天就比較合理，那麼一天的量就是：8,000×3,600×24=691,200,000，大概每天近7億條資料。這個量對於influxdb單機來說，我覺得是夠用了，除非你的每條記錄量的確很大，那麼可以考慮採購商業版本做成分布式來提公升磁碟I/O效能。
無需你再去做所謂的表水平切分，毫無意義。水平分表針對的都是按行儲存與索引的傳統關係型資料庫，水平分表的邏輯還是按key或者時間進行行集的範圍劃分，加快定位，減少掃瞄。對於influxdb，其底層儲存設計理念完全不同於傳統關係表資料庫，它的TSM資料模型源自於nosql常用的LSM-Tree資料模型設計，又遠勝於此模型，是基於時序TS資料的特定優化，
至於按時間範圍查詢會不會很慢？這個問題，其實這種憂慮是多餘的，這就需要理解其分片存放和TSM結構：
按照這種保留策略，每隔一天就會形成乙個分片目錄，存放一天的TSM資料，那麼無論是600億還是6000億，按照時間範圍查詢一定是先根據目錄索引。如果你是influxdb集群，例如：8個節點，2個副本，相當於對一天的資料又切成了四分，也就是乙個節點的某個分片目錄只對應了1.
7億的資料，集群的分布這會讓讀寫更快。
我們在細究到influxdb時間查詢問題的內部，influxdb為什麼用時間範圍查就一定很快，上面聊的是分片的檔案目錄優化帶來的查詢效能提公升，其實tsm檔案本身就分成了資料塊集合和索引塊集合兩部分，乙個資料塊就是由時間戳(timestamps)的集合與值(values)的集合組成。索引塊由N個索引實體組成，每個索引實體提供了資料塊最小時間和最大時間的偏移量，這個時間範圍就定位到了要取的資料塊，因此查詢的時候，Series + field作為主鍵定位乙個索引塊，拿時間範圍在索引塊中去定位匹配的一組索引實體，也就很快定位到了匹配的資料塊集合。
我們在細究到它的內部結構原理上，influxdb的儲存是按照Series+field的方式儲存時間戳與資料塊集合，記憶體中還原後類似Series+field=這種結構，典型的列式結構，查詢時按照series作為行鍵進行fields列的排序成行，輸出結果，這又類似於列簇的結構，明顯看出要比常見的按k/v單元儲存之上增強了V的按時間線的聚合性。這就完美的匹配了時序資料的特徵，資料塊中時間戳的聚合排列以及fields值的聚合排列，帶來了驚人的壓縮效率，同樣按照時間範圍的查詢效率更為驚人！
因此我們可以看到，influxdb就是玩時間線儲存的高手，這也是為什麼幾個億的記錄讓它用時間範圍去匹配，很輕鬆達到秒級以內別速度。
我另外兩篇關於influxdb機制原理的詳細描述回答:
influxDB 適合做什麼？
如何看待influxdb集群功能不再開源？
關注領域：大資料技術、分布式架構 ｜ 技術管理
購買廉價硬碟，不通電儲存資料方案是否可行？
冬日暖陽 硬碟資料如果需要確保資訊保安，可以考慮硬碟加密橋產品，將資料使用AES或SM演算法加密後儲存，金鑰和資料徹底分離，感興趣的可以到中科安源官網了解 http www.akeydrive.com 末路狂奔 買個靠譜點的NAS,組個RAID5，然後把硬碟分別儲存，有心的話，可以把硬碟內容做提取，...
海量日誌資料儲存用 elasticsearch 和 hbase 哪個好？
5G很小了，直接分片存raid5磁碟，手擼乙個簡單的查詢引擎，搞定。運維一套ELK或者hbase，成本可不小。如果傾向於開源方案的話，看下loki吧，雲原生，低成本。 dz lee elasticsearch和Hbase結合使用是不錯的選擇.Hbase 儲存是很不錯的選擇,NOSQL格式,方便擴充套...
記憶體是如何儲存資料的？
Sanjay 記憶體是計算機的乙個重要部件，計算機內所有程式的執行都需依託於記憶體。記憶體中主要存放CPU的運算資料以及與外部儲存裝置互動的資料。首先需要了解一下記憶體的物理結構。記憶體由IC電路組成，內部有電源 位址訊號 資料訊號 控制訊號，這些訊號皆通過IC 引腳來實現資料的讀寫操作。圖中 VC...