最近我开始使用 DynamoDB 来存储事件，结构如下：
{start_date: '2016-04-01 15:00:00', end_date: '2016-04-01 15:30:00', from_id: 320, to_id: 360, type: 'yourtype', duration: 1800}
但是当我开始分析它时，我发现 DynamoDB 没有聚合，有读/写限制，响应大小限制等。然后我安装了一个插件来将数据索引到 ES。结果，我发现我不再需要使用 DynamoDB。 所以我的问题是你什么时候肯定需要 NoSQL（在我的例子中是 DynamoDB）实例以及 Elasticsearch？ 当您不仅存储索引而且存储完整文档时，它会降低 ES 性能吗？ （是的，我知道 ES 只是一个索引，但无论如何，在某些情况下，这种方法可能比拥有 MySQL 集群更具成本效益）
【问题讨论】：
标签： elasticsearch amazon-dynamodb bigdata nosql
您将数据写入 DynamoDB，然后使用 DynamoDB Streams 在 Elasticsearch 中自动为其编制索引的原因是，DynamoDB 或 MySQL 被认为是可靠的数据存储。 Elasticsearch 是一种索引，一般来说，它不适合存储您确实无法承受丢失的数据。
DynamoDB 本身在存储时间序列事件数据方面存在问题，并且如您所述，无法进行聚合。但是，您可以将 DynamoDB Streams 与 AWS Lambda 和单独的 DynamoDB 表结合使用，根据您要计算的内容具体化聚合视图。根据您的用例和所需的灵活性，这可能需要考虑。
如果您愿意接受数据丢失的可能性，通常认为使用 Elasticsearch 作为日志等内容的唯一目的地是可以接受的。如果您想要存储和分析的记录真的太有价值而不能丢失，那么您真的应该将它们存储在其他地方，并让 Elasticsearch 成为您查询的副本。 Elasticsearch 允许非常灵活的聚合，因此它是此类用例的绝佳工具。
作为一种完全替代方案，您可以使用 AWS Kinesis Firehose 摄取事件并将它们持久地存储在 S3 中。然后，您可以使用 S3 事件触发 AWS Lambda 函数将数据发送到 Elasticsearch，您可以在其中聚合它。这是一个负担得起的解决方案，唯一的主要缺点是 Firehose 施加的 60 秒延迟。使用这种方法，如果您在 Elasticsearch 集群中丢失数据，仍然可以从存储在 S3 中的文件中重新加载数据。
【讨论】：