我不会直接说它受限,但只要我看得到给出的建议都是“如果你需要超越这个范围,你可以改变后端存储...”。为什么?当超过150-200m三元组时,为什么Sesame不像OWLIM或Allegrgraph那样高效?为了达到如此大的规模,采取了哪些优化措施?底层数据结构是否不同?
我不会直接说它受限,但只要我看得到给出的建议都是“如果你需要超越这个范围,你可以改变后端存储...”。为什么?当超过150-200m三元组时,为什么Sesame不像OWLIM或Allegrgraph那样高效?为了达到如此大的规模,采取了哪些优化措施?底层数据结构是否不同?
以下为@Jeen Broekstra 回答: http://answers.semanticweb.com/questions/21881/why-is-sesame-limited-to-lets-say-150m-triples
- RDF语句中实际的值(即主题、谓语和宾语)在一个相对简单的哈希表中被索引,将整数ID映射到实际数据值。该索引通过内存缓存来加速查找,但随着存储空间的增加,插入或查找期间需要从硬盘检索的值不在缓存中的概率增加,并且磁盘查找本身随着哈希表大小的增加而变得更加昂贵。
- 本地存储的数据检索已经平衡,以充分利用文件系统页面大小,以最大限度地提高B树节点的检索速度。此优化依赖于连续的查找重用相同的数据块,以便可以重用操作系统级别的页面缓存。然而,随着事务大小(因此是B树)的增长,这种启发式开始经常失败。
- 随着B树的增长,大规模级联分裂的机率增加。