问题描述
有没有人有在Elasticsearch和关系数据库（例如MysqL / postgres /）之间切换的经验？两者的优点/缺点是什么？
背景：希望构建一个仪表板UI来显示与商店/商品相关的指标，并需要在后端使用正确的工具以提供查询的灵活性（假设UI具有日期范围选择器，然后该UI显示已售出的热门商品，总销售额等）。其他一些注意事项是，我们将只在商店或商品周围使用聚合/嵌套聚合（不会利用文本搜索）。
我知道您可以同时使用这两种，但就哪一种而言，
-
性能？我想他们会在很大程度上相似
- 耐久性？我想像一下elasticsearch，它会自动复制数据
- 维护？我想Elasticsearch会更糟（维护集群而不是维护单个节点）
- 费用？我想象一个存储相同数量数据的Elasticsearch集群由于复制会花费更多的钱
- 开发工作？我猜想Elasticsearch使用Elasticsearch的自定义查询会导致开发花费更长的时间，而不是围绕SQL查询编写API。
这些假设正确吗？ 在这两个选项上，我还应该考虑其他数据库/数据存储吗？
解决方法
根据我的经验，Elastic Search是一款出色的工具：
- 搜索
- 实时数据聚合
- 具有广泛过滤支持的实时报告
我们还使用Elastic Search增强了具有广泛过滤器选项（例如日期范围，状态等）的实时报告。
我们将E.S和MongoDB的聚合性能与类似的计算机进行了比较，总计500万条记录的mongo-db花费了大约12秒，而E.S花费了不到1秒。
性能？我想它们会在很大程度上相似
如果您对需要大量过滤，搜索等操作的数据负载具有纯聚合用例，那么ES的性能将无与伦比。
耐久性？我想象弹性搜索，它会自动复制 数据
是的，E.S确实具有固有的复制支持，因为它是分布式系统。
维护？我认为elasticsearch会更糟（维持 集群与维护单个节点）
绝对分布式系统需要更多维护，但您也可以使用ES的托管版本（例如AWS Elasti缓存）
费用？我想象一个弹性搜索集群存储相同数量的 复制会导致数据花费更高
还必须考虑群集并提供复制支持。红外线成本会更高。
开发工作？我想Elasticsearch会导致发展 使用Elasticsearch的自定义查询要比编写API花费更长的时间 围绕SQL查询
这取决于E.S.的经验由于Mysql已经存在了很长时间，因此大多数开发人员都对此有所了解。任何新技术都有其学习曲线。
请紧记：
- E.S不是兼容ACID的数据存储。
- 没有事务支持。如果您的系统是纯事务性的，则可能需要使用Relational-db作为读/写存储，并需要E.S来支持聚合用例。