Google CloudSQL :在cloudSQL上构造历史数据

Question

我使用google cloudSQL对人的数据进行预先搜索，以获取用户列表。在数据存储中，已有2种模型存储的数据。首先用于跟踪用户的当前数据，其他模型用于跟踪历史时间线。当前的数据存储在google cloudSQL上，对所有用户来说都是上百万行。现在，我希望通过将所有历史数据添加到云中来实现对历史数据的预先搜索，包括日期之间的搜索。

如果有人能为这个历史模型提出更好的结构，我已经浏览了许多链接和文章。但是无法找到适当的解决方案，因为我必须考虑搜索的性能(在当前的搜索中，获取结果的时间是正常的，但是当历史记录被获取时，它将扫描由于需要复杂的连接而导致查询减速的所有记录)。用于从cloudSQL获取数据的查询是根据用户的需要动态进行的。例如，用户需要员工列表，其"xyz.123@abc.in"管理器为，通过使用python代码，查询将相应地生成。现在，一个用户想要找到的用户，其经理是"xyz.123@abc.in"与effectiveFrom 2016-05-02至2017-01-01。

正如我已经发现的结构的一些应用程序，如下所示：

1)与当前结构相同，为isCurrentData设置了新的列标志(数据状态，无论是历史还是active)。

Disadv.: -在获取数据的同时，查询速度减慢，因为它将扫描所有记录。重复的数据可能会增加。

这些都是废品。会通过增加时间来影响提前搜索的性能。解决此问题的方法是将整个表划分为diff表。

2)基于年份的划分。随着时间的推移，这将产生太多的表。

( 3)可维持2个表。第一是当前数据，第二是历史数据。但是，当用户想在这两种模型上搜索数据时，都会造成构建查询的复杂性。

因此，需要建议如何构造具有改进性能和有效数据处理功能的历史时间线。

提前谢谢。

Answer 1

根据您想要进行活动查询与历史查询的频率以及数据集的大小，您可能需要考虑将历史数据放在其他地方。

例如，如果您需要对活动数据进行快速查询并执行其中的许多操作，但可以处理较高延迟的查询，并且只在某些时候执行这些查询，则可以考虑定期将数据导出到Google BigQuery。BigQuery对于搜索大量的数据很有用，但是延迟性要高得多，并且没有一个与MySQL兼容的有线协议(尽管它的查询语言对于那些熟悉它的人来说是很熟悉的)。此外，对于Cloud，您需要支付数据存储和数据库运行的时间，而在BigQuery中，您主要支付数据存储和查询执行过程中扫描的数据量。因此，如果您计划执行许多这些历史查询，它可能会变得有点昂贵。

另外，如果您没有非常大的数据集，那么BigQuery可能有点过分了。您的“实时”数据集有多大，您期望您的“历史”数据集随时间增长有多大？是否有可能随着历史数据的增长而增加Cloud实例的大小，直到开始导出到Big为止？

Answer 2

@：谢谢你用你的信息和问题指导我，因为它给了我新的思维方式。

历史数据记录将超过30万至50万(最多)。现在，我将使用BigQuery进行历史推进搜索。

对于实时数据，将使用cloudSQL，因为我们必须将重点放在获取数据的性能上。

一些性能问题将出现在历史搜索中，当用户需要实时和历史数据的结果时。(BigQuery在最坏的情况下大约需要5-6Secor的时间)，但它将根据数据和模型的结构进行优化。