这些是来自http://elki.dbs.ifi.lmu.de/的引号：
“本质上，我们将抽象距离查询绑定到数据库，然后对这个距离进行最近邻搜索。此时，ELKI 会自动选择最合适的 kNN 查询类。如果存在适合我们距离函数的索引（不是每一个索引都能加速每一个距离！），这里会自动使用。”
“getKNNForDBID 方法可能归结为缓慢的线性扫描，但是当数据库有合适的索引时，会使用索引查询。然后算法可以在 O(nk log n) 甚至 O(nk) 时间内运行。”
问题是：ELKI 选择运行索引查询的依据是什么？
什么是：“当数据库有适当的索引时”，我如何保证？
关于“运行”方法签名的另一个不相关的问题，为什么有 3 个签名而不是只有 1 个？它们之间有什么区别，确定使用哪个签名的标准是什么？
ELKI wiki 中有一个关于此的操作指南页面：http: //elki.dbs.ifi.lmu.de/wiki/HowTo/Index
本质上，您必须使用-db.index. 如果索引支持距离度量，它将自动使用。R*-Tree 似乎是最强大的。还有一个关于为自定义距离函数添加 R-tree 索引支持的教程：http: //elki.dbs.ifi.lmu.de/wiki/Tutorial/SpatialDistanceFunctions
至于第二个问题：有一种run(Database)方法AbstractAlgorithm使用自省来检查替代方法签名。乱七八糟，但实际上可以选择其中一个签名很方便。只要确保，你的getInputTypeRestriction()比赛。当您处理多个关系时，这很有意义。只要你活在“一切都是（单一）向量”的思维中，就显得多余了；但即便如此，拥有一个已经具有要处理的数据关系的run(Database database, Relation<O> relation)签名也很方便。
这主要是对@Anony-Mousse 帖子的后续跟进，非常有针对性。
索引需要由用户添加到数据库中。当前没有自动索引（因为任何索引都需要额外的内存和构建时间）。-db.index是这个的参数。对自动索引的支持在愿望清单上，但它需要仔细调整成本模型。在小数据集或高维数据上，或者当用户根本不需要这种类型的查询时，添加索引是有代价的。
数据库会将查询请求按顺序转发到每个索引。第一个提供加速的指数获胜。如果没有索引返回加速查询，除非给出提示，否则数据库将回退到线性扫描DatabaseQuery.HINT_OPTIMIZED_ONLY。在这种情况下，null将被退回。可以通过 强制进行线性扫描QueryUtil，这对于单元测试索引最有用。
M-Trees 可以处理任何数字距离，但如果距离不是度量标准，则结果可能不正确。isMetric()如果距离函数未报告为真，则应报告错误。
R-Trees 可以与任何实现 的距离函数一起使用SpatialPrimitiveDistanceFunction，这实质上意味着实现一个下界点到矩形的距离。可以找到许多距离函数的下限，但有效性可能会有所不同。例如，角距离从 R-tree 使用的矩形页面中受益少得多。
至于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使用两个两个关系。第一个关系是实例的空间关系，例如地理位置。第二个关系是实际数据，例如测量值。地理位置用于确定哪些实例预计是相似的（但这些实例也可以是多边形！），而第二个关系指定实际然后比较相似性的数据。