用于传感数据传输的Oracle Materialized View

Question

在应用程序中，我们必须通过Internet将感知数据流从多个客户端发送到中央服务器。一个显而易见的解决方案是使用Mafs（面向消息的中间件），例如Kafka，但我最近了解到我们可以使用oracle Materialized View等数据库同步工具来实现这一点。

后一种方法适用于某些应用程序（从中央服务器向多个客户端发送数据，与我们的应用程序相反），但它在我们的应用程序中的优缺点是什么？哪个更适合从速度，安全性等方面将多个（~100）客户端的传感数据流发送到服务器？

谢谢。

附：

有关更多详细信息，请考虑一个应用程序，其中许多（大约100个）客户端必须通过Internet向中央服务器发送流数据（每分钟1MB数据）。服务器需要数据，以便进行在线监控，分析和一些计算，如机器学习和数据挖掘任务。

我的问题是db-to-db连接和流式解决方案（如kafka）之间的区别，用于将数据从客户端转移到服务器。

Answer 1

Prologue

我将尝试将您的问题解决，以便更清楚地了解您当前的要求，然后重新构建它。这需要很长时间才能写出来，所以如果你做了两件事，我真的很感激：

1. 持怀疑态度 - 对自己测试的东西绝对没有替代品。互联网作为指南是非常有用的，但不能保证你得到的帮助（如果这个答案甚至是有用的！）对你的具体情况是最好的。在分配的空间中完全描述你当前的情况是不可能的，所以任何答案都必然会缺乏某些地方。
2. 再看看你是如何解释自己的 - 这是一个有效的问题，由于你对系统的描述不清晰以及你想要实现的目标而被部分阻止。在发布复杂问题之前让不熟悉您系统的人查看您的问题可能会有所帮助。

---

Problem definition

从多个客户端到中央服务器的感知数据流

您将数据从多个位置发送到单个持久性存储

在线监测

您将基于原始数据和可能的某些聚合数据触发进一步的操作

分析和一些计算，如机器学习和数据挖掘任务

您将要对客户端数据执行一些聚合，即您需要将所有客户端数据的聚合保留在某处（无论是暂时的）

进一步的假设

因为您在讨论物化视图，我们可以假设所有客户端都将数据保存在数据库中，可能是Oracle。

来自客户的数据是关于同一主题的。

你有大约100个客户，在这个数额我们可以假设：

• 客户端数量可能会发生变化
• 您希望能够在不增加访问数据的方法数量的情况下添加客户端

您不适用于Google，亚马逊，Facebook，Quantcast，Apple等。

Architecture diagram

在这里，我没有对它的实际工作方式发表任何评论 - 这是基于我对你的系统缺乏了解的讨论的开始。 “原始数据持久性”可以是文件，Kafka，数据库等。这是对所需组件的描述，并粗略猜测它们将如何连接。

Applying assumed architecture to materialized views

物化视图是持久化查询。因此，您有两个选择：

1. 创建一个将所有100个客户端数据联合在一起的查询。如果添加或删除客户端，则必须更改查询。如果您的任何一个客户端出现网络问题，则一切都会失败
2. 编写并维护100个物化视图。中心位置的Oracle数据库有100个传入连接。

正如您可能从权衡中猜到的那样，我不得不将物化视图视为唯一的解决方案。我们应该尝试减少重复代码和单点故障的数量。

您仍然可以使用物化视图。如果我们采用图表并删除中心位置的所有重复箭头，则意味着两件事。

1. 有一种服务可以接受传入的数据
2. 有一项服务可将所有传入数据放入一个位置

然后，您可以为聚合层使用单个物化视图（如果原始数据持久性不在Oracle中，则首先必须将数据放入Oracle）。

变化的后果

现在我们已经确定你有一个单一的数据管道，你的决定实际上变得更难了。我们已将客户端从中心位置和聚合层与原始数据持久性分离。这意味着现在的选择是你的，但它们也更容易改变。

Reimagining architecture

在这里，我们需要弄清楚哪些技术不会改变。

• Oracle数据库价格昂贵，你每天需要140GB /天（相当于50TB /年）。我不知道你是否真的存储了所有的原始数据，但是在那些卷上它不太可能 - 你只是存储聚合
• 我假设你有一些首选的技术，你的机器学习和数据挖掘发生。如果你不这样做，那么考虑一些来防止疯狂支持一切

把所有这些放在一起我们最终会得到以下结论。实际上只有一个问题很重要：

您希望从数据库中读取原始数据的次数。

如果答案是一次，那么我们刚刚描述了一些描述的中间件。如果答案不止一次，那么除非你有一些非常好的磁盘，否则我会重新考虑。你是否在这个中间层使用Kafka完全取决于你。使用您最熟悉的任何内容，以及您最愿意花时间学习和支持的内容。你正在处理的数据量是非常重要的，并且会有一些试验和错误来实现这一点。

关于这一点的最后一点;我们已经定义了一个数据管道。一种数据流经系统的方法。通过这样做，我们增加了系统的灵活性。想要添加更多客户，无需做任何事情。想要改变系统部分背后的技术，只要界面保持不变就没有问题。想要在其他地方发送数据，没问题，它都在原始数据持久层中。