实现Triplestore原子

Question

我正试图在SQL数据库的基础上实现我自己的triplestore (是的，我知道有一些已经完成的项目)，并且我试图决定实现一个符号"atom“的最佳方法。

在简单的设计中，我们可以通过创建一个包含三个varchar列(名为subject、谓词、object )的单一“三重”表来实现SQL中的triplestore。为了节省空间，我将创建一个"atom“表，该表将存储在任何主题/谓词/对象字段中使用的唯一文本，并将这些字段更改为外键，链接回包含其文本的原子。

但是，我看到了几种实现Atom表的方法。

1. 将文本存储为varchar.

- Pros: Simple to index and enforce uniqueness of the text.
- Cons: It could not store arbitrarily large text.

​

1. 将文本存储为文本blob，以及查询和执行唯一性时要使用的文本散列。

- Pros: Could store arbitrarily large text.
- Cons: A little more complicated. Possibly, albeit rare, hash collisions depending on the hashing algorithm (md5, sha, etc).

​

在性能、长期可靠性和存储任何类型数据的能力方面，哪种方法更好？如果我使用哈希，是否存在对碰撞的有效关注？即使碰撞是罕见的，它也只需要发生一次就可以破坏三叉戟。

Answer 1

在证明是瓶颈，并且是最重要的修复问题之前，不要浪费时间来优化它。

“节省空间.”不要，空间几乎是自由的。除非你有超过一兆字节的数据，否则你没什么可担心的。你很容易把更多的时间浪费在存储上，而不是存储的价值。

varchar解决方案将工作和规模很好。“字符串池”或“原子表”的概念实际上是一个很好的想法，因为您将有很多对同一个基础对象的引用。为什么要重复这段话？为什么不直接重复一个索引呢？

“任意大的文本”是一个奇怪的要求。为什么要麻烦呢？

一个水滴一般会慢一些。哈希冲突--虽然只是理论上的关注--是你用两种方式处理的事情。首先，使用超过32位的散列。第二，碰撞不会破坏任何东西，除非你(愚蠢地)没有检查实际的斑点，看看它们是否真的相同。如果您想避免比较整个blob以确认是否存在冲突，请使用不同的算法保留两个散列。