浅析时序数据库评测和选型的区别_时序数据库 开源

浅析时序数据库评测和选型的区别_时序数据库 开源时序数据库评测,时序数据库选型,松果时序数据库

大家好,又见面了,我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE稳定放心使用

时序数据库是近两年的热门话题,不断有新的时序数据库产品发布,但在我个人看来,目前还没有看到一个系统的、全面的时序数据库评测方案,帮助开发者认识各个产品的异同,为特定场景选择最适合的产品,各个数据库厂商基于自身优势和特点,设计发挥其产品最佳性能的场景,展示一份份傲人的性能测试报告。本篇博客就结合本人的一些看法,从不同维度来分析时序数据库产品的异同,同时也希望有更多的人关注时序数据库,在各自的行业应用需求上为时序数据库厂商建言献策,共同推动时序数据库的发展。由于个人能力有限,难免有不妥之处,还望大家提出宝贵意见,多多批评指正。

首先对本文提到的一些名词做相应的解释:

对象:本文所述对象是能够持续产生数据的实体,也是时序数据库数据建模的对象,例如:传感器、电梯、自行车等。

时间线:为了将同一个对象在不同时间点产生的数据组织在一起而提出的数据管理单元。各个时序数据库对时间线有不同的称呼,例如:松果时序数据库的“设备”、influxDB的“Measurement和Tags的组合”、TDEngine的“子表”以及实时数据库的“测点”。实际上他们表达的是同一个概念,命名不同而已。

其次通过以下几个维度来浅析时序数据库评测和选型:

(1)支持时间线的数量

时序数据库能够支持时间线的数量?每个时间线需要消耗的资源?

(2)对象是否确定?

场景一:公交公司将公交车运行的位置、营运状态等信息写入时序数据库。此时对象是公交车,对象是确定的,不会爆发式增长。

场景二:互联网公司将用户的访问记录写入时序数据库。如果将用户作为对象,此时对象是不确定的,可能爆发式增长,也有可能某用户访问后就不再访问。

对象是否确定这项指标在实际场景中影响非常大,应重点考量、对比各个时序数据库的差异,选择最适合实际场景的产品。

(3)数据产生的频率

场景一:智能电表每15分钟产生一条数据,900万个智能电表平均每秒产生一万条数据。

场景二:某智能设备(欢迎补充)每秒钟产生一千条数据,10个设备合计每秒产生一万条数据。

上述两个场景每秒都产生一万条数据,因此在选择数据库时应充分考虑数据产生的频率并做相应的测试以满足需求。

(4)不要把沙子装在金库里

不同的时序数据的价值密度差异巨大,例如:股票产生的时序数据和环境监测产生的时序数据价值密度相差巨大。他们对数据安全性和分析处理有着截然不同的要求。没有人愿意为处理环境监测的数据支付金融级解决方案的成本。因此需要针对不同的场景选择适宜的时序数据库产品。

(5)分析性功能

时序数据库是否支持复杂查询(排序、聚合、子查询、多表连接等),典型的代表是TimescaleDB,他基于PostgreSQL实现能够支持各种复杂的SQL查询,另外一些时序数据库不支持或支持受限的复杂查询。并不是支持复杂查询就比不支持好!例如:在关系库中时常发生由于一个复杂的SQL导致数据库服务hang住了。在时序数据库中亦是如此,很多时序数据库系统每天都会写入几亿条、几十亿条甚至更多的数据,对上亿条的数据进行排序、聚合是一个灾难,松果时序数据库不支持复杂查询,因而能够轻易做到只要数据库支持的查询都不会因为某一个任务占用过多的内存或磁盘资源导致其他的任务无法执行或执行失败,也不会出现任何死锁的情况,其稳定性强于支持复杂查询的时序数据库。不支持分析性功能的时序数据库可以引入额外的计算服务来达到复杂计算的功能,但是对比能支持复杂查询的数据库来讲更麻烦、灵活性更低。因此,是否选择支持分析性功能的产品需要根据实际情况权衡。

(6)单机&分布式

单机和分布式产品的对比:

单机时序数据库

分布式时序数据库

产品实现难度

简单

复杂

