从关系数据库迁移到大数据答案

【问题标题】：Moving from Relational Database to Big Data从关系数据库迁移到大数据
【发布时间】：2017-11-13 09:53:24
【问题描述】：

目前我在 Google Cloud Platform 上托管了一个应用程序，它提供网络分析并提供会话活动（点击、下载等）并将该网络活动与网络注册联系起来。

目前，我们将所有点击和会话配置文件数据存储在 MySQL 中，并使用 SQL 查询来生成汇总报告和每用户报告，但是，随着数据量的增长，我们看到了真正的放缓在查询响应中，这反过来会减慢页面加载时间。

在研究解决此问题的方法时，我们研究了 Google Cloud Platform 上可用的工具，例如 Dataproc 和 Dataflow 以及 NoSQL 解决方案，但是，我很难理解如何将我们当前的解决方案应用于任何这些解决方案。

目前，我们的数据架构的大致思路如下：

User table
- id
- name
- email

Profile table (web browser/device)
- id
- user id
- user agent string

Session table
- id
- profile id
- session string

Action table
- id
- session id
- action type
- action details
- timestamp

根据我的研究，我对最佳解决方案的理解是将操作数据存储在像 BigTable 这样的 NoSQL 数据库解决方案中，它将数据馈送到像 DataProc 或 DataFlow 这样生成报告的解决方案中。但是，鉴于我们当前的架构是一种高度相关的结构，似乎取消了转向 NoSQL 解决方案的选项，因为我的所有研究都表明您不应该将关系数据迁移到 NoSQL 解决方案。

我的问题是，我对如何应用这些工具的理解是否正确？还是有更好的解决方案？甚至有必要考虑离开 MySQL 吗？如果没有，有哪些可用的解决方案可以让我们在后台预处理/生成报告数据？

【问题讨论】：

会话和操作表值是否已更新？我的意思是只有那些插入还是有更新？
会话表通过 cronjob 更新，该 cronjob 将一些数据（例如每个会话的操作计数）聚合到会话表中，但是，操作是仅插入的。
您可以在 MySQL 中保留一个临时会话表，一旦会话完成或在一天结束时将其全部转储到 BigQuery。

标签： mysql performance google-cloud-platform analytics bigdata

【解决方案1】：

假设sessions 和actions 表值没有更新，只是插入。最好的方法是将数据库分成两部分。为user 和profile 表保留MySQL DB，并为actions 和sessions 使用BigQuery。

这样你就有了：

最大限度地减少您必须在任一方（数据提取和提取）上进行的更改
您将显着降低数据存储成本
查询时间将显着缩短
不知不觉中，您将涉足大数据领域，而 BigQuery 正是它的解决方案

BigQuery 是最好的方法。但是，如果您有太多可用的额外资源和时间，您可以考虑将其存储到 NoSQL 数据库中，然后使用 DataFlow 在其上运行管道作业以提取分析数据，您将再次需要将其存储在数据库中以进行查询。

【讨论】：

最重要的是：您可以按日期对 BigQuery 表进行分区，并降低长期存储和日常查询的成本。

【解决方案2】：

几个问题/潜在的解决方案：

简介！如果是相同的查询在数据库中运行，那么优化您的查询或为您最频繁的页面缓存一些结果可以帮助减轻处理负担。数据库设置、RAM 等也是如此。
您的数据库有多大？如果它小于 64GB，则扩展到更大的服务器以使数据库可以放入 RAM 中可能是一个快速的胜利。
您的数据是如何使用的？如果它纯粹是为了历史数据，您可能会减少点击到查找表中，例如。每周每个会话或每个用户每周的操作。如果每 5 分钟/小时整理一次数据，下载原始数据并在本地进行处理也可以。
您可以反规范化，例如。将 user agent|session|action type|details|timestamp 合并为一行，但您可能会增加存储需求和查找时间。
另外，更多的标准化也有帮助。将用户代理字符串分解为自己的表将减少该表的数据需求并可能加快处理速度。
您的数据似乎可以由用户拆分/分片，因此这可能是另一种选择。

一般来说，解决这些问题的最快方法是针对您的特定工作负载进行尝试，例如。您可以在具有合理 RAM 量的开发机器上执行多少典型请求（或随机仪表板）（或启动服务器/创建不同的测试数据库）。

此外，如果您主要习惯于关系数据库，则在切换时会产生一些开销（尤其是对于最前沿的解决方案），因此在切换或切换之前，您需要相当确定成本大于收益一次一点，这样如果它不起作用，你可以切换回来。同样，测试会有所帮助。

【讨论】：

1.优化一直是一场持续的斗争，因为我们的主要 perf-killing 查询大约是 100 行 SQL 并且非常复杂 2. 目前它不到 64gb，我们一直在扩大规模，但这感觉像是一个临时解决方案 3. 将数据写入它出现并生成报告 4-5。但是，可能我觉得问题在于聚合而不是数据存储 6. 分片可能会起作用，但是在那个用例中聚合查询会发生什么？
1. 100 行似乎很大，一定要先尝试简化/缓存这一行。 2. 如果你正在扩展，大多数事情都是临时解决方案。额外的 RAM 可能会为您争取更多时间并帮助您度过难关。 3. 提前生成/存储这些报告（或其中的一部分）可能会有所帮助。 4,5。如果存储“更密集”，聚合可能会更快 6. 最好的情况是，您的工作负载除以 N。不过，您可能需要手动分散大量用户才能在实践中实现这一点。

【解决方案3】：

如果可行，根本不要存储大量数据！

相反，在数据块到达时对其进行汇总（聚合），然后存储汇总。

优点：

可能需要十分之一的磁盘空间；
报告速度可能快 10 倍，
可以在现有的 RDBMS 中完成。

缺点：

您不能改进不同的摘要。（好的，您可以保留原始数据并重新开始；无论如何这可能会更好。）
代码更复杂。

Discussion 的汇总表。

【讨论】：