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