实施难度

简单

复杂

运维难度

简单

复杂

问题排查

简单

复杂

大规模扩容

简单

管理的时间线

从产品实现难度、实施难度、运维难度和问题排查来看,单机时序数据库比分布式时序数据库简单很多,也即一个单机数据库产品更容易研发并发布稳定版本、更易于维护。实际应用中应该以解决业务问题为导向,结合场景特点,预留一定的扩容需求,不应盲目选择分布式时序数据库。若一个业务场景不需要考虑大规模扩容的情况下,应当优先考虑单机时序数据库产品。

(7)对实时数据库的看法

业内存在些许实时数据库难以使用、价格昂贵的观点,萌发使用时序数据库替代实时数据库的想法,我个人认为:在某些应用场景中(欢迎大家补充),会因实时性无法得到保障而埋下隐患。另外,趁着时序数据库的热度,一些实时数据库厂商也发布了时序数据库的产品,虽然国内的实时数据库产品做得非常好了,但在一些核心指标上(如稳定性,欢迎大家补充)与国外一流产品存在一定的差距。实时数据库和时序数据库虽然在数据模型和使用上有一些相似性,实际上他们解决的是不同的问题,实时数据库厂商应更多的聚焦在如何超越PI等国外先进产品上。

最后,任何一个产品都有其适用性和局限性,完善时序数据库的评价体系才能客观、公正的对比各个产品的优势和特点及其适用场景,让时序数据库厂商充分发挥自身优势定位产品方向,研发出针对特定场景最适合的时序数据库产品,为客户提供更好的服务,这符合时序数据库厂商和客户的利益诉求。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/186098.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

  • android签名命令行,Android系统签名位置及命令

    android签名命令行,Android系统签名位置及命令app需要使用系统的权限在AndroidManifest.xml中声明了系统全下申明了系统权限android:sharedUserId=”android.uid.system”1.找到平台签名文件“platform.pk8”和“platform.x509.pem”文件位置android/build/target/product/security/2.签名工具“signapk.jar”位置…

  • android错误之android.content.res.Resources$NotFoundException:

    错误:android.content.res.Resources$NotFoundException: String resource ID #0x1原因:一般发生在参数 int resId 错误,你把String赋值给int的resId,所以编译器找不到正确的resource于是报错。最简单的例子,检查一下你的Toast.makeText()啊textView.setText啊之类的函数

  • 数据库置疑的解决方法_列族数据库

    数据库置疑的解决方法_列族数据库数据库置疑处理文档修订记录日期Date修订版本RevisionVersion修改描述ChangeDescription作者Author2010-04-261.0格式化UltraSQL目录一、知识点简介1.DBCC中的CHECKDB命令2.重置置疑状态3.sp_add_log_file_reco…

  • Alex 的 Hadoop 菜鸟教程: 第10课 Hive 安装和使用教程

    Alex 的 Hadoop 菜鸟教程: 第10课 Hive 安装和使用教程Hive提供了一个让大家可以使用sql去查询数据的途径。让大家可以在hadoop上写sql语句。但是最好不要拿Hive进行实时的查询。因为Hive的实现原理是把sql语句转化为多个MapReduce任务所以Hive非常慢,官方文档说Hive适用于高延时性的场景而且很费资源。

  • java 雪崩效应,七、微服务架构中的“雪崩效应”

    java 雪崩效应,七、微服务架构中的“雪崩效应”1.雪崩效应在微服务架构中,我们将业务拆分成一个个的服务,服务与服务之间可以相互调用,但是由于网络原因或者自身的原因,服务并不能保证服务的100%可用,如果单个服务出现问题,调用这个服务就会出现网络延迟,此时若有大量的网络涌入,会形成任务堆积,最终导致服务瘫痪。其实,在单体服务中,高并发也会导致服务瘫痪。见下一章,Jmeter模拟微服务当中的高并发场景在分布式系统中,由于网络原因或自身的原因,服…

  • DOS的Copy命令参数详解[通俗易懂]

    DOS的Copy命令参数详解[通俗易懂]原文地址::http://zhongsion.blog.163.com/blog/static/22646272008478255656/相关文章1、

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号