Solandra 取代我们的 Lucene +关系型数据库管理系统？

Question

目前我们正在使用SQL Server和Lucene的组合来索引一些有关域名的关系数据。我们有一个域表，以及大约 10 个其他各种表，用于存储我们计算和存储的有关域的不同指标的历史记录。例如：

Domain

• Id BIGINT
• Domain NVARCHAR
• IsTracked BIT

SeoScore

• Id BIGINT
• DomainId BIGINT
• Score INT
• Timestamp DATETIME

我们正在尝试将主要区域文件中的所有域包含在我们的数据库中，因此我们最终会查看大约 6 亿条记录，这似乎在 SQL Server 中扩展会有点麻烦。鉴于我们依赖 Lucene 来执行一些相当高级的查询，Solandra 似乎是一个不错的选择。我很难不以关系数据库术语来思考我们的数据。

SeoScore 表将映射一个到多个域（每次计算分数时一条记录）。我认为，用 Solandra 的术语来说，实现这一目标的最佳方法是使用两个索引，一个用于 Domain，一个用于 SeoScore。

以下是我们需要实现的查询场景：

1. 每个域的最新指标的“当前快照”（即给定域的最新 SeoScore。我假设我们会首先找到我们想要的域记录，并且然后运行进一步的查询以分别获取每个指标的最新快照。

2. 自 x 日期以来未检查 SeoScore 且 IsTracked=1 的域名，因此我们将知道哪些域名需要重新计算。此处的批处理系统，以便我们可以“签出”域名并对它们运行计算，而无需重复工作。

我这里是不是偏离了轨道？在这种情况下，我们将表基本上映射到 solandra 中的单独索引是否正确？

更新

以下是我的想法的一些 JSON 表示法：

Domains : { //Index
    domain1.com : { //Document ID
        Middle : "domain1", //Field
        Extension : "com",
        Created : '2011-01-01 01:01:01.000',
        ContainsDashes : false,
        ContainsNumbers : false,
        IsIDNA : false,
    },
    domain2.com {
        ...
    }
}

SeoScores : { //Index
    domain1.com { //Document ID
        '2011-02-01 01:01:01.000' : { 
            SeoScore: 3 
        },
        '2011-01-01 01:01:01.000' : {
            SeoScore: -1
        }
    },
    domain2.com {
        ...
    }
}

Answer 1

对于 SeoScores，您可能需要考虑使用虚拟核心：

https://github.com/tjake/Solandra/ wiki/ManagingCores

这允许您按域对数据进行分区，这样您就可以拥有 SeoScores.domain1 并使每个文档代表一个时间戳。

其余的听起来都不错。