歐洲航天局科學數據中心（the European Space Agency Science Data Center，簡稱ESDC）利用TimescaleDB擴展切換到用PostgreSQL來存儲他們的數據。ESDC的各種數據，包括結構化的、非結構化的和時間序列指標在內接近數百TB，還有使用開源工具查詢跨數據集的需求。
ESDC收集來自他們每一個空間任務的海量數據（每天的量以TB計算），并把這些數據提供給包括普通公眾在內的團隊使用。包括空間任務和衛(wèi)星的元數據，以及在空間任務執(zhí)行期間生成的數據，這些數據都可以是結構化的，也可以是非結構化的。生成的數據包括地理空間和時間序列數據。因為需要能夠使用現成的、開源工具來分析數據，所以在選擇數據存儲解決方案時，對數據集的交叉運用就成了一個需求項。團隊希望擺脫像Oracle和Sybase這樣的傳統(tǒng)系統(tǒng)。
因為PostgreSQL的成熟，以及對各種數據類型和非結構化數據的支持，ESDC團隊已經確定使用PostgreSQL。除了這些例行要求外，ESDC也需要存儲和處理地理空間和時間序列數據。地理空間數據是那些附有位置信息的數據，比如行星在天空中的位置。這必須在不使用不同類型或數據源的不同數據存儲的情況下完成。之所以決定遷移到PostgreSQL，是因為它支持這種處理的擴展機制。PostgreSQL針對JSON和全文本搜索有原生支持。PostGIS、pg_sphere和q3c擴展運行ESDC使用常規(guī)SQL來運行基于位置的查詢以及更專業(yè)的分析。
對于像太陽軌道器項目（the Solar Orbiter project）這樣的任務產生的時間序列數據，PostgreSQL還必須高效且可擴展地存儲它們。這對寫入速度要求很低，因為收集到的數據存儲在本地的衛(wèi)星上，“用于每天的地面站通行期間的稍后下行鏈路”，并分批次插入數據庫。但是，針對這個數據庫的查詢，必須支持結構化的數據類型、數據集之間的ad-hoc匹配和高達數百TB的大型數據集。
目前，還不清楚哪些特定的時間序列數據庫得到了評估，但是，該團隊沒有選擇其中任何一個，因為他們已經將SQL標準化為首選的查詢語言，并把PostgreSQL作為平臺，因為它滿足了他們的其他要求。過去有一些方法可以把時間序列數據存儲在PostgreSQL上。它最近的分區(qū)特性試圖解決這樣的問題：將大表索引保存在內存中，并在每次更新時將其寫入磁盤，方法是將表分割成更小的分區(qū)。當按時間進行分區(qū)時，分區(qū)也可以用于存儲時間序列數據，遵循著這些分區(qū)上的索引。ESDC存儲時間序列數據的時候，遇到了性能問題，于是轉而使用名為TimescaleDB的擴展。
TimescaleDB使用名為hypertable的抽象來隱藏跨多個維度（如時間和空間）的分區(qū)。每個hypertable被分成“塊（chunk）”，每個塊對應一個特定的時間間隔。塊的大小是一定的，因此，用于表索引的所有B樹結構都能夠在數據插入數據庫期間駐留內存，類似于PostgreSQL進行分區(qū)的方式。索引是根據時間和分區(qū)關鍵字自動產生的。可以針對任意“維度”進行查詢，就像其他時間序列數據庫允許針對標簽查詢一樣。
TimescaleDB和其他分區(qū)工具（如pg_partman）的區(qū)別之一是自動調整分區(qū)大小。盡管據報道，與基于PostgreSQL 10分區(qū)的解決方案和InfluxDB相比，TimescaleDB有更高的性能基準，但人們一直擔心可維護性。在撰寫本文時，TimescaleDB的集群部署仍處于開發(fā)階段。
原文作者：Hrishikesh Barua
