Spa*_*key 66 database influxdb prometheus
在普罗米修斯网页之后,普罗米修斯和InfluxDB之间的一个主要区别就是用例:普罗米修斯存储时间序列只有InfluxDB更适合存储个别事件.由于在InfluxDB的存储引擎上做了一些重要工作,我想知道这是否仍然如此.
我想设置一个时间序列数据库,除了推/推模型(可能是性能上的差异),我看不出两个项目分开的大事.有人可以解释用例的区别吗？
Pau*_*Dix 81
这里有InfluxDB CEO和开发人员.下一版本的InfluxDB(0.9.5)将拥有我们的新存储引擎.使用该引擎,我们将能够有效地存储单个事件数据或定期采样系列.即不规则和规则的时间序列.
InfluxDB支持使用不同压缩方案的int64,float64,bool和字符串数据类型.普罗米修斯只支持float64.
对于压缩,0.9.5版本将具有与Prometheus竞争的压缩性.在某些情况下,我们会看到更好的结果,因为我们会根据我们看到的内容改变时间戳上的压缩.最佳案例场景是以固定间隔采样的常规系列.在那些默认情况下,我们可以压缩1k点时间戳作为8字节的开始时间,delta(Z字形编码)和计数(也是zig-zag编码).
根据我们所见的数据形状,压缩后平均每点2.5个字节.
YMMV基于您的时间戳,数据类型和数据的形状.例如,具有大的可变增量的纳秒级时间戳的随机浮点数将是最差的.
时间戳中的变量精度是InfluxDB的另一个特性.它可以表示秒,毫秒,微秒或纳秒刻度时间.普罗米修斯固定在几毫秒.
另一个区别是,在向客户端发送成功响应后,对InfluxDB的写入是持久的.Prometheus缓冲区在内存中写入,默认情况下每隔5分钟刷新一次,这会打开一个潜在数据丢失的窗口.
我们希望一旦0.9x版本的InfluxDB发布,它将是普罗米修斯用户使用长期指标存储(与Prometheus一起使用)的不错选择.我很确定Prometheus已经支持了,但在0.9.5版本下降之前它可能会有点不稳定.显然,我们必须共同努力并进行一系列测试,但这正是我所希望的.
对于单服务器度量标准的提取,我希望Prometheus能够获得更好的性能(尽管我们没有在这里进行测试并且没有数字),因为它们的数据模型更受限制,并且因为它们在写出索引之前不会将写入附加到磁盘.
两者之间的查询语言非常不同.我不确定他们支持我们还没有,反之亦然,所以你需要深入研究两者的文档,看看是否有你可以做的事情.从长远来看,我们的目标是使InfluxDB的查询功能成为Graphite,RRD,Prometheus和其他时间序列解决方案的超集.我说超集是因为我们想要在以后更多的分析函数中覆盖那些超集.显然我们有时间去那儿.
最后,InfluxDB的长期目标是通过群集支持高可用性和水平可伸缩性.当前的群集实现尚未完成功能,仅在alpha中.但是,我们正在努力,这是该项目的核心设计目标.我们的聚类设计是数据最终是一致的.
据我所知,Prometheus的方法是对HA使用双写(因此没有最终的一致性保证)并使用联合进行水平可伸缩性.我不确定如何跨联合服务器进行查询.
在InfluxDB集群中,您可以跨服务器边界进行查询,而无需通过网络复制所有数据.这是因为每个查询都被分解为一种可以即时运行的MapReduce作业.
可能还有更多,但这就是我现在能想到的.
use*_*461 33
我们在其他答案中得到了两家公司的营销信息.现在让我们忽略它,回到时间数据系列的悲惨现实世界.
InfluxDB和prometheus被用来取代过去时代的旧工具(RRDtool,graphite).
InfluxDB是一个时间序列数据库.Prometheus是一种度量标准收集和警报工具,其中只有一个存储引擎.(我实际上不确定你是否可以[或者应该]重复使用存储引擎)
遗憾的是,编写数据库是一项非常复杂的任务.这些工具设法运送的唯一方法是删除与高可用性和群集相关的所有硬件功能.
说白了,它是一个只运行单个节点的应用程序.
Prometheus没有任何目标支持群集和复制.支持故障转移的官方方法是" 运行2个节点并将数据发送给它们 ".哎哟.(请注意,它是唯一可行的现有方式,它在官方文档中写了无数次).
InfluxDB多年来一直在谈论集群......直到3月份正式放弃.对于InfluxDB,群集不再存在于桌面上.把它忘了吧.当它完成时(假设它曾经)它将只在企业版中可用.
https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/
在未来几年内,我们希望拥有一个精心设计的时间序列数据库,它可以处理与数据库相关的所有难题:复制,故障转移,数据安全,可扩展性,备份......
目前,没有银弹.
评估预期的数据量.
100个指标*100个来源*1秒=>每秒10000个数据点=>每天864个兆位数据点.
时间序列数据库的优点在于它们使用紧凑格式,压缩良好,聚合数据点,并清理旧数据.(另外,它们还具有与时间数据系列相关的功能.)
假设数据点被视为4个字节,那么每天只有几千兆字节.幸运的是,有10个核心和10 TB驱动器的系统随时可用.这可能在单个节点上运行.
另一种方法是使用经典的NoSQL数据库(Cassandra,ElasticSearch或Riak),然后设计应用程序中的缺失位.这些数据库可能没有针对那种存储进行优化(或者是现代数据库是如此复杂和优化,除非进行基准测试,否则无法确定).
您应该评估应用程序所需的容量.用这些不同的数据库写出概念证明并测量事物.
看看它是否属于InfluxDB的限制.如果是这样,那可能是最好的选择.如果没有,你将不得不在其他方面做出自己的解决方案.
小智 17
InfluxDB根本无法保存1000台服务器的生产负载(指标).它在数据摄取方面存在一些实际问题,最终导致停滞/挂起和无法使用.我们尝试使用它一段时间,但一旦数据量达到某个临界水平,它就不能再使用了.没有内存或CPU升级帮助.因此,我们的经验肯定是避免它,它不是成熟的产品,并有严重的建筑设计问题.我甚至没有谈论Influx突然转向商业广告.
接下来我们研究了普罗米修斯,虽然它需要重写查询,但它现在摄取了4倍的指标,与我们尝试提供给Influx相比没有任何问题.所有这些负载都由单个Prometheus服务器处理,它快速,可靠,可靠.这是我们在相当沉重的负荷下经营庞大的国际网络商店的经验.
IIRC当前的Prometheus实现是围绕单个服务器上的所有数据进行设计的.如果您拥有大量数据,则可能并非所有数据都适合普罗米修斯.
| 归档时间： |
|
| 查看次数： |
37523 次 |
| 最近记录： |