PostgreSQL中的大容量空間探索時間序列資料儲存
歐洲航天局科學資料中心（the European Space Agency Science Data Center，簡稱ESDC）利用TimescaleDB擴充套件切換到用PostgreSQL來儲存他們的資料。ESDC的各種資料，包括結構化的、非結構化的和時間序列指標在內接近數百TB，還有使用開源工具查詢跨資料集的需求。
ESDC收集來自他們每一個空間任務的海量資料（ofollow,noindex" target="_blank">每天的量以TB計算 ），並把這些資料提供給包括普通公眾在內 的團隊使用。包括空間任務和衛星的元資料，以及在空間任務執行期間生成的資料，這些資料都可以是結構化的，也可以是非結構化的。生成的資料包括地理空間和時間序列資料。因為需要能夠使用現成的、開源工具來分析資料，所以在選擇資料儲存解決方案時，對資料集的交叉運用就成了一個需求項 。團隊希望擺脫像Oracle和Sybase這樣的傳統系統。
因為PostgreSQL的成熟，以及對各種資料型別和非結構化資料的支援，ESDC團隊已經確定使用PostgreSQL。除了這些例行要求外，ESDC也需要儲存和處理地理空間和時間序列資料。地理空間資料是那些附有位置資訊的資料，比如行星在天空中的位置。這必須在不使用不同型別或資料來源的不同資料儲存的情況下完成。之所以決定遷移到PostgreSQL，是因為它支援這種處理的擴充套件機制。PostgreSQL針對JSON和全文字搜尋有原生支援。PostGIS 、pg_sphere 和q3c 擴充套件執行ESDC使用常規SQL來執行基於位置的查詢以及更專業的分析。
對於像太陽軌道器專案（the Solar Orbiter project） 這樣的任務產生的時間序列資料，PostgreSQL還必須高效且可擴充套件地儲存它們。這對寫入速度要求很低，因為收集到的資料儲存在本地的衛星上，“用於每天的地面站通行期間的稍後下行鏈路”，並分批次插入資料庫。但是，針對這個資料庫的查詢，必須支援結構化的資料型別、資料集之間的ad-hoc匹配和高達數百TB的大型資料集。
目前，還不清楚哪些特定的時間序列資料庫得到了評估，但是，該團隊沒有選擇其中任何一個，因為他們已經將SQL標準化為首選的查詢語言，並把PostgreSQL作為平臺，因為它滿足了他們的其他要求。過去 有 一些方法 可以把時間序列資料儲存在PostgreSQL上。它最近的分割槽特性試圖解決這樣的問題：將大表索引儲存在記憶體中，並在每次更新時將其寫入磁碟，方法是將表分割成更小的分割槽。當按時間進行分割槽時，分割槽也可以用於儲存時間序列資料，遵循著這些分割槽上的索引。ESDC儲存時間序列資料的時候，遇到了效能問題，於是轉而使用名為TimescaleDB 的擴充套件。
圖片來源: https://blog.timescale.com/when-boring-is-awesome-building-a-scalable-time-series-database-on-postgresql-2900ea453ee2
TimescaleDB使用名為hypertable 的抽象來隱藏跨多個維度（如時間和空間）的分割槽。每個hypertable被分成“塊（chunk）”，每個塊對應一個特定的時間間隔。塊的大小是一定的，因此，用於表索引的所有B樹結構都能夠在資料插入資料庫期間駐留記憶體，類似於PostgreSQL進行分割槽的方式。索引是根據時間和分割槽關鍵字自動產生的。可以針對任意“維度 ”進行查詢，就像其他時間序列資料庫允許sary/#tag" rel="nofollow,noindex" target="_blank">針對 標籤 查詢一樣。
TimescaleDB和其他分割槽工具（如pg_partman ）的區別之一是自動調整分割槽大小 。儘管據報道 ，與基於PostgreSQL 10 分割槽的解決方案和InfluxDB 相比，TimescaleDB有更高的效能基準，但人們一直擔心可維護性 。在撰寫本文時，TimescaleDB的叢集部署仍處於開發階段。
閱讀英文原文：High Volume Space Exploration Time-Series Data Storage in PostgreSQL
感謝冬雨對本文的審校。