TimescaleDB是一个开源的数据库打包为Postgres扩展支持时间序列,但“看来这只是Postgres时间表的产品负责人说,戴安娜谢长廷。“所以你可以使用整个生态系统。您可以使用所有的功能中启用Postgres——比如JSON索引,关系表,JSON——他们所有的工作时间表。”
去年,时间表为PostgreSQL Grafana v5.3查询生成器。的新可视查询编辑器PostgreSQL数据源让用户更方便地进行探讨时间序列数据,提高数据的可发现性存储在PostgreSQL。用户可以使用下拉菜单制定与有效的查询选择具体功能和宏来表达时间序列。
“我们决定建立的原因,是因为它确实更容易患有不同程度的SQL的能力实际上为高级用户编写SQL查询,“谢告诉群众GrafanaCon。
查询构建器允许用户自动不同的列,这样“工作的人更多的devops也许只使用PromQL可以使用查询编辑器,看起来更熟悉,”谢长廷解释道。
该工具还反映了权限给每个Grafana实例。“用户将能够知道他们可以在数据库中查询哪个表,而不必实际知道底层模式在实际数据库中,”谢说。(更多关于查询生成器的功能,查看这篇博客)。
但是时间序列监测系统SQL甚至一个可行的解决方案?在GrafanaCon,谢揭穿所有的疑虑在SQL在她说话。
不是很多人都熟悉SQL
谢长廷说SQL的主要原因之一是“awesome”是因为它其实是一个非常著名的查询语言。
根据最近的堆栈溢出调查中,SQL是排在第四位最受欢迎的技术编程,脚本和标记语言。“我也做了一个快速搜索在LinkedIn有多少人知道SQL与不列出SQL的配置文件,九百万年还是几百几千,”谢说。“我认为这是真的。”
谢长廷还指出,业务分析师知道SQL。“我知道SQL在开始编码之前,”谢说。“这其实是一个非常著名的语言,跨越一个组织。”
最后,其他两个分布式非SQL数据库实际上是介绍SQL。“弹性有一个类似于sql的语言,卡夫卡KSQL甚至有一个小标志,”谢说。“这只是告诉你,甚至一些非SQL数据库也很喜欢SQL的。”
有新的数据库语言投资
执行SQL的价值超越了技术的好处。
“这是一个成本考虑,”谢说。“在一天结束的时候,我们已经意识到数据不仅仅是能够存储它。你也必须能够访问它,这发生在所有给定的架构层的。”
从微观层面,例如,韩国产业银行是一个金融公司倾向于使用特定数据库因为KDB开发人员难找,他们赚得更多的钱。“如果你考虑你选择的数据库组织的基础,考虑是多么昂贵的得到一个SQL开发人员相比,KDB开发商。”
如果你看一看大局,“如果你选择一种语言,人们不知道,你要训练你的整个组织,”谢说。否则你创建不同的筒仓风险,有些人知道如何访问别人不要的数据来源。
“不仅仅是那些感人的开发人员和业务分析师SQL,”谢说。“的人也知道如何管理SQL,知道如何构建关系模式的人,知道如何操作Postgres的人。这是一个更大的生态系统。所以这是一种投资选择,扩大整个组织,持续一段时间。”
SQL不规模
谢长廷承认这是“房间里的大象”。
“我要说,我同意这种说法,”谢说。
传统的SQL数据库优化事务性语义,这不是时间序列数据库。
用时间序列数据,不断摄取新的数据随着时间的推移,这就需要更多的存储空间。但在Postgres服务器构建用例事务,比CPU、内存和存储将会截然不同。作为一个数据集的增长,Postgres的摄入将会大大减少因为指数变得太大不能适应在RAM中了。
不过,谢长廷仍然致力于20岁的数据库语言,因为“我们认为无聊与数据库太棒了,”谢说。
所以时间尺度实现Postgres存储层。“Postgres这么有趣的是可扩展的,我们已经扯掉模式是如何管理的,我们提供我们自己的抽象层,”谢长廷解释道。“抽象层所做的是把一个大表,有很多时候系列,它会把一切分成块基于时间间隔。所以它自动分区数据。”
因此,指数不是建立在整个表。“现在当你插入数据时,所有的这些索引建在一块可以生活在记忆,”谢说。“这一切速度,你可以写东西更快的查询计划的水平。”
时间表,如果用户编写成一个表,分区下面会自动发生。如果有一个时间序列的查询,它将其路由通过一个优化的时间序列查询规划。但是如果你有一个标准的SQL,它会通过标准SQL查询。
最终,“你可以有关系数据库和时间序列数据库在同一个数据库中,”谢说。“你可以得到很多更好的性能使用时间表,你不要看到性能下降的插入…8核机器的时候,我们能够得到111万每秒。”
最后,这不是关于SQL是否可以,谢长廷说。“人们的最大挑战之一是改变时间序列框架思考如何在SQL模型它,因为它是一个不同的SQL的思考方式。”
更多的从GrafanaCon 2019,查看所有的谈判YouTube。
