先看下 http://www.cnblogs.com/bonelee/p/6236962.html 這裏對於環形數據庫的介紹，便於理解歸檔這個操作！

轉自：http://blog.sina.com.cn/s/blog_6de3aa8a0102wk0y.html

早期的OpenStack監控（遙測）項目ceilometer被一分為四（Ceilometer、Gnocchi、Aodh、Panko），各司其職！其中Ceilometer負責采集計量數據並加工預處理；Gnocchi主要用來提供資源索引和存儲時序計量數據；Aodh主要提供預警和計量通知服務；Panko主要提供事件存儲服務。促成Ceilometer分裂的主要原因是：早期各類資源的計量數據（即是時間序列數據）（measurement，核心字段是<</span>時間，值>）存儲在SQL數據庫中的sample表中；隨著雲環境中需要被監控的資源增多和時間的推移，計量數據的增長變得難以預測；計量數據的使用方面，查詢操作首先要從巨大的sample單表中過濾所需條目，然後還會涉及到相關的聚合計算；可想而知，由此帶來的性能開銷絕對是無法忍受的，並且隨著時間的推移這個瓶頸會愈加明顯直至奔潰。要解決上述問題方法有很多，比如分表：每個監控指標（Metirc）一張表，那麽一個資源可能會有多張表（比如一個instance至少會有cpu，cpu.util，memory，memory.usage，disk.* 等監控指標metrics）；這似乎有點誇張，即使這樣都可以接受的話，那麽查詢時對計量數據的聚合操作也還是個問題。

類似的思想，紅帽的Julien Danjou（blog：https://julien.danjou.info/blog/）發起了Gnocchi項目來解決這類問題。其總體思路是：把各個計量指標Metric的計量數據measurement直接寫入後端存儲中；並在measurement寫入之前根據預先設定的歸檔策略進行聚合操作；查詢時直接讀取對應的文件即可獲得聚合後的監控信息點，顯然時間復雜度變為O(1)了；並且提供資源索引，這樣能更快的找到每個資源的基礎信息metadata和其相關的metrics信息。

OpenStack/Gnocchi簡介和架構[附文檔翻譯]

文檔翻譯（歡迎雅正）：http://gnocchi.xyz

第一部分：Gnocchi簡介 http://gnocchi.xyz/index.html

Gnocchi – Metric as a Service，Gnocchi計量作為一種服務
Gnocchi是一個多租戶時間序列，計量和資源數據庫。提供了HTTP REST接口來創建和操作數據。Gnocchi設計用於超大規模計量數據的存儲，同時向操作者和用戶提供對度量和資源信息的訪問。
Gnocchi是OpenStack項目的一部分。因此它支持OpenStack，但也能完全獨立的工作。
您可以在 http://gnocchi.xyz上閱讀完整的在線文檔。

Why Gnocchi?為什麽使用Gnocchi？
Gnocchi已被創建滿足在雲計算環境中可用的時間序列數據庫的需要：提供存儲大量度量數據並且易於擴展的能力。
Gnocchi項目於2014年開始，作為OpenStack Ceilometer項目的分支，以解決Ceilometer在將標準數據庫用作計量數據的存儲後端時遇到的性能問題。更多信息，請參見Julien的博客Gnocchi。

Use cases，使用案例
Gnocchi旨在用於存儲時間序列及其相關聯的資源元數據。因此，它有用的例子如：
（1）計費系統的存儲；（2）報警觸發或監控系統；（3）數據的統計使用。

Key Features，關鍵特性
HTTP REST接口 水平可擴展性 度量聚合 測量批處理支持 存檔策略 計量值搜索
結構化資源 資源歷史 可查詢資源索引器 多租戶支持 Grafana支持 Statsd協議支持


第二部分：Gnocchi的架構 http://gnocchi.xyz/architecture.html

Project Architecture，項目架構
Gnocchi由幾個服務組成：一個HTTP REST API（請參閱REST API Usage），可選的statsd兼容守護程序（請參閱Statsd守護程序使用）和異步處理守護程序。 通過HTTP REST API和statsd守護程序接收數據。異步處理守護程序（稱為gnocchi-metricd）在後臺對接收到的數據執行統計計算，度量標準清除等操作。
HTTP REST API和異步處理守護程序都是無狀態的，並且是可擴展的。可以根據負載添加其它workers。

