2012-09-08 37 views
1

我已经有了一个场景,其中的文档在弹性搜索中被编入索引,并且我需要检索mongo中的匹配文档以及按照时间戳排序的前面和后面的文档。这个想法是与原始文档一起检索文档的上下文。基于_id获取顺序文档

如果我使用顺序的_id,我现在能够成功完成此操作。作为一个例子,使用下面的数据:

[ 
    {_id: 1, value: 'Example One' }, 
    {_id: 2, value: 'Example Two' }, 
    {_id: 3, value: 'Example Three' }, 
    {_id: 4, value: 'Example Four' }, 
    {_id: 5, value: 'Example Five' }, 
    {_id: 6, value: 'Example Six' }, 
    ... 
] 

如果我搜索在ES“四”,我回来的4文档_id,因为它是连续的,我可以创造一个蒙戈查询拉ID之间的范围 - 2和id + 2,在这种情况下是2 - 6.只要我不删除文档,这种方式效果很好。当我删除一个文档时,我将不得不重新编制整个系列的索引以消除差距。我正在寻找一种达到相同结果的方式,同时也能够删除文件而无需更新所有文件。

我很乐意使用其他技术来实现这一点,我不一定与mongodb绑定。

回答

0

这个问题与MongoDB无关,与使用不同的数据库(例如RDBMS)没有什么不同。您将不得不循环查找小于/大于当前ID的文档ID,并查找前两个匹配项。是的,这意味着您需要执行多个查询。唯一的其他选择是在MongoDB之上实现链接列表,您可以在其中存储指向左右邻居节点的指针。是的,在删除的情况下,您需要调整指针(基本数据结构算法....)。缺点是:您将需要多个操作才能执行更改。由于MongoDB不是事务处理,你可能遇到不一致的前一个/下一个指针....这就是为什么MongoDB完全在这里吸引。

+0

使用RDBMS时还有其他方法可以解决这个问题。例如,使用SQL Server,我可以使用带有ROW_NUMBER的CTE。我可能能够使用地图缩小功能获得我正在寻找的内容。我得看看那个。 –

1

我可以使用类似以下的预期效果:

collection.find({_id: { $gte: matchedId } }).limit(3); 
collection.find({_id: { $lt: matchedId } }).sort({$natural: -1}).limit(2); 

不太一样好使用一个明确的范围,但没有必要重新计算文件删除任何东西。

是的,我知道limitations of natural order,这对我的特殊用例不是问题。

+0

关于自然顺序的一个注意事项:除非您有上限的集合,否则随着时间的推移自然顺序将与您期望的“上一个/下一个”文档不匹配。特别是文档的删除和移动会在可以插入或移动文档的可用数据空间中产生差距。如果您期待某个订单(例如广告订单),则应该使用显式索引排序()。在你的例子中,你想要在'_id'字段上排序。 – Stennie