私の仕事では、数十億のトリプルを使用する巨大なアプリケーションを構築しています。これらのトリプルを格納するために必要なスペースを最適化するために、私はトリプルを表現する別の方法を探していました。より経済的な方法であれば何でも歓迎します。ありがとう
4 に答える
数十億のトリプルを格納するために必要なスペースが、SQL データベースに数十億の行を格納するために必要なスペースよりも現実的に悪いとは思いません。
ほとんどのシステムがネイティブ ストア/SQL ベースのどちらであるかにかかわらず、一般的なアプローチは、ノードに ID を割り当て、各トリプルを 3 つのノード ID として保存することです。ノード ID 生成の適切な選択と、ノード ID とノード値の間の効率的なインデックスがあれば、大規模にスケールアウトするストアを簡単に構築できます。
さらなる最適化として、一部のストアでは、単純な値の型 (整数、ブール値、日時など) の値が直接ノード ID にエンコードされるようにノード ID を生成するため、ID から値へのルックアップを行う必要はありません。 (またはそのようなデータを挿入する場合はその逆)
また、neo4j のように、物事をトリプルとして保存しないクラス全体のグラフ ストレージ システムもあります。しかし、物事をトリプルとして保存するという理由だけで、トリプル ストアを除外するつもりはありません ;-) 今日の現在のソリューションの多くは、すでに数十億のトリプルを保存しているため、元に戻すことはできません (ただし、それよりも 1 つまたは 2 つのオーダーが高くなると、物事は取得されます)。タフ)。私は個人的にアレグログラフの店を10億以上で埋め尽くしました.
このスレッドを参照してください: http://www.semanticoverflow.com/questions/3332/scalable-owl-rdf-database
RobV が言うように、ほとんどすべてのストアが内部値/ノード ID をトリプルの要素に付加します。そうは言っても、トリプル ストアの多くのスペースは、ルックアップに必要なさまざまなインデックスによって占有されます。リレーショナル データベースでは、使用しているデータモデルに基づいてインデックスの数を簡単に減らすことができます。トリプル ストアでは、これは非常に難しく、ストアは基本的に、トリプルの要素を順序付けできるさまざまな方法で多数 (6 つ以上) のインデックスを作成します。