Back-ends，後端
Gnocchi使用了兩個不同的後端存儲數據：一個用於存儲時間序列（存儲驅動程序），另一個用於索引數據（索引驅動程序）。
存儲器負責存儲所創建的度量的計量值measurement。它接收時間戳和值，並根據定義的歸檔策略預先計算聚合。
索引器負責存儲所有資源的索引，以及它們的類型和屬性。Gnocchi不僅了解來自OpenStack項目的資源類型，也提供了一個通用類型，因此您可以創建基本資源並自己處理資源屬性。 索引器還負責將資源與度量指標metric相關聯。

How to choose back-ends，如何選擇後端
Gnocchi目前提供了集中不同的存儲引擎：File，Swift，S3，Ceph（首選）。
Storage的驅動程序基於一個名為Carbonara的中間庫，由該中間庫處理時間序列操作，因為這些存儲技術本身都不能處理時間序列。
四個基於Carbonara的驅動程序運行良好，並且後端技術保證可擴展性。 Ceph和Swift本身就比文件驅動器更具可擴展性。
根據您的體系結構的大小，使用文件驅動程序並將數據存儲在磁盤上可能就足夠了。 如果需要使用文件驅動程序擴展服務器數量，則可以通過NFS在所有Gnocchi進程中導出和共享數據。在任何情況下，顯然S3，Ceph和Swift驅動程序在很大程度上更具可伸縮性。Ceph還提供了更好的一致性，因此是推薦的驅動程序。

How to plan for Gnocchi’s storage，如何規劃Gnocchi的存儲
Gnocchi使用基於Carbonara庫的自定義文件格式。在Gnocchi中，時間序列是點的集合，其中點是在時間序列的壽命中的給定測量或樣本。使用各種技術壓縮存儲格式，因此可以基於其最壞情況情況使用以下公式來估計時間序列大小的計算： 點數×8字節=以字節為單位的大小
您要保留的點數通常由以下公式確定： 點數=時間跨度÷粒度
例如，如果您想保留一年的數據，一分鐘的分辨率： 點數=（365天×24小時×60分鐘）÷1分鐘 = 525 600。然後：字節大小= 525 600字節×6 = 3 159 600字節= 3 085 KiB
這只是一個聚合時間序列。如果歸檔策略使用具有相同“一年，一分鐘聚合”分辨率的6個默認聚合方法（mean，min，max，sum，std，count），則使用的空間將最多增加到6×4.1 MiB = 24.6 MiB。

How to set the archive policy and granularity，如何設置歸檔策略和計量粒度
在Gnocchi中，歸檔策略以點數表示。如果歸檔策略定義了10點的策略，粒度為1秒，則時間序列歸檔將保持長達10秒，每個代表1秒鐘的聚合。這意味著時間序列將最多保留最近點和最舊點之間的10秒數據（有時多一點）。這並不意味著它將是10個連續的秒：如果數據被不規則地時間間隔送達，可能存在間隙。
相對於當前時間戳沒有數據到期。此外，您不能刪除舊的數據點（至少現在）。
因此，存檔策略和粒度完全取決於您的用例。根據數據的使用情況，可以定義多個歸檔策略。典型的低粒度用例可能是：
3600點，粒度為1秒= 1小時
1440點，粒度為1分鐘= 24小時
720點，粒度為1小時= 30天
365分，粒度為1天= 1年
這將表示每種聚集方法6125點×9 = 54 KiB。如果使用8標準聚合方法，您的指標將占用8×54 KiB = 432 KiB的磁盤空間。

Default archive policies，默認的歸檔策略
默認情況下，使用默認存檔策略（在default_aggregation_methods中列出，即平均值，最小值，最大值，總和，標準值，計數）創建3個歸檔策略：
low（每個metric的最大估計大小：5 KiB）
5分鐘粒度1小時；1小時粒度1天；1天粒度超過1個月
medium（每個metric的最大估計大小：139 KiB）
1分鐘粒度1天；1小時粒度超過1周；1天的粒度超過1年
high（每個metric的最大估計大小：1 578 KiB）
1秒粒度；1分鐘粒度1周；1小時粒度超過1年

OpenStack/Gnocchi簡介——時間序列數據聚合操作提前計算並存儲起來，先算後取的理念