PostgreSQL中的大容量空间探索时间序列数据存储

欧洲航天局科学数据中心(the European Space Agency Science Data Center,简称ESDC)利用TimescaleDB扩展切换到用PostgreSQL来存储他们的数据。ESDC的各种数据,包括结构化的、非结构化的和时间序列指标在内接近数百TB,还有使用开源工具查询跨数据集的需求。

ESDC收集来自他们每一个空间任务的海量数据(每天的量以TB计算),并把这些数据提供给包括普通公众在内的团队使用。包括空间任务和卫星的元数据,以及在空间任务执行期间生成的数据,这些数据都可以是结构化的,也可以是非结构化的。生成的数据包括地理空间和时间序列数据。因为需要能够使用现成的、开源工具来分析数据,所以在选择数据存储解决方案时,对数据集的交叉运用就成了一个需求项 。团队希望摆脱像Oracle和Sybase这样的传统系统。

因为PostgreSQL的成熟,以及对各种数据类型和非结构化数据的支持,ESDC团队已经确定使用PostgreSQL。除了这些例行要求外,ESDC也需要存储和处理地理空间和时间序列数据。地理空间数据是那些附有位置信息的数据,比如行星在天空中的位置。这必须在不使用不同类型或数据源的不同数据存储的情况下完成。之所以决定迁移到PostgreSQL,是因为它支持这种处理的扩展机制。PostgreSQL针对JSON和全文本搜索有原生支持。PostGISpg_sphereq3c扩展运行ESDC使用常规SQL来运行基于位置的查询以及更专业的分析。

对于像太阳轨道器项目(the Solar Orbiter project)这样的任务产生的时间序列数据,PostgreSQL还必须高效且可扩展地存储它们。这对写入速度要求很低,因为收集到的数据存储在本地的卫星上,“用于每天的地面站通行期间的稍后下行链路”,并分批次插入数据库。但是,针对这个数据库的查询,必须支持结构化的数据类型、数据集之间的ad-hoc匹配和高达数百TB的大型数据集。

目前,还不清楚哪些特定的时间序列数据库得到了评估,但是,该团队没有选择其中任何一个,因为他们已经将SQL标准化为首选的查询语言,并把PostgreSQL作为平台,因为它满足了他们的其他要求。过去一些方法可以把时间序列数据存储在PostgreSQL上。它最近的分区特性试图解决这样的问题:将大表索引保存在内存中,并在每次更新时将其写入磁盘,方法是将表分割成更小的分区。当按时间进行分区时,分区也可以用于存储时间序列数据,遵循着这些分区上的索引。ESDC存储时间序列数据的时候,遇到了性能问题,于是转而使用名为TimescaleDB的扩展。

TimescaleDB使用名为hypertable的抽象来隐藏跨多个维度(如时间和空间)的分区。每个hypertable被分成“块(chunk)”,每个块对应一个特定的时间间隔。块的大小是一定的,因此,用于表索引的所有B树结构都能够在数据插入数据库期间驻留内存,类似于PostgreSQL进行分区的方式。索引是根据时间和分区关键字自动产生的。可以针对任意“维度”进行查询,就像其他时间序列数据库允许针对标签查询一样。

TimescaleDB和其他分区工具(如pg_partman)的区别之一是自动调整分区大小。尽管据报道,与基于PostgreSQL 10 分区的解决方案和InfluxDB相比,TimescaleDB有更高的性能基准,但人们一直担心可维护性。在撰写本文时,TimescaleDB的集群部署仍处于开发阶段。

TimescaleDB是托管在GitHub上的开源软件。

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址http://www.infoq.com/cn/news/2018/10/space-time-series-data
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券