这些是http://elki.dbs.ifi.lmu.de/的引号：
“基本上，我们将抽象距离查询绑定到数据库，然后获取最近邻居搜索此距离。此时，ELKI将自动选择最合适的kNN查询类。如果存在适当的索引距离函数（不是每个索引都可以加速每个距离！），它会在这里自动使用。“
“getKNNForDBID方法可以归结为慢速线性扫描，但是当数据库具有适当的索引时，将使用索引查询。然后算法可以在O（nk log n）或甚至O（nk）中运行时间“。
问题是：ELKI选择在什么基础上运行索引查询？
是什么意思：“当数据库具有适当的索引时”，我该如何保证？
关于“run”方法签名的另一个无关紧要的问题， 为什么有3个签名而不是1个？他们之间有什么区别， 以及确定使用哪个签名的标准是什么？
答案 0 :(得分：1)
在ELKI wiki中有一个关于此的页面：http://elki.dbs.ifi.lmu.de/wiki/HowTo/Index
基本上，您必须使用-db.index添加索引。然后，如果索引支持距离度量，它将自动使用。 R * -Tree似乎是最强大的。还有一个关于为自定义距离函数添加R树索引支持的教程：http://elki.dbs.ifi.lmu.de/wiki/Tutorial/SpatialDistanceFunctions
至于第二个问题：run(Database)中有一个AbstractAlgorithm方法，它使用内省来检查替代方法签名。这是一个烂摊子，但能够选择其中一个签名实际上很方便。请确保您的getInputTypeRestriction()匹配。当你处理多种关系时，这是有道理的。只要你生活在“一切都是（单一）载体”的思考中，它似乎是多余的;但即便如此，拥有{em>已经已具有要处理的数据关系的run(Database database, Relation<O> relation)签名也很方便。
答案 1 :(得分：1)
这主要是@ Anony-Mousse的帖子的后续行动，该帖子非常适合。
用户需要将索引添加到数据库中。当前没有自动索引（因为任何索引都需要额外的内存和构建时间）。 -db.index是此参数。支持自动索引是在愿望清单上，但它需要仔细调整成本模型。在小数据集或高维数据上，或者当用户根本不需要这种类型的查询时，添加索引将付出代价。
数据库将按顺序将查询请求转发给每个索引。 提供加速的第一个索引获胜。如果没有索引返回加速查询，则数据库将回退到线性扫描，除非提供了提示DatabaseQuery.HINT_OPTIMIZED_ONLY。在这种情况下，将返回null。可以通过QueryUtil强制执行线性扫描，这对于单元测试索引非常有用。
M-Trees可以使用任何数字距离，但如果距离不是公制，则结果可能不正确。如果距离函数未将isMetric()报告为真，则应报告错误。
R-Trees可以使用任何实现SpatialPrimitiveDistanceFunction的距离函数，这实际上意味着实现下限点到矩形的距离。对于许多距离函数可以找到下限，但效果可以变化。例如，角度距离将从R树使用的矩形页面中受益更少。
至于run方法。通常的矢量空间方法的首选签名是
YourResultType run(Database database, Relation<V> relation)
截至目前，数据库实际上可以通过relation.getDatabase()获得，但这可能会在未来发生变化。在许多情况下，这是有问题的，并且遗憾的是，目前无法轻易删除某些情况。无论如何，这是显式形式，方便从Java代码运行算法，即它允许我指定使用哪个关系，而不必使用数据库，这是唯一合适的关系（因此它会自动选择）。
我确实计划从长远来看使其更加明确，为选择要处理的数据子集添加明确的支持，也可能是查询。然后抽象的父run方法会处理这个问题。 自动优化器将依赖于此：它将首先查询所有要运行的算法，包括查询要求。根据查询，数据集，可用内存等，优化器可以选择适当的索引，并为算法传递适当的查询方法。
为了简化run签名，可能会通过一些Instance类处理，而更多地使用工厂模式。但现在不要担心。
如果您想了解为什么我们需要这个，请查看例如：地理空间离群检测算法。例如SLOM使用的签名是：
OutlierResult run(Database database, Relation<N> spatial, Relation<O> relation)
即。 SLOM使用两个两个关系。第一个关系是实例的空间关系，例如地理位置。第二种关系是实际数据，例如测量。地理位置用于确定预期哪些实例相似（但这些实例也可以是多边形！），而第二关系指定实际然后比较相似性的数据。