物联网数据解释

Question

这是一个更多的架构问题，我希望从这个线程中获得更多的想法。我有一个计算机视觉模型，检测日常生活活动，每秒钟向服务器发送数据。我想展示的数据在正面，但只有在解释后，以一种可理解的方式。

因此，目前的进程是：

1. 活动被检测到
2. 一些数据被推到我的API中。
3. 数据存储在数据库中。

要以可理解的方式解释数据，我们必须返回并查看前面的行，以确认该数据是什么。例如，如果在过去的1小时内检测到并持续检测到睡眠，那么它就是睡眠，否则就不是真正的睡眠。到目前为止，为了达到这一结果，我们提出了一些建筑方案：

选项1:触发器--在将数据插入数据库时，我们编写一个触发器，返回并确定这是什么类型的活动。

• 优点:我们会立即找出相关活动，并能很快将这些数据提供给客户。
• 缺点:触发器通常会减慢速度。我担心这会发送数据库性能，或者可能导致死锁。考虑到我们将每秒从不同的方向多次插入数据，这可能很快就会成为一种负担。

选项2:存储过程-在发生数据库插入后，存储的proc包含所有逻辑，分别遍历数据并对活动进行分类。

• 优点:处理会立即进行。
• 缺点:同样，考虑到我们将要处理的数据量，数据库上的任何这样的函数都会造成开销。

选项3:在服务器上添加解释逻辑--在插入数据之前将数据推送到API之后，我们将得到前面的所有行，并分析服务器上的数据，然后再插入数据。到目前为止，我认为这是最可行的选择。我正在使用nodeJS，所以这样做似乎很容易。

• 优点:没有DB开销，即时，服务器可以处理更复杂的逻辑
• 缺点:如果我们在每个请求上都这样做，可能会使服务器慢下来。

选项4:让另一个服务运行，它每分钟查看数据并对其进行分类，并将其放在一个单独的表中。

• 优点:没有DB开销，希望不会让服务器慢下来。
• 缺点:不是立即

，我是来找出是否有更明显的方法来处理这类我还不知道的事情。如果有任何明显的AWS服务，我可以使用，这也将是值得赞赏的

。

Answer 1

为了这种工作，我会抛弃关系数据库。

看看时态DBs，它更适合进行时间序列(即“事件”-based)的计算和聚合。即使是Elasticsearch也是合适的，因为它有一些与时间序列相关的功能。

另外，看看流处理解决方案，这是您所描述的大致相同的。比如阿帕奇的“火花”、“风暴”、“弗林克”等等。

同样，卡夫卡是上述两者的混合，同时有一些相当酷和独特的特点。它同时也是一种timeseries DB，同时具有一个非常强大和简单的流处理库。