TimescaleDB使用限制、使用常见问题(翻译整理)
限制
虽然 TimescaleDB 通常提供超出 PostgreSQL 提供的功能,但使用超表存在一些限制,特别是分布式超表。本节记录了使用常规和分布式超表时的常见限制。
超表限制
不支持引用超表的外键约束。
用于分区的时间维度(列)不能有 NULL 值。
索引必须包括作为分区维度的所有列。
UPDATE
不支持在分区(块)之间移动值的语句。这包括 upserts (INSERT ... ON CONFLICT UPDATE
)。
分布式超表限制
常规超表的所有限制也适用于分布式超表。此外,以下限制特别适用于分布式超表:
不支持后台作业的分布式调度。在访问节点上创建的后台作业在此访问节点上调度和执行,而无需将作业分发到数据节点。
仅在接入节点上支持连续聚合。
不支持重新排序块。
表空间不能附加到访问节点上的分布式超表。仍然可以在数据节点上附加表空间。
假设角色和权限在分布式数据库的节点之间是一致的,但不强制执行一致性。
不支持数据节点上的联接。将分布式超表与另一个表连接起来需要另一个表驻留在访问节点上。这也限制了分布式超表上连接的性能。
分布式超表中外键约束引用的表必须存在于访问节点和所有数据节点上。这也适用于引用值。
不支持并行感知扫描和追加。
本地未提供用于跨节点备份/还原的一致还原点;将单个备份还原到访问节点和数据节点时必须小心。
此处描述了本机复制限制。
用户定义的函数必须手动安装在数据节点上,以便函数定义在访问节点和数据节点上都可用。这与使用 注册的函数特别相关
set_integer_now_func
。
请注意,这些限制涉及访问节点的使用。一些当前不受支持的功能可能仍适用于单个数据节点,但这种用法既没有经过测试,也没有得到官方支持。TimescaleDB 的未来版本可能会消除其中一些限制。
常见问题 - 关于我们的产品
Timescale、TimescaleDB、Timescale Cloud 和 TimescaleDB 托管服务之间有什么区别?
时间尺度是公司。
Timescale 为时间序列构建了一个名为TimescaleDB的开源关系数据库 。
Timescale 通过称为Timescale Cloud和Managed Service for TimescaleDB的托管服务代表其客户托管和管理 TimescaleDB 。
Timescale Cloud是一个易于使用的云原生关系数据库,用于在 AWS 上收集和分析不间断的时间序列数据流。Timescale Cloud 具有增强的功能,可帮助您利用数据的潜力,并建立在 PostgreSQL 和 TimescaleDB 的坚如磐石的基础之上,Timescale Cloud 使您能够衡量所有重要的事情。
TimescaleDB 托管服务是一种时序数据库即服务 (DBaaS),用于在 GCP 和 Azure 上进行部署。TimescaleDB 建立在 PostgreSQL 之上,为您的时间序列数据奠定了坚实的基础。TimescaleDB 托管服务支持多云部署,具有超过 75 个区域的灵活性。
什么是 TimescaleDB?
TimescaleDB 是一个开源的时间序列关系数据库。开发人员经常告诉我们,TimescaleDB 是“具有超能力的 PostgreSQL”。TimescaleDB 是支持全 SQL 的开源时序数据库。TimescaleDB 针对快速摄取和复杂查询进行了优化,像传统的关系数据库一样易于使用,但可以以以前为 NoSQL 数据库保留的方式进行扩展。特别是,这使得 TimescaleDB 成为运营分析的理想候选者。
为什么要使用 TimescaleDB?
随着时间成为衡量数据的一个更关键的维度,TimescaleDB 使开发人员和组织能够利用其更多的力量来衡量所有重要的事情。
在查询级别统一时间序列数据和关系数据消除了数据孤岛,并使演示和原型更容易启动。可扩展性和完整的 SQL 接口的结合使组织中的各种人员(例如,开发人员、产品经理、业务分析师等)能够直接询问数据问题。换句话说,通过支持已经广泛使用的查询语言,TimescaleDB 确保您的问题受限于您的想象力,而不是数据库。
我可以使用 TimescaleDB 做什么?
TimescaleDB 非常适合从 SQL 接口中受益的时间序列工作负载。SQL 有很多好处:大多数开发人员已经知道的查询语言;丰富的功能和实用程序;以及广泛的工具、连接器和可视化选项生态系统。此外,由于 TimescaleDB 本身支持 SQL JOINS,因此可以在查询时组合来自不同来源的数据(例如,将存储在 PostgreSQL 表中的关系数据与存储在 TimescaleDB 超表中的时间序列数据组合起来)。这种将关系数据与时间序列数据一起存储的能力使开发人员能够简化他们的堆栈,有可能将复杂的多语言架构简化为单个操作分析数据库。
由于这些优势,TimescaleDB 目前部署在多个行业,包括制造业、能源、公用事业、采矿、石油和天然气、金融、广告技术、智能空间等。用例包括复杂的监控和分析;预测应用程序、模型、消费者和连接机器的性能和行为;为运营分析工作流程和仪表板提供动力;用于 QA 和性能测试。
为什么我应该选择托管的 Timescale 产品?
如果您想要 TimescaleDB 的所有好处而无需安装、维护和管理数据库本身的麻烦,那么让 Timescale 代表您管理和操作 TimescaleDB。
借助基于云的 TimescaleDB,Timescale 可以管理数据库的所有操作元素,因此您可以专注于构建应用程序,而不是确保基础设施正常工作。我们确保您拥有一个安全、高可用性的环境,我们在其中管理基础架构,直至设置复制、时间点恢复、只读副本、备份等。
TimescaleDB 托管服务支持哪些云提供商和区域?
TimescaleDB 托管服务在以下云和区域中可用:
Amazon Web Services (AWS):弗吉尼亚北部 (
us-east-1
)、俄亥俄 (us-east-2
)、加利福尼亚北部 (us-west-1
)、俄勒冈 (us-west-2
)、圣保罗 (sa-east-1
)、斯德哥尔摩 (eu-north-1
)、爱尔兰 (eu-west-1
)、伦敦 (eu-west-2
)、巴黎 (eu-west-3
)、法兰克福 (eu-central-1
)、加拿大 (ca-central-1
)、新加坡 (ap-southeast-1
)、悉尼 (ap-southeast-2
)、东京 (ap-northeast-1
)、孟买 (ap-south-1
)、首尔 (ap-northeast-2
)Microsoft Azure (Azure):美国东部、美国东部 2、西欧、东南亚
Google Cloud Platform (GCP):北弗吉尼亚、洛杉矶、南卡罗来纳、爱荷华、俄勒冈、圣保罗、苏黎世、伦敦、法兰克福、芬兰、比利时、荷兰、蒙特利尔、悉尼、台湾、孟买、香港、东京、新加坡
Microsoft Azure、Digital Ocean 或其他云提供商提供的 TimescaleDB 版本是多少?
TimescaleDB 是一个用于时间序列的关系数据库,其中一些功能在 Apache 2.0 许可下获得许可,但您知道和喜爱的许多功能都通过Timescale 许可获得许可(包括连续聚合、压缩、数据保留策略、操作、多节点, 和更多)。Microsoft、Digital Ocean 等提供的 TimescaleDB 的“Apache 2.0”版本仅包含 Apache 许可证中的功能。Timescale 许可证禁止云提供商提供 TimescaleDB 即服务的“社区版本”。
今天,您可以在本地或您自己的托管服务帐户中部署 TimescaleDB 的社区版本,在裸机上运行该软件或使用我们 的开源 k8s helm 图表。以这种方式获得的 TimescaleDB 完全可以免费使用,甚至可以免费修改以供您自己使用或您在 TimescaleDB 上构建的服务或产品。
或者,如果您愿意,您可以让我们为您运行 TimescaleDB,在超过 75 个区域的 AWS、Azure 或 GCP 上完全托管,并可以访问我们的支持团队。
你真的支持“所有的 SQL”吗?
是的,所有的 SQL,包括:二级索引、JOIN、窗口函数。事实上,在外界看来,TimescaleDB 看起来就像一个 PostgreSQL 数据库:您可以像 PostgreSQL 一样连接到数据库,并且可以像 PostgreSQL 一样管理数据库。任何与 PostgreSQL 连接的工具和库都会自动与 TimescaleDB 一起使用。
为什么是 SQL?
SQL 是世界上用于与数据库交互和操作数据的广泛使用的查询语言。我们希望 TimescaleDB 易于使用且功能强大。由于 SQL 使用如此广泛,它允许整个组织访问他们的数据,为分析数据提供不同的视角,并赋予各自角色的人员权力。它还允许将驻留在 PostgreSQL 表中的数据轻松迁移到 TimescaleDB 超表。换句话说:我们希望确保您的查询仅受您的想象力的限制,而不是受查询语言的限制。要深入了解我们为何对 SQL 持积极态度,请阅读这篇博文: 为什么 SQL 正在击败 NoSQL,以及这对数据的未来意味着什么
支持哪些 SQL 功能?
我们支持所有 SQL,包括二级索引、复杂谓词、JOIN、窗口函数、CTE 等。此外,我们扩展 SQL 以引入 新的语义,使时间序列操作更容易。在幕后,我们还优化了 PostgreSQL 查询计划器,使数据库能够正确推理时间序列数据,这在某些情况下可以将查询延迟提高 10,000 倍以上。
是否有集群版本,我该如何尝试?
为了实现多节点部署,TimescaleDB 2.0 引入了 分布式超表的概念。
常规超表是我们初的创新之一,它是 TimescaleDB 中的一个虚拟表,它在一台机器上自动将数据划分为许多子表(“块”),并根据需要不断创建新的子表,同时提供单个连续的错觉整个时间的表。
分布式超表是一种超表,它自动将数据划分为跨多台机器的块,同时始终保持单个连续表的错觉(和用户体验)。
TimescaleDB 目前是否在生产中使用?
是的。TimescaleDB 目前部署在多个行业的生产中,包括制造、能源、公用事业、采矿、石油和天然气、金融、广告技术、智能空间等。
TimescaleDB 是一个不错的选择:
如果您和您的组织中的更多人想要对时间序列数据进行标准 SQL 查询,即使是大规模的。大多数(全部?)NoSQL 数据库需要学习一种新的查询语言或使用充其量是“SQL-ish”的东西(这仍然会破坏与现有工具的兼容性并导致一定程度的心理摩擦)。
如果您需要(或希望)只为您的关系和时间序列数据管理一个数据库。否则,用户通常需要将数据存储到两个数据库中:一个“普通”关系数据库,另一个是时间序列数据库。
如果您想要 JOIN,它允许您在数据库层一起查询关系和时间序列数据,并且可能完全消除在应用程序层开发此功能的需要(阅读:释放开发人员资源)。
如果您想要一组不同查询的查询性能。更复杂的查询通常是对 NoSQL 数据库的慢速或全表扫描,而一些数据存储甚至无法支持许多自然查询。
如果你想简化数据库管理。TimescaleDB 可以像 PostgreSQL 一样进行管理,并继承其对各种数据类型和索引(B-tree、hash、range、BRIN、GiST、GIN)的支持。
如果需要支持地理空间数据。TimescaleDB 中存储的数据可以利用 PostGIS 的几何数据类型、索引和查询。
如果您在使用第三方工具时需要更多选择。TimescaleDB 支持任何说 SQL 的东西,包括整个 PostgreSQL 生态系统。
如果您已经使用并喜欢 PostgreSQL,并且不想放弃它并迁移到 NoSQL 系统以扩展到更大的数据量。
如果由于扩展问题或问题,您已经选择放弃 PostgreSQL 或其他关系数据库而使用 Hadoop/NoSQL 系统。我们为迁移回来提供支持。
如果我的用例是简单的键值读取怎么办?
对于这种情况,内存或面向列的数据库设计用于具有快速查找的键值存储,而关系数据库可能并不理想。但是,这些系统显然无法扩展到大数据量,并且无法很好地执行更复杂的查询,而 TimescaleDB 和 PostgreSQL 等关系数据库更适合这些查询。
如果我有非常稀疏或非结构化的数据怎么办?
TimescaleDB 利用 PostgreSQL 对 JSON/JSONB 格式的支持并非常有效地处理稀疏性(NULL 值的位图)。但是,根据您的方案,有一些佳实践和建议可能适用于获得佳性能。请参阅这些文档中的讨论或加入我们的 Slack 组。
常见问题解答 - 关于时间序列数据库
为什么时间序列数据很重要?
在 Timescale,我们致力于为世界各地的开发者提供服务,使他们能够构建卓越的数据驱动产品来衡量所有重要事项:软件应用程序、工业设备、金融市场、区块链活动、消费者行为、机器学习模型、气候变化等. 跨时间维度分析这些数据(“时间序列数据”)使开发人员能够了解当前正在发生的事情、正在发生的变化以及发生变化的原因。
这可能是测量土壤的温度和湿度,以帮助农民应对气候变化。或者测量航班数据以预测航空公司和旅客的着陆和到达时间。或者跟踪用户在应用程序中执行的每个操作,以及该应用程序底层基础设施的性能,以帮助解决支持问题并提高客户满意度。但这些只是开发人员使用时间序列数据来衡量当今所有重要事物的数千种不同方式中的一小部分。
为什么要建立另一个时间序列数据库?
时间序列数据出现在越来越多的地方:监控和 DevOps、传感器数据和物联网、财务数据、物流数据、应用程序使用数据等等。通常,这些数据量大且性质复杂(例如,与单个时间相关的多次测量和标签)。这意味着存储时间序列数据需要规模化和高效的复杂查询。然而,实现这两个特性仍然难以捉摸。用户通常面临在 NoSQL 的水平可扩展性和关系数据库的查询能力之间进行权衡。我们需要同时提供两者的东西,所以我们建造了它。
常见问题解答 - 使用 TimescaleDB
我可以使用 TimescaleDB 做什么?
TimescaleDB 非常适合从 SQL 接口中受益的时间序列工作负载。SQL 有很多好处:大多数开发人员已经知道的查询语言;丰富的功能和实用程序;以及广泛的工具、连接器和可视化选项生态系统。此外,由于 TimescaleDB 本身支持 SQL JOINS,因此可以在查询时组合来自不同来源的数据(例如,将存储在 PostgreSQL 表中的关系数据与存储在 TimescaleDB 超表中的时间序列数据组合起来)。这种将关系数据与时间序列数据一起存储的能力使开发人员能够简化他们的堆栈,有可能将复杂的多语言架构简化为单个操作分析数据库。
由于这些优势,TimescaleDB 目前部署在多个行业,包括制造业、能源、公用事业、采矿、石油和天然气、金融、广告技术、智能空间等。用例包括复杂的监控和分析;预测应用程序、模型、消费者和连接机器的性能和行为;为运营分析工作流程和仪表板提供动力;以及 QA 和性能测试。
如何写入数据?
只是通过普通 SQL,但这里有一些插入示例。
如何读取数据?
只是通过普通 SQL,但这里有一些查询示例。
我的压缩选项有哪些?
从 v1.5 开始,TimescaleDB 支持使用混合行/列方法与特定类型压缩算法(例如,时间戳、整数、浮点数、字符串或其他数据的不同压缩算法)的本机压缩。许多用户看到他们的存储空间减少了 90-98%,从而显着节省了成本(以及其他查询性能改进)。请注意,必须为超表显式打开和配置压缩;压缩默认关闭。有关如何使用 TimescaleDB 压缩的更多详细信息,请参阅我们的压缩文档或在我们的博客上 进行更长时间的技术深入研究。
TimescaleDB 可以扩展多远?
在我们对标准云 VM 的内部基准测试中,我们定期将单节点 TimescaleDB 测试到 100 TB 的数据,同时保持 100-200k 行/秒(1-2 百万公制插入/秒)的插入率。多节点 TimescaleDB 可以扩展到 10+ 百万指标插入/秒,并存储 PB 级数据。您可以阅读有关 多节点 TimescaleDB 的插入和查询基准的更多信息。
TimescaleDB 旨在将流行的 NoSQL 数据库的可扩展性与 RDBMS 系统支持的本机查询复杂性相结合。继续阅读以了解有关集群的更多详细信息。
TimescaleDB 如何扩展?
TimescaleDB 的架构利用了时间序列数据的两个关键属性:
时间序列数据在很大程度上是不可变的。新数据不断到达,通常作为对新时间间隔的写入(插入),而不是对现有记录的更新。
工作负载具有跨时间和空间的自然分区。
TimescaleDB 通过自动将数据划分为二维块来利用这些属性,这些块的操作类似于较小的 PostgreSQL 表,执行操作并优化所有块的查询计划。将数据划分为块可确保在将数据插入数据库时将近表的索引保存在内存中。然而,所有这些复杂性都是从用户那里抽象出来的,他们暴露在一个表接口(“超表”)中,该接口的功能与 PostgreSQL 中的普通表完全一样。有关更多信息,请参阅此博客文章: 时间序列数据:为什么(以及如何)使用关系数据库而不是 NoSQL。
什么是超表和块?
我们的文档更深入地描述了这些设计元素。
我应该如何配置分块?
请参阅我们文档的佳实践部分。
如何跨空间维度确定超表块?
所有超表块都会随时间自动分区,这对于正确调整块大小是必要的,这样表索引的 B 树可以在插入期间驻留在内存中,以避免在修改这些树中的任意位置时可能发生的颠簸。此外,在创建超表时,用户可以选择在设备 ID、客户 ID 或其他 ID 上跨空间维度(分区键)进行分区。空间分区使用散列:每个不同的项目都散列到 N 个桶之一。空间分区的主要目的是在为单个设备/客户/代码定期执行范围查询时启用并行 I/O 到相同的时间间隔或构建更小的表。有关空间分区的更多详细信息,请参阅佳实践。
如何安装 TimescaleDB?
请参阅我们的安装文档。
如何更新现有安装?
请参阅我们的更新文档。
常见问题 - 与 PostgreSQL 比较
为什么我要在香草 PostgreSQL 上使用 TimescaleDB?
阅读我们的 TimescaleDB-PostgreSQL 基准测试:
TimescaleDB 与 PostgreSQL 的时间序列数据
PostgreSQL 10 用于时间序列数据的问题
总而言之,TimescaleDB 提供:
易用性:TimescaleDB 更容易使用,因为创建分区(或我们称之为“块”)是自动为用户执行的。自动分区的所有复杂性都被抽象到一个超表后面,用户可以像使用 PostgreSQL 表一样与之交互。
更高的摄取规模:一旦表达到中等大小(例如,数千万行),TimescaleDB 的吞吐量是 PostgreSQL 的 20 倍以上。虽然 vanilla PostgreSQL 适用于低容量的时间序列数据,但它不能很好地扩展到大多数时间序列应用程序产生的数据量,尤其是在单个服务器上运行时。特别是 vanilla PostgreSQL 对中等表的写入性能很差,而且随着数据量随时间线性增长,这个问题只会随着时间的推移而变得更糟。当表索引不再适合内存时,这些问题就会出现,因为每次插入都会转换为许多磁盘提取以交换索引的 B-Tree 的一部分。TimescaleDB 通过大量使用时空分区来解决这个问题,即使在运行时也是如此在一台机器上。因此,对近时间间隔的所有写入都仅对保留在内存中的表,因此更新任何二级索引也很快。
卓越的(或类似的)查询性能:在 TimescaleDB 中,可以专门针对时间排序进行推理的查询性能更高(快 1000 倍)。至少在单磁盘机器上,许多仅执行索引查找或表扫描的简单查询在 PostgreSQL 和 TimescaleDB 之间的性能相似。
更快的数据删除:为了节省空间或实施数据保留策略,普通 PostgreSQL 需要昂贵的“清理”操作来对与此类表关联的磁盘存储进行碎片整理。TimescaleDB 通过指定要删除的早于指定时间段的数据来避免清理操作并轻松实施数据保留策略。有关详细信息,请参阅数据保留。
扩展的面向时间的功能:TimescaleDB 包括原始 PostgreSQL 中不包含的时间序列特定功能,并且完全是 TimescaleDB 独有的(例如
time_bucket
、first
和last
),未来还会有更多功能。
TimescaleDB 与 PostgreSQL 的兼容性如何?
TimescaleDB 是作为 PostgreSQL 的扩展实现的,它引入了透明的可扩展性和性能优化,以及时间序列特定的功能(例如,任意聚合、数据保留策略)。TimescaleDB 与任何和所有与标准 PostgreSQL 连接器通信的第三方工具相连。TimescaleDB 支持与 PostgreSQL 相同的扩展、工具和驱动程序。您可以继续运行现有的 PostgreSQL 数据库并使用当前的可视化和报告工具。
TimescaleDB 如何处理地理空间数据?
作为 PostgreSQL 的扩展,TimescaleDB 与 PostGIS 配合得很好。例如, 请参阅我们在纽约出租车数据上使用 PostGIS 和 TimescaleDB的教程。
常见问题 - 社区
什么是 TimescaleDB 开源许可证?
阿帕奇 2.0。
有我可以加入的 TimescaleDB 社区或组吗?
是的!我们在 Slack 中有一个非常活跃的在线社区,您可以在我们的GitHub页面上报告任何问题。
我可以获得支持或商业许可吗?
是的。请与我们联系以获取更多信息。
我在哪里可以获得 TimescaleDB 源代码?
请参阅GitHub。
来源 https://mp.weixin.qq.com/s/7FHBoZ7qWhNmxiI2hvNwbQ
相关文章