Triplestore Atomの実装

Question

私はSQLデータベースの独自のtriplestore ontopを実装しようとしています（はい、そこにプロジェクトが完成していることは分かります）。シンボリックな "アトム"を実装する最良の方法を決定しようとしています。 。

純粋な設計では、subject、predicate、objectという3つのvarcharカラムを持つ単一の「トリプル」テーブルを作成して、SQLでトリプルストアを実装することがあります。スペースを節約するため、私は "atom"テーブルを作成しました。これは、任意の件名/述語/オブジェクトフィールドで使用される一意のテキストを格納し、それらのフィールドをテキストを含むアトムにリンクする外部キーに変更します。

しかし、私はAtomテーブルを実装するいくつかの方法を見ています。

1. テキストをvarcharとして保存します。

   • 長所：テキストを一意に索引付けして強制することが簡単です。
   • 短所：任意の大きなテキストを保存できませんでした。

2. テキストをテキストブロブとして保存し、一意性を照会して実施するときに使用するテキストのハッシュとして保存します。

   • 長所：任意の大きなテキストを保存できました。
   • 短所：少し複雑です。おそらく、まれではあるが、ハッシュの衝突はハッシュアルゴリズム（md5、shaなど）に依存します。パフォーマンス、長期信頼性、およびあらゆる種類のデータを格納する機能の面でより良いアプローチです

？ハッシュを使用している場合、衝突について有効な懸念がありますか？たとえ衝突が稀であっても、トリプルストアを壊すためには一度しか起こらないでしょう。

Answer 1

を証明するまで、これを最適化しようとすると時間を無駄にしないでください。ボトルネックであり、修正するのが最も重要です。

「スペースを節約するには...」しないでください。スペースはほとんど無料です。テラバイト以上のデータがなければ、心配する必要はありません。ストレージが考える価値よりもストレージを考える時間を簡単に無駄にすることができます。

varcharソリューションは正常に機能し、スケーラビリティが向上します。 "文字列プール"や "アトムテーブル"の考え方は、実際には同じ基本オブジェクトへの参照がたくさんあるため、実際には優れています。なぜvarcharを繰り返すのですか？インデックス番号を繰り返すのはなぜですか？

「任意の大きなテキスト」は奇妙な要件です。なぜ迷惑？

ブロブの方が一般的に遅くなります。ハッシュの衝突は、理論上の懸念ではありませんが、2つの方法で対処するものです。まず、32ビット以上のハッシュを使用します。第二に、あなたが（愚かにも）実際のブロブをチェックして実際に同じかどうかを確認しない限り、衝突によって何かが損なわれることはありません。衝突がないことを確認するためにブロブ全体を比較しないようにするには、異なるアルゴリズムで2つのハッシュを保持します。