InfluxDB的设计见解和权衡

原创 2018-07-19 18:21 阅读(263)次

作为时序数据库,InfluxDB在设计的时候,对一些具体问题做了优化,提高性能的同时也需要作出权衡,削减一些功能。

如下  方案一:趋向赞成问题,方案二:趋向反对问题

1. 当DB收到多次相同的数据,认为他是client多次发送了相同的数据。

方案一:赞成,为此提高性能,照单全收。InfluxDB是进行field set的整合。

方案二:反对,不支持存储重复数据,可能发生覆盖。

2. 时序数据库很少发生删除。如果发横几乎是删除大范围的旧数据,而不是删除刚刚插入的新数据。

方案一限制删除权限,增加读写性能。

方案二删除功能强烈限制。(我理解甚至不提供删除功能)


3. 更新数据很少发生,争议更新永远不会发生。永不更新新数据

方案一限制更新的权限,增加读写性能。

方案二更新功能强烈限制。(我理解甚至不提供更新功能)

4. 绝大多数的数据写入是最近的时间戳的数据(很新的数据),并且数据按时间升序排列。

方案一基于这个假设,按时间升序存储性能提高。

方案二:提供支持随机时间写入的功能,或者不按时间升序,但会造成性能较差。

5. 必须处理大量的读写并发。

方案一:可以支持大量读写并发。

方案二: 开发团队用其他方式提升性能

6. 能够读写数据比拥有强一致性更重要(这应该是可用性和强一致性的取舍问题)

方案一:读写数据可以由多个client在高负载下完成。

方案二: 如果数据库负载很重,查询不返回最新的point

7. 许多时序数据是短暂的。通常情况下,时序数据只会出现几小时就停止了,比如一个主机启动,报告数据一段时间后就被关闭了

方案一:赞成,支持管理不连续的数据

方案二:Schema-less 意味着不支持一些function,比如表连接。

8. 单个point不重要

方案一:赞同,因为InfluxDB有非常强大数据聚合能力和大数据sets.

方案二:points没有id,是按时间戳和series来区分的


·本文原文是https://docs.influxdata.com/influxdb/v1.6/concepts/insights_tradeoffs/

我觉得有一些方案的取舍应该是很明确,不明白为什么官网写出另外一个相反方案的意义何在。

本文完。

本站作品的版权皆为作品作者所有。

本站文字和内容为本站编辑或翻译,部分内容属本站原创,所以转载前务必通知本站并以超链接形式注明内容来自本站,否则以免带来不必要的麻烦。

本站内容欢迎分享,但拒绝有商业目的的转载!



上一篇:初识InfluxDB