6

在我的工作中，我们正在构建一个巨大的应用程序，它将使用数十亿个三元组，以优化存储这些三元组所需的空间，我一直在寻找一种不同的方式来表示它们，任何更经济的方式都是受欢迎的。谢谢

4

4 回答 4

3

我认为存储数十亿个 Triples 所需的空间实际上并不比在 SQL 数据库中存储数十亿行所需的空间差。

无论原生存储/基于 SQL 的大多数系统采用的一般方法是将 ID 分配给节点并将每个三元组存储为仅 3 个节点 ID。给定节点 ID 生成的良好选择以及节点 ID 和节点值之间的有效索引，您可以轻松构建大规模扩展的存储。

作为进一步的优化，一些商店生成节点 ID 的方式是简单的值类型（例如整数、布尔值、日期时间等）将其值直接编码到节点 ID 中，因此无需从 ID 到值进行查找（或在插入此类数据时反之亦然）

于 2011-03-12T09:54:16.950 回答
3

还有一整类图形存储系统不会像 neo4j 那样将事物存储为三元组。但是，我不会仅仅因为它们将东西存储为三元组而排除三元组商店；-) 今天的许多当前解决方案已经存储了数十亿个三元组，所以它是不可撤销的（尽管你得到的订单比得到的多 1 或 2 个订单艰难的）。我个人已经用超过 10 亿美元填满了 Allegrograph 商店。

看到这个线程： http ://www.semanticoverflow.com/questions/3332/scalable-owl-rdf-database

于 2011-03-11T15:28:41.457 回答
2

正如 RobV 所说，几乎所有商店都将内部值/节点 ID 附加到三元组的元素上。话虽如此，查找所需的各种索引占用了三重存储的大量空间。在关系数据库中，您可以根据所使用的数据模型轻松减少索引数量。在三元存储中，这要困难得多，并且存储基本上会根据可以对三元的元素进行排序的不同方式创建大量（6+）索引。

于 2011-03-14T10:07:51.173 回答
0

有很多所谓的三联店。请参阅Wikipedia或W3C并选择一个。

于 2011-03-11T13:42:53.757 回答