0

我有一个应用程序需要存储大量数据（每天大约 200,000 txns），每条记录大约 100 kb 到 200 kb 大小。数据的格式将是 JSON/XML。

该应用程序应该是高可用的，因此我们计划将数据存储在 S3 或 AWS DynamoDB 上。

我们有一些用例，我们可能需要根据一些属性（日期范围、状态等）搜索数据。大多数搜索将针对少数常见属性，但对于某些操作用例可能会有一些任意查询。

我研究了搜索非关系数据的方法，到目前为止发现了大多数技术使用的两种方法 1）构建索引（Solr/CloudSearch 等） 2）运行 Map Reduce 作业（Hive/Hbase 等）

我们的要求是搜索结果是可靠的（与 S3/DB 中的数据一致 - 类似于 oracle 查询，速度慢是可以的，但是当我们获取数据时，我们应该返回与查询匹配的所有内容，或者至少让我们知道有些结果被跳过了）

一开始看起来基于索引的方法会比 MR 更快。但我不确定它是否可靠 - 索引可能已过时？（有没有办法在我们进行搜索时知道索引已经过时以便我们可以更正它？有没有办法让索引始终与 DB/S3 中的值一致？类似于 Oracle DB 上的索引）。MR 作业似乎总是可靠的（因为它为每个查询从 S3 获取数据），这个假设对吗？有没有办法加快这个查询 - 可能是 S3 中的分区数据并基于每个分区运行多个 MR 作业？

4

2 回答 2

0

添加文档后，您可以 <commit /> 和 <optimize /> Solr 索引，所以我不确定过时的索引是否值得关注。我设置了一个 Solr 实例，它每天可能处理 100,000 个额外的文档。在我离职时，我们的索引中有 140 万份文档。它用于内部报告，并且性能出色（最复杂的查询也在不到一分钟的时间内）。我刚问了一位前同事，一年后它仍然做得很好。

不过，我不能对地图缩减软件说话。

于 2012-04-17T23:22:25.953 回答
0

例如，您应该考虑每周/每月拥有一个 Solr 核心，这样较旧的核心将是只读的，并且更易于管理并且很容易分布在多个 Solr 实例上。如果每天要添加 20 万个文档，那么您需要那个或 Solr 分片，那么单个内核永远都不够。

于 2012-04-19T13:50:06.893 回答