0

SQLデータベース上に独自のトリプルストアを実装しようとしています(はい、完成したプロジェクトがそこにあることはわかっています)。シンボリックな「アトム」を実装するための最良の方法を決定しようとしています。

単純な設計では、subject、predicate、objectと呼ばれる3つのvarchar列を持つ単一の「トリプル」テーブルを作成することにより、SQLにトリプルストアを実装できます。スペースを節約するために、サブジェクト/述語/オブジェクトフィールドで使用される一意のテキストを格納する「アトム」テーブルを作成し、それらのフィールドを、テキストを含むアトムにリンクする外部キーに変更しました。

ただし、Atomテーブルを実装する方法はいくつかあります。

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

    • 長所:テキストの一意性をインデックス付けして適用するのは簡単です。
    • 短所:任意の大きなテキストを保存できませんでした。
  2. テキストをテキストブロブとして保存し、一意性をクエリして適用するときに使用するテキストのハッシュも保存します。

    • 長所:任意の大きなテキストを保存できます。
    • 短所:もう少し複雑です。まれですが、ハッシュアルゴリズム(md5、shaなど)によっては、衝突が発生する可能性があります。

パフォーマンス、長期的な信頼性、およびあらゆる種類のデータを保存する機能の観点から、どちらが優れたアプローチですか?ハッシュを使用する場合、衝突についての正当な懸念はありますか?衝突がまれであっても、トリプルストアを破損するのは1回だけです。

4

1 に答える 1

1

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

「スペースを節約するために...」しないでください。スペースはほとんど無料です。テラバイトを超えるデータがない限り、心配する必要はほとんどありません。ストレージの価値よりも、ストレージについて考える時間を簡単に浪費する可能性があります。

varcharソリューションは機能し、正常にスケーリングします。「文字列プール」または「アトムテーブル」のアイデアは、同じ基になるオブジェクトへの参照がたくさんあるため、実際には良いアイデアです。なぜvarcharを繰り返すのですか?インデックス番号を繰り返してみませんか?

「任意に大きなテキスト」は奇妙な要件です。なぜわざわざ?

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

于 2011-10-20T19:56:13.183 に答える