8

我面临一个问题：过程工厂的数据库。在 50 ms 的采样率下，最多有 50,000 个传感器。所有测量值至少需要存储3年，并且必须支持实时查询（即用户可以看到延迟小于1秒的历史数据）。我最近读了一篇关于时序数据库的文章，手头有很多选择：OpenTSDB、KairosDB、InfluxDB、...

我很困惑哪一个适合这个目的？任何知道这一点的人请帮助我！

更新 15.06.25

今天我运行一个基于 OpenTSDB 的测试。我使用 Virtual Box 创建了一个由 3 个 CentOS x64 虚拟机（1 个主设备，2 个从设备）组成的集群。主机配置为 8 GB RAM，核心 i5。主 VM 配置为 3 GB RAM，从属 VM 配置为 1.5 GB RAM。我编写了一个 python 程序来将数据发送到 OpenTSDB，如下所示：

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("192.168.10.55", 4242))

start_time = time.time()
start_epoch = 1434192418;

for x in range(0, 1000000):
    curr_epoch = start_epoch + x

    tag1 = "put TAG_1 %d 12.9 stt=good\n" % (curr_epoch)
    tag2 = "put TAG_2 %d 12.9 stt=good\n" % (curr_epoch)
    tag3 = "put TAG_3 %d 12.9 stt=good\n" % (curr_epoch)
    tag4 = "put TAG_4 %d 12.9 stt=good\n" % (curr_epoch)
    tag5 = "put TAG_5 %d 12.9 stt=good\n" % (curr_epoch)
    tag6 = "put TAG_6 %d 12.9 stt=good\n" % (curr_epoch)
    tag7 = "put TAG_7 %d 12.9 stt=good\n" % (curr_epoch)
    tag8 = "put TAG_8 %d 12.9 stt=good\n" % (curr_epoch)
    tag9 = "put TAG_9 %d 12.9 stt=good\n" % (curr_epoch)
    tag10 = "put TAG_10 %d 12.9 stt=good\n" % (curr_epoch)
    str = tag1 + tag2 + tag3 + tag4 + tag5 + tag6 + tag7 + tag8 + tag9 + tag10

    s.send(str)

print("--- %s seconds ---" % (time.time() - start_time))

我在主机上运行 python，大约 220 秒后工作完成。所以，我得到了一个平均值。每秒约 45000 条记录的速度。

更新 15.06.29

这次我只使用了 1 个 VM（5 GB RAM，3 个内核，CentOS x64，伪分布式 Hadoop）。我在 Windows 7 主机上运行 2 个 python 进程，将 2 半数据发送到 OpenTSDB。平均 放置数据的速度约为每秒 100,000 条记录。

4

4 回答 4

2

要处理每秒百万次的写入，您需要进行一些严肃的工程。

并非所有数据库都能够以紧凑的形式存储这么多数据。

例如，ATSD 每个样本使用 5 到 10 个字节（浮点数据类型），具体取决于观察到的方差。

有一种基于 HBase 构建的分布式（集群）数据库能够处理这种负载。

例如，您可以尝试查看openTSDB和ATSD。

更新 1。

我们针对您的特定用例运行了以下测试：

30.000 个模拟传感器写入浮点型数据，产生 540.000.000 条记录

20.000 个数字传感器写入短类型数据（零和一），产生 552.000.000 条记录

数据占用了 3.68 GB。压缩是无损的。

导致每条记录平均 3.37 字节。

这是一个存储效率测试。

充分披露，我为开发 ATSD 的公司工作。

于 2015-06-22T16:36:23.540 回答
2

InfluxDB 目前无法处理每秒持续的百万次写入，但这在今年晚些时候的性能目标范围内。我看到的更大挑战是您要存储的数据量巨大。如果您需要在不进行下采样的情况下保持三年的全分辨率，那就是数百 TB 的数据。如果这不是全部在 SSD 上，查询性能将不会很好。如果这一切都在 SSD 上，那将是一个极其昂贵的数据库。此外，有了这么多原始数据，无论安装多少，都可以很容易地制作一个爆炸 RAM 的查询。

我会说在 8-12 周后与 InfluxDB 团队联系，我们可能会更好地了解如何处理您的问题。不过，我的建议是找到一种方法来拆分它。如果你真的以 50ms 的间隔对 50k 台机器进行采样，那将是大量的数据、网络流量等。

于 2015-06-22T18:34:49.847 回答
1

非常有趣的用例。

我不能代表别人说话，因为我只强烈评估和使用过 KairosDB 和 Cassandra，但我可以谈谈我自己的经验。

KairosDB + Cassandra 可以承受吞吐量，但是对于每秒 1M 的写入，您需要一个具有多个前端（我建议至少 10 个节点，但您必须进行测试）和后端服务器（如果它们可以托管在需要）。

无论如何，每个传感器的吞吐量为每秒 200 个样本......对于长查询来说，检索历史数据可能是一个问题（历史数据的 1 秒很有趣，但您必须确定查询持续时间的样本量）。

据我所知，存储效率不会像 ATSD 那样好（可能是两倍大小，这已经很好了）。

我个人喜欢 KairosDB 和 Cassandra 以及我们采用它的原因：它简单、真正分布式、KairosDB 不会弄乱数据、设计优雅且不涉及复杂系统、Cassandra 管理数据并且 kairosDB 提供 TSDB服务，性能和效率一点也不差......而且Cassandra作为一个集群比它的同行更容易管理。

于 2015-07-29T15:09:29.940 回答
0

MemSQL 每秒可以处理 1M 次写入。我建议为此使用 Kafka 和 MemSQL 列存储。根据查询的类型，亚秒级响应是非常可能的。

于 2015-06-24T23:25:03.823 回答