NoSQL（Mongo，DynamoDB）与Elasticsearch相比，单独使用Elasticsearch的区别

Question

NoSQL（Mongo，DynamoDB）与Elasticsearch相比，单独使用Elasticsearch的区别

elasticsearchamazon-dynamodbbigdatanosql

3

最近我开始使用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集群更具成本效益）

- Pavel K

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- JaredHatfield · Accepted Answer

使用DynamoDB Streams将数据写入DynamoDB，然后自动在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中的文件重新加载它。