我有一个应用程序需要存储大量数据（每天大约 200,000 txns），每个记录的大小约为 100 kb 到 200 kb。数据的格式将是JSON/XML。
应用程序应该是 高度可用 ，因此我们计划将数据存储在 S3 或 AWS DynamoDB 上。
我们有一些用例，我们可能需要根据一些属性（日期范围、状态等）搜索数据。大多数搜索将基于几个共同属性，但对于某些操作用例可能会有一些任意查询。
我研究了搜索非关系数据的方法，到目前为止，发现大多数技术都在使用两种方式。 1）构建索引（Solr/CloudSearch等） 2） 运行 Map Reduce 作业（Hive/Hbase 等）
我们的要求是搜索结果是可靠的（与 S3/DB 中的数据一致 - 类似于预言机查询，慢一点是可以的，但是当我们获得数据时，我们应该返回与查询匹配的所有内容，或者至少让我们知道一些结果被跳过了）
一开始，基于指数的方法似乎比MR更快。但我不确定它是否可靠 - 索引可能过时？（有没有办法在进行搜索时知道索引是否过时，以便我们可以更正它？有没有办法让索引始终与 DB/S3 中的值保持一致？类似于 Oracle 数据库上的索引）。MR 作业似乎始终是可靠的（因为它为每个查询从 S3 获取数据），这个假设对吗？有没有办法加快此查询的速度 - 可能是 S3 中的分区数据并根据每个分区运行多个 MR 作业？
添加文档后，您可以<提交 /> 并<优化 /> Solr 索引，所以我不确定过时的索引是一个问题。我设置了一个 Solr 实例，每天处理大约 100,000 个额外的文档。在我离职时，我们的索引中有 140 万份文档。它用于内部报告，并且性能很高（最复杂的查询也在一分钟内）。我刚刚问了一位前同事，一年后它仍然做得很好。
不过，我不能与地图减少软件交谈。
例如，您应该考虑每周/每月拥有一个Solr内核，这样较旧的内核将是只读的，并且更易于管理，并且非常容易分布在多个Solr实例上。如果要每天添加 200k 个文档，您需要该文档或 Solr 分片，那么单个内核将永远不够。