我们正在创建一个接收 JSON 消息的应用程序，如下所示，
{ orderId: "00e8da9b", created: 12-22-2016, lineItems: [ { itemName: Item 1 qty: 1 price: 20.0 } { itemName: Item 2 qty: 3 price: 80.0 }] 定价：{零售：110，实际：100，储蓄：10，}，}
主要是应用程序用来生成统计报表。系统将执行的主要操作是，
INSERT order details
UPDATE order status
SUM 所有订单中特定项目的总价（按月和年
）在所有订单中按项目名称搜索（也类似于部分文本搜索）并显示所有订单记录数量、项目和价格
我们已经回顾了一些 NoSQL DB 的 MongoDB、Cassandra 和 Elastic Search。查看以下 URL 时，看起来 Elastic Search 是比 MongoDB 更好的搜索和求和操作选择。但在 Elastic Search 中存在数据丢失的可能性。
http://blog.quarkslab.com/mongodb-vs-elasticsearch-the-quest-of-the-holy-performances.html
请建议哪种 NoSQL DB 最适合该要求。
谢谢。
我认为不可能根据给定的信息正确建议 NoSQL 解决方案。
相反，我将尝试向您指出特定解决方案的最佳位置。然后根据一些假设它是否适合您。
Cassandra：对于大规模的数据/请求，数千个请求/秒以上，每天数百万次插入；适用于面向列表的数据模型、时间序列数据，例如来自 IoT 设备、用户等的事件。可扩展性伴随着一些缺点，例如分析和搜索功能非常有限。您只能通过分区/集群键字段访问数据。如果您需要分析和搜索功能，则需要探索/学习其他工具，例如 Apache Spark、SOLR、Elasticsearch。--> 可能不是您的最佳选择，只要您不必处理大规模数据。
Elasticsearch：实时全文搜索和分析解决方案的索引。如果您没有全文搜索要求，并且不需要对数百万个数据点的实时分析功能，那么这可能也不是您的首选。同样在大多数用例中仅用作主数据库的附加索引。--> 您的搜索要求听起来更像是可以使用普通 SQL“LIKE”运算符完成的事情。您的搜索和报告要求听起来更像是在月末/年末完成的传统报告。因此，额外的搜索引擎似乎是您不需要的开销。
MongoDB：对于面向文档的数据，对于用例，您将使用 RDBMS 系统，但您需要一个灵活的模式等。 --> 从数据建模的角度来看，可能不是您的最佳选择，因为您必须对之间的关系进行建模产品和订单，您可能需要在关系的两端发现和添加数据。
结论：如果您不必处理大量数据，那么用于统计报告的数据库对我来说听起来很像 RDBMS（即使我不是 RDBMS 专家 ;)）。