Database 哪个NoSQL数据库最适合统计报表应用

我们正在创建一个接收JSON消息的应用程序，如下所示，

{ 订单ID:“00e8da9b”， 创建日期：2016年12月22日， 行项目：[ { 项目名称：项目1 数量：1 价格：20.0 } { 项目名称：项目2 数量：3 价格：80.0 } ] 定价：{ 零售：110， 实际：100， 节省：10， }, }

该应用程序主要用于生成统计报告。系统将执行的主要操作是，
插入订单详细信息
更新订单状态
按月份和年份对所有订单中特定项目的总价求和
在所有订单中按项目名称搜索（也类似于部分文本搜索），并显示包含订单号、项目和价格的所有记录

我们已经回顾了NoSQL DB的MongoDB、Cassandra和Elastic搜索。 查看下面的URL，看起来弹性搜索比MongoDB更适合搜索和求和操作。但弹性搜索存在数据丢失的可能性。

请建议NoSQL DB是满足该要求的最佳套件

---

谢谢。

我最熟悉Cassandra，所以我可以回答这个问题：Cassandra非常适合插入、更新和查找（需要注意的是，为了获得良好的性能，必须使用整个分区键进行查询。分区键实际上是数据在内部索引的对象，可以粗略地认为是主键或复合主键）

Cassandra需要通过第三方索引引擎提供一些帮助（例如SOLR，它集成在Cassandra的Datastax企业平台中，或者您可以复制到ElasticSearch进行索引）用于不包含整个分区键的查询。如果没有帮助，聚合操作实际上不可能实现；索引引擎（SOLR，Elasticsearch）可以通过查询来实现这一点，但是如果您拥有所有需要求和的完整分区密钥，我更喜欢获取记录并处理聚合客户端（我们使用SOLR，发现配置错误的SOLR或过于复杂的SOLR查询可能会对集群造成不良影响）

因此，就您的用例而言，Cassandra可以提供： 插入=好 更新=良好 SUM=可以使用外部索引引擎或客户端执行，只要按月/年分区即可。 SEARCH=仅可使用您描述的方式使用外部索引引擎

对于外部索引引擎，我的项目使用SOLR，但我听到了将Cassandra复制到ElasticSearch以进行搜索和聚合，并同时使用这两者的建议

---

我对Mongo知之甚少，因此我不能对它说太多。

我认为不可能根据给定的信息正确建议NoSQL解决方案

相反，我会尝试给你一个特定解决方案的最佳点在哪里的指示，然后基于一些假设，它是否适合你

• Cassandra:对于大规模的数据/请求，每天有数千个请求/秒以上，数百万次插入；适用于面向列表的数据模型、时间序列数据，例如来自物联网设备、用户等的事件。可扩展性也有一些缺点，例如分析和搜索能力非常有限。您只能访问data按分区/群集关键字段。如果您需要分析和搜索功能，您需要探索/学习其他工具，如ApacheSpark、SOLR、Elasticsearch。 -->只要您不必处理大规模数据，可能就不是最佳选择

• Elasticsearch：用于实时全文搜索和分析解决方案的索引。如果您没有全文搜索要求，并且不需要对数百万个数据点进行实时分析，则可能也不是您的首选。此外，在大多数情况下，仅用作主数据库的附加索引-->您的搜索要求听起来更像是可以通过普通的SQL“like”操作符完成的。您的搜索和报告要求听起来更像是在月底/年底完成的传统报告。因此，额外的搜索引擎似乎是您不需要的开销

• MongoDB：对于面向文档的数据，在用例中，您将使用RDBMS系统，但需要灵活的模式等-->从数据建模的角度来看，可能不是最佳选择，因为您必须对产品和订单之间的关系进行建模，并且您可能需要在数据模型的两侧发现和添加数据他是我的亲戚

---

结论：如果您不必处理大量数据，统计报告数据库对我来说非常像RDBMS（即使我不是RDBMS的人；）。

Wil Elassandra将有助于提高我们所有业务的性能。这在很大程度上取决于什么对您最重要。Cassandra具有优越的写入可伸缩性和性能，如果您主要通过主键进行查询，它的速度会非常快。由于您需要搜索，我的理解是SOLR是更快的搜索索引引擎，但从操作的角度来看，ElasticSearch更可靠，更易于设置。Philip带来了一个经常被遗忘但我自己的回答没有触及的基本点：不要使用NoSQL，因为它很时髦。使用它是因为它带来了RDBMS无法提供的价值。