我正在使用google cloudSQL对人员数据进行预先搜索以获取用户列表。在数据存储区中，已存储有2个模型的数据。首先用于跟踪用户的当前数据，而其他模型用于跟踪历史时间线。目前的数据存储在google cloudSQL上，对于所有用户来说都超过了数百万行。现在，我想通过将所有历史数据添加到云来实现对历史数据的预先搜索，包括日期之间。
如果有人能够为这个历史模型建议更好的结构，我已经浏览了很多链接和文章。但是找不到合适的解决方案，因为我必须处理搜索的性能（在当前搜索中，获取结果的时间是正常的，但是当获取历史记录时，它将扫描导致查询速度减慢的所有记录，因为根据需要复杂的JOIN）。用于从cloudSQL获取数据的查询是根据用户的需要动态生成的。例如，用户想要经理 “xyz.123@abc.in”的员工列表，通过使用python代码，将相应地构建查询。现在，用户希望找到其经理WAS “xyz.123@abc.in”且有效从2016-05-02到2017-01-01的用户。
我找到了一些结构的用例，如下所示：
1）与当前结构相同的模型， isCurrentData 的新列标志（数据状态是历史还是活动）
Disadv： - 在获取数据时查询减慢，因为它将扫描所有记录。 数据重复可能会增加。
这些都是disadv。将通过增加时间来影响提前搜索的性能。 解决此问题的方法是将整个表分区为差异表。
2）基于年份的分区。 随着时间的推移，这将产生太多的表。
3）可能会保留2个表格。 第一个是当前数据，第二个是历史数据。但是当用户想要在两个模型上搜索数据时，会产生构建查询的复杂性。
因此，需要通过改进性能和有效数据处理来构建历史时间表的建议。
提前致谢。
答案 0 :(得分：0)
根据您希望对历史查询和数据集的大小进行实时查询的频率，您可能需要考虑将历史数据放在其他位置。
例如，如果您需要快速查询实时数据并执行其中许多操作，但可以处理更高延迟的查询并且有时只执行它们，您可以考虑定期将数据导出到Google BigQuery。 BigQuery可用于搜索大量数据，但具有更高的延迟，并且没有与MySQL兼容的有线协议（尽管对于那些了解任何SQL风格的人来说，查询语言看起来很熟悉）。此外，对于Cloud SQL，您需要为数据存储和数据库运行的时间付费，而在BigQuery中，您通常需要为数据存储和查询执行期间扫描的数据量付费。因此，如果您计划执行许多这些历史查询，可能会有点贵。
此外，如果您没有非常大的数据集，BigQuery可能有点过分。您的“实时”数据集有多大，您希望“历史”数据集随着时间的推移有多大？是否可以随着历史数据的增长而增加Cloud SQL实例的大小，直到开始导出到Big Query有意义的时候？
答案 1 :(得分：0)
@Kevin Malachowski：感谢您指导我的信息和问题，因为它给了我新的思维方式。
历史数据记录将超过0.3-0.5百万（最大值）。现在我将使用 BigQuery 进行历史高级搜索。
对于实时数据 - 将使用 cloudSQL ，因为我们必须关注获取数据的性能。
当用户想要既有实时数据也有历史数据时，某些性能问题将出现在历史搜索中。 （对于最坏的情况，BigQuery需要花费大约5-6秒[或更多]的时间）但是它将根据模型的数据和结构进行优化。