我们平台的用户将在我们的系统上存储大量数据。通过应用程序，一旦连接，这些数据将被传输给他们，不再需要保留在我们的服务器上。在任何给定时间都可能有成百上千的用户连接，执行他们的下载。
这是建议的架构：
用户管理、配置和数据下载统计信息将保存在 SQL Server 数据库中，同时使用 Redis 或 DynamoDB 处理大型数据集。
选择 Redis 或 DynamoDB 的原因是基于成本（比运行另一个 SQL Server 实例便宜）和性能。数据格式将类似于数据集市 - 没有连接的平面表。
最初，查询很简单——获取用户 X 在日期范围内的所有数据，并可选择删除。
由于我们可能希望使用弹性搜索添加自由文本搜索该数据的某些字段，因此从一开始就使用它可能是一个更好的选择。
我希望这是自动缩放的，但不确定哪个数据库最适合这种情况。
我不会单独使用 Elastic-search，因为它不提供写入容量的自动缩放。事实上，增加索引的分片数量并非易事。其次，它只能处理 JSON 格式，这对您来说可能是个问题。
Redis 可能是一个好主意，因为它非常快，一切都在 RAM 中完成，并且它为密钥提供了有限的生存时间，这对你来说可能很有趣。不幸的是，如果您的数据大小超过了亚马逊实例的 RAM 容量，您将不得不对 Redis 数据库进行分片。Redis 不支持它，你必须在你的应用程序代码上处理它。此外，据我所知，Redis 不处理复杂的查询。您还需要将数据保存在 Redis 数据结构中，这对您来说可能是个问题
DynamoDB 可以很好地处理自动缩放，但另一方面，它是一个键/值数据库，因此它不允许您进行诸如“获取日期范围内用户 X 的所有数据”之类的查询。DynamoDB 还允许您以任何格式保存数据。
解决方案是根据数据的大小使用 DynamoDB 或 Redis，并使用 ElasticSearch 以便仅使用元数据（用户和日期）来索引您的键。像这样你的索引会很小，如果你因为 ElasticSearch 太忙而失去了索引的能力，你保留保存用户数据的能力。
