XSLT索引有许多相同的键的性能问题

我在许多上下文中使用XSLT键。通常，使用的密钥或多或少都是唯一的，而且非常罕见的重复实例。现在我定义了一个关键字，它有一些关键值的实例。准确地说：我正在处理一个具有@STEREOTYPE属性的420.000条目的1.7 GigaByte文件。一些刻板印象发生达90.000次。不过，这些并不是我感兴趣的。我想选择的那些通常可能有10到20个实例。XSLT索引有许多相同的键的性能问题

的键定义是

<xsl:key 
    name="entityByStereotype" 
    match="/REPOSITORY_DUMP/ENTITY_LIST/ENTITY" 
    use="@STEREOTYPE"/>

索引的建筑永远持续，即我通常为5或6小时后终止进程。

的替代密钥的定义是

<xsl:key 
    name="entityByStereotype" 
    match="/REPOSITORY_DUMP/ENTITY_LIST/ENTITY" 
    use="concat(@STEREOTYPE, @OBJECT_ID)"/>

迫使实例关键字是唯一的，它的构建返回14秒之后。我的假设是排序算法对于同一个键的多个实例不能很好地工作，从而导致具有相同键的所有子集的O（n ** 2）复杂度。对于90.000个条目的子集，这是非常糟糕的。 :-(

但是，我不能使用备用索引定义，因为我不知道事先实例的OBJECT_ID部分

任何想法非常感谢

撒克逊使用：？！9.1版.0.5

来源

2010-09-14 Marcus Rickert

您可以预处理输入文档以排除不需要的重复项吗？这可以通过例如使用快速SAX解析器。 – 2010-09-14 11:55:14

哪些是使ENTITY有趣的确切标准？你不能从这些标准中建立关键吗？ – 2010-09-14 12:07:03

准确的标准是寻找一个特定的STEREOTYPE。目前，没有其他的标准可用。预处理输入可能是一个选项。我可以将这个实体子集移动到XML树中的不同位置。通过一定的努力，这可能会解决特定的问题。但是，知道索引速度如此之慢的真正原因是很好的。另外，我们处理的其他部分实际上可以从STEREOTYPE上的这个特定索引中受益。 – 2010-09-14 12:47:42

你试过只使用<xsl:for-each-group>？

如果你提供一个合适的源XML文档我可能有兴趣帮助寻找更优化的溶胶ution。

更新：其他一些技巧，我建议：

1）如果你事先知道的@STEREOTYPE值中，你有兴趣，然后使用：

<xsl:key 
    name="entityByStereotype" 
    match="/REPOSITORY_DUMP/ENTITY_LIST/ENTITY[@STEREOTYPE = ($val1, $val2,...,$val-n)]" 
    use="@STEREOTYPE"/>

如果它们出现，就像你说的那样，只需10-20次，散列表（是的，排序对于实现键没有意义）将更容易构建。

2）将XML文档拆分为几个较小的（比如说10个）文档并分别进行处理。

来源

2010-09-14 13:13:06

通过名称选择相关的定型作业。非常感谢你！但是，我认为这种行为是一个错误。也许我应该把它与SAXON一起提交。 – 2010-09-29 08:52:03

XSLT索引有许多相同的键的性能问题

回答

相关问题