https://www.diglog.com/story/1032055.html
经过两年的专门设计和用户反馈，TimscaleDB 2.0终于问世了，它为时间序列数据库树立了一个新的标杆-而且它是完全免费的。
时间序列数据无处不在。无论您是在监控您的软件堆栈、用户、生产线、家庭、车辆、股票和加密货币组合、您家中的空气质量，还是只是在大流行期间监测您的健康状况，您都在收集时间序列数据。随着软件继续无情地渗透到我们的生活和业务中，时间序列数据正变得更加无处不在，而且对任务至关重要。
与此同时，关系数据库这一古老的坚定不移的数据库正在卷土重来，成为软件应用程序的首选数据库。尽管多年来一直在炒作NoSQL，但目前使用最多的4个数据库都是关系数据库。此外，PostgreSQL是去年增长最快的数据库(是的，甚至比MongoDB还快)。
开发人员需要的是一种新的数据库，专为时间序列工作负载而构建，同时完全采用关系模型。毕竟，你的时间序列数据并不存在于真空中。能够将其与技术元数据、业务数据和结果相关联，对于了解您的软件、系统、运营和业务如何随时间变化至关重要。
构建该数据库一直是我们的使命：帮助开发人员以快速、可靠和经济高效的方式存储和分析时间序列数据，以便他们可以专注于核心应用程序并取悦他们的用户。
自3.5年前推出以来，TimscaleDB已证明自己是领先的时序数据关系数据库，基于PostgreSQL进行设计，并通过免费软件或作为AWS、Azure和GCP上的完全托管服务提供。
在此期间，TimscaleDB社区已成为最大的时序数据开发者社区：数千万下载量；超过500,000个活动数据库；AppDynamics、博世、思科、康卡斯特、瑞士信贷、DigitalOcean、陶氏化学、艺电、富士通、IBM、微软、Rackspace、施耐德电气、三星、西门子、优步、沃尔玛、华纳音乐、WebEx等数以千计的组织；所有这些都是PostgreSQL社区和生态系统之外的。
在此2.0版本中，TimscaleDB现在是用于时间序列的分布式、多节点、PB级关系数据库。而且，我们在这个版本中的所有内容都是完全免费的。这是两年来专心致志的工程努力的结果，也是用户对之前几个测试版的重要反馈。
事实上，用户在连续日常使用中运行多节点TimscaleDB已经有好几个月了，包括一家财富100强科技公司每天吞噬超过10亿行的22节点集群：
我们不断地将遥测事件接收到TimscaleDB 2.0中，以监控和分析大量会话。在过去的几乎一年里，我们一直在22台服务器上运行TimscaleDB多节点，每天接收超过10亿行数据。TimscaleDB的性能、规模、关系和SQL功能，以及处理复杂数据的能力一直是真正的赢家。&拉胡尔，财富100强科技公司的技术主管。
Netskope以速度和可扩展性而自豪，我们严重依赖时间序列数据来计划、监控和排除我们由数千台服务器组成的全球网络的故障。有了TimscaleDB，我们可以利用无处不在的PostgreSQL生态系统，并使用TimscaleDB的连续聚合和其他内置的时间序列功能进行实时分析和高级历史分析。现在有了多节点TimscaleDB，我们获得了我们现在和将来大规模监控和管理我们的系统所需的水平可扩展性和快速吞吐能力。“-Netskope公司的系统架构师马克·S·雷伯特博士(Mark S.Reibert，Ph.D.)。
更新、更宽松的许可：使我们所有的企业功能都是免费的，并向用户授予更多权限。
对连续聚合的实质性改进：改进API并让用户更好地控制流程。
用户自定义操作(新功能！)：用户现在可以在数据库中定义自定义行为，并使用我们的作业调度系统对其进行调度。
TimscaleDB 2.0候选版本立即可用于自我管理软件安装，预计在2020年后期全面上市。届时，TimscaleDB 2.0将在我们的托管时间系列服务上提供。如果您已经在使用TimscaleDB，我们已经创建了详细的文档来简化和加速您的迁移。
我们也鼓励您加入我们5,000+会员的Slake社区，有任何问题，了解更多，并与志同道合的开发人员会面-我们在所有渠道都很活跃，并在此提供帮助。
(虽然Ajay和Mike被列为这篇文章的作者，但Timescale数据库团队的成员在几个小时、几周和几个月的时间里一直致力于交付高质量的代码：Erik Nordström、Gayathri Ayyappan、Ruslan Fomkin、Mats Kindahl、Sven Klemm、Brian Rowe和Dmitry Simonenko，这是他们的全部荣誉和热烈的掌声。)。
我们非常感谢我们所有的测试版测试人员；从报告问题到分享反馈和建议特性，你们都为使TimscaleDB 2.0成为开发人员最好的体验发挥了重要作用。
要了解有关TimscaleDB2.0、时间序列数据的更多信息，以及为什么我们认为关系数据库是软件开发的过去和未来，请继续阅读。
大约30年来，从20世纪70年代中期到2000年代中期，如果您在开发软件，您使用的是关系数据库。从System R(1974)到Oracle(1979)、SQL Server(1989)，再到后来的开源选项，如MySQL(1995)和PostgreSQL(1996)，关系数据库是任何新应用程序的标准。
大约15年前，这一切都改变了。非关系数据库，有时也称为“NoSQL”数据库，变得流行起来。很多这样的用法都是合法必要的。新的互联网巨头建造了新的系统来处理以前深不可测的数据量，例如，谷歌(Google)推出了MapReduce(2004年)和Bigtable(2006年)；亚马逊(Amazon)推出了Dynamo(2007年)。但是，大量采用NoSQL是下意识的反应，大致是这样的：“关系数据库不能伸缩，所以我需要一个NoSQL数据库。”
然而，大多数公司都不是谷歌或亚马逊。事实证明，以保留数据集中关系的方式存储数据的能力很有价值。在生产中使用了几十年之后，大多数关系数据库都是经久耐用的，通常比它们的NoSQL表亲更可靠。SQL也重新成为数据分析的通用语言，是当今第三广泛使用的语言(仅次于JavaScript和HTML/CSS)。
今天，使用最多的4个数据库仍然都是关系数据库。特别值得一提的是，PostgreSQL是去年增长最快的数据库(是的，甚至比MongoDB还快)。其中一些来自改换过来的开发人员；另一些来自从未离开关系数据库的开发人员。所以不要称它为卷土重来-关系数据库已经在这里存在了很多年了(h/t James Todd Smith)。
最重要的是，关系数据库实际上可以伸缩。我们在最近的“NewSQL”数据库浪潮中看到了这一点。近十年前，谷歌再次走在了前列，在他们的第一篇Spanner论文(2012年)(作者包括MapReduce的原始作者)中宣布了一个地理复制的关系数据库，紧随其后的是其他先驱，如CockroachDB(2014)和Yuabyte(2016)。有了TimscaleDB(2017)，我们已经建立了一个可针对时间序列数据进行缩放的关系数据库。
简而言之，时间序列是跨越时间的事物的度量。但是，更深入地挖掘，时间序列数据是对事物如何变化的度量。
如果我寄给你10美元，那么一个传统的银行数据库会自动记入我的账户的借方，并记入你的账户的贷方。然后，如果你寄给我10美元，同样的过程会发生相反的情况。
在这个过程结束时，我们的银行余额看起来是一样的，所以银行可能会想，“哦，什么都没发生。”这就是传统数据库会向你展示的。
但是，有了时间序列数据库，银行可以看到，“嘿，这两个人一直在互相寄10美元--也许他们是朋友，也许他们是室友，也许有其他事情发生。”这种粒度水平，即对事物如何变化的度量，正是时间序列所能实现的。
换句话说，时间序列数据集以插入(而不是更新)的形式跟踪对整个系统的更改，以捕获有关正在发生的事情的更多信息。
时间序列过去是小众的，孤立于金融、流程制造(例如，石油和天然气、化工、塑料)或电力和公用事业等行业。但在过去几年中，时间序列工作负载呈爆炸式增长(这是过去24个月中增长最快的类别)。这在一定程度上是由于IT监控和物联网的增长，但也有许多其他新的时间序列数据来源：加密货币、游戏、机器学习等。
正在发生的情况是，每个人都希望更快地做出更好的数据驱动决策，这意味着以尽可能高的保真度收集数据。时间序列是您可以捕获的最高保真度的数据，因为它准确地告诉您事情是如何随着时间的推移而变化的。传统数据集为您提供静态快照，而时间序列数据则提供整个系统中正在发生的事情的动态电影：例如，您的软件、物理发电厂、游戏、应用程序中的客户。
时间序列不再是一些小众的工作负荷。它无处不在。事实上，所有数据都是时间序列数据-如果您能够以这种保真度存储它的话。当然，这就是收集时间序列数据的问题：它是无情的。通过执行所有这些插入，而不是更新，您最终会以比以往更高的容量和速度获得更多的数据。您很快就会看到数十亿行中的表。对于传统数据库来说，这在性能和可伸缩性方面带来了挑战。
TimscaleDB是领先的时间序列数据关系数据库。Timescale基于PostgreSQL设计，可以通过免费软件获得，也可以作为AWS、Azure和GCP上的完全托管服务使用。
TimscaleDB是专门为时间序列工作负载构建的，因此您可以以极少的成本获得数量级的性能提升，以及更好的开发体验。这意味着巨大的规模(单个服务器上每秒数千亿行和数百万次插入)、94%以上的本机压缩、比PostgreSQL、InfluxDB、Cassandra和MongoDB快10-100倍的查询速度-所有这些都保持了PostgreSQL的可靠性、易用性、SQL接口和整体优势。
如今，存储时间序列数据有几种选择。然而，大多数是非关系系统，本质上是美化的度量存储，专注于存储数字数据，而不是时间序列工作负载所需的广泛的数据类型(也不是数据集之间关系的丰富表示)。
2017年4月，我们将TimscaleDB作为第一个支持全SQL的时序数据库，进入了这个充斥着非关系型指标存储的世界。从那时起，其他许多人已经将我们的SQL方法复制到时间序列中(包括一些名称非常可疑的方法，*咳嗽*Amazon Time Stream*咳嗽*)，但没有人能够复制TimscaleDB的真正关系基础和社区。
因此，在短短3.5年的时间里，TimscaleDB已经取得了长足的进步，现在已经有了数千万的下载量和超过50万个活动数据库。TimscaleDB开发人员社区包括AppDynamics、博世、思科、康卡斯特、DigitalOcean、陶氏化学、电子艺界、富士通、IBM、微软、Rackspace、施耐德电气、三星、西门子、优步、沃尔玛、华纳音乐、WebEx等数以千计的组织。
除了这个专门的社区，我们还受益于庞大的PostgreSQL社区和生态系统。总而言之，TimscaleDB社区是最大的时间序列数据开发社区。
自从我们推出TimscaleDB以来，我们就遇到了质疑。毕竟，在PostgreSQL上构建时间序列数据库是一个不明显的、有点异端的决定。然而，随着每一次发布，我们继续反驳我们的仇恨者，并取悦我们的用户。因为，事实证明，为时间序列构建一个可伸缩的关系数据库并不是不可能的-只是很难。但是，凭借我们才华横溢的团队和热情的用户，我们正在做这件事。
误区1：关系型数据库不能像非关系型数据库那样具有伸缩性
事实：对于时间序列数据，我们的性能优于非关系(和其他关系)数据库。与Cassandra相比，插入速度提高了10倍，查询速度提高了1000倍。与Mongo相比，插入速度提高了20%，查询速度提高了1400倍。与InfluxDB相比，插入更多、查询更快、可靠性更高。(与所有这些选项不同，我们还支持完整的SQL，这允许用户使用编程语言和他们已经知道的工具对其数据运行复杂的分析。)。
误区2：关系数据库占用太多磁盘空间(或者，面向行的数据库不能像列式数据库那样压缩)。
事实：可以在面向行的数据库中构建列压缩，这正是我们所做的。TimscaleDB采用了几种同类最佳的压缩算法，包括Delta-Delta、Gorilla和SIMPLE-8bRLE，使我们能够实现94%以上的本机压缩。
事实：每个数据库，无论是关系数据库还是非关系数据库，都使用模式来存储数据。唯一的区别是您是否有能力修改该模式并根据您的使用对其进行优化。但是，自动为您生成模式是很有用的。我们已经在探索自动模式：例如，请参阅Promscale，这是我们为普罗米修斯构建的基于TimscaleDB的新分析平台，它将数据存储在针对指标高度优化的动态自动生成模式中。还会有更多。
事实：NewSQL数据库(如上所述)驳斥了事务性工作负载的这一神话。今天，我们将用TimscaleDB 2.0为时间序列工作负载驳斥这一神话。
如上所述，客户在连续的日常使用中运行多节点TimscaleDB已经有好几个月了，其中包括一家财富100强科技公司每天吞噬超过10亿行的包含22台服务器的集群。
常规超级表是我们的原创性创新之一，它是TimscaleDB中的一个虚拟表，它自动将数据分区到单个机器上的多个子表(“块”)中，根据需要不断创建新的子表，同时始终提供单个连续表的错觉。
分布式超级表是一个超级表，它自动跨多台机器将数据分区为块，同时始终保持单个连续表的错觉(和用户体验)。
该体系结构由一个访问节点(AN)和一组数据节点(DN)组成，前者存储分布式超级表的元数据并跨集群执行查询规划，后者存储分布式超级表数据集的子集并在本地执行查询。*为简化操作，TimscaleDB仍然是一个单一软件；上述角色是通过在TimscaleDB内执行数据库命令来建立的(例如，在应该充当访问节点的服务器上，添加指向数据节点主机名的_DATA_NODE，然后添加_Distributed_HYPERTABLE。)。
目前，您可以添加任意数量的数据节点以实现水平可伸缩性，还可以利用数据节点上现有的Postgres物理复制来实现容错(我们还在为将来的版本开发更多本机复制；请参见下文)。
访问节点还可以进行物理复制以实现高可用性，未来的版本将侧重于进一步扩展TimscaleDB多节点的读写路径。
因此，传统的超级表格可以扩展到每秒100-200万个指标和100 TB的数据，而分布式超级表格则可以扩展到每秒接收1000多万个指标并存储PB级的数据：
分布式超表还利用查询并行化，采用完全/部分聚合和下推，以实现更快的查询：
我们已经在努力改进这个分布式超级表的初始版本，并提供以下一系列功能：
复制：目前每个节点都需要自己的复制(使用主/备份物理复制)。针对TimscaleDB本机构建的跨数据节点的群集范围复制正在开发中。
重新平衡：目前，当新数据节点灵活地添加到现有分布式超级表中时，会跨可用节点创建新的区块，并相应地路由查询以识别重新分区。但与本机复制相关，现有区块目前没有跨节点重新平衡，这也在开发中。
备份：每个节点都可以备份和还原，但目前在整个群集上没有一致的还原点快照。群集范围的备份也在开发中。
压缩：当前必须以块为单位执行压缩。将来，访问节点上的压缩策略，然后传播到每个数据节点将成为可能。
一些功能，如连续聚合和TIME_BUCK_GAPFILL，目前不适用于分布式超级表。这些也在开发中。
请查看下面的讲解视频，了解分布式超级表格的工作原理、何时以及为什么要使用它们、最佳实践等详细信息。
更新、更宽松的许可：使我们所有的企业功能都是免费的，并向用户授予更多权限。
对连续聚合的实质性改进：改进API并让用户更好地控制流程。
用户自定义操作(新功能！)：用户现在可以在数据库中定义自定义行为，并使用我们的作业调度系统对其进行调度。
TimscaleDB 2.0引入了Timescale许可证的更新，这是我们的源代码可用许可证，用于管理我们的大多数高级功能，包括本机压缩、多节点、连续聚合等。
此更新使我们所有的企业功能都是免费的，并为用户提供了扩展的权限，加强了我们对社区的承诺。值得注意的是，此更新增加了“维修权”、“改进权”，并完全取消了付费企业层和使用限制(从而确定我们所有的软件都将是免费的)。(更多信息请参见本公告。)。
连续聚合是一项现有功能(1.5年前在TimscaleDB 1.3中引入)，它可以在后台自动计算查询结果并将结果具体化，从而大大加快查询速度。它们与PostgreSQL实体化视图有点类似，但与实体化视图不同的是，连续聚集不需要手动刷新；视图在添加新数据或修改旧数据时会在后台自动刷新。(有关更多详细信息，请参阅我们的连续聚集文档。)。
TimscaleDB 2.0包括对连续聚集的实质性改进(因此，还包括一些突破性的API更改)：
更新了将功能和策略分开的API，让用户可以更好地控制连续聚合过程。例如，现在可以在给定范围内手动刷新连续聚合。一个常见的用户请求是物化最新数据，但将历史数据留给手动刷新。现在这是可能的。
功能和策略的分离也使得此功能在将来更适合分布式操作(例如，多节点)。例如，访问节点上的策略可以触发数据节点上的刷新。
因此，对连续聚集(突出显示)进行了一些突破性的API更改。