使用Solr保持对事件历史的审计

Question

我需要对事件进行审核，并且需要快速查询此审核。审核应在线保存7年。每天大约10万次活动，但可能会增加。事件通常会多次重发。事件足够大，以至于我不会多次存储它们会带来好处。

逻辑上，在非规范化的JSON中，我的事件看起来像这样：

{
    correlationIds: [],
    payload: "",
    history: [
        {
            uniquePublishId: "",
            time: "",
            consumed: [
                {
                    system: "",
                    time: "",
                    audit: ""
                }
            ]
        }
    ]
}

每个事件都可以多次发布，每次发布时，都会在history数组中添加一个新项目。每次使用事件时，都会将一个项目添加到consumed数组中。

correlationIds是一个字符串数组，可用于搜索事件，因此每次发布时都会包含每个uniquePublishId。

将运行的典型查询，预计接近即时响应：

• 按uniquePublishId
查找活动
• 按相关ID查找事件。
• 按发布日期/时间范围查找事件
• 按消费日期/时间范围查找事件
• 查找已发布但未被特定system
消费的事件

现在我正在考虑使用Solr存储它来给我快速搜索我想要的，但是我想知道如何最好地存储它以便我能够有效地搜索。

每个馆藏的文件限额为21亿IIRC，但我想我可以按年份存储在多个馆藏中。

所以我的问题：

如何存储这些事件以确保快速搜索时间？我不希望每次要向history添加新事件发布时，或者当我向consumed数组添加消息时，都必须提取消息有效负载。

从谷歌搜索，看起来我可以将它们存储在单独的集合中并进行交叉集合加入 - 但我不知道这会如何影响性能。现在这已经引领我进入规范化的领域，我甚至应该使用Solr？

Answer 1

此问题非常适合Solr，但使用Solr Cloud，最好在HDFS上存储索引，以便在N个数据节点之间实现最佳读取分配。 Solr 5.3提供了json faceting，它提供了丰富的查询功能（并将涵盖您上面列出的问题）。

每年有超过3600万个事件可用于索引或搜索。正如你所提到的，按年份划分是完美的。

加入多个集合可能会带来挑战（例如，维护可能会导致错误的结果，编写复杂的查询等）。

我做了类似的设置但是推文。按月划分的14.4亿条推文被索引。每个推文JSON在磁盘上大约是2K。等等 磁盘Solr大小约为1TB。查询时间平均为3秒 一个5数据节点的Hadoop集群。