質問：冗長性の高い強力なハッシュでインデックス付けされた非常に大規模な（数テラバイト）データベースを処理するために、どのような解決策またはヒントが必要ですか？
ある種の逆ストレージ？
Postgresでできることはありますか？
必要に応じて、自分のストレージをロールバックする準備ができています。
（ヒント：オープンソースである必要があり、Javaでなく、Linuxで実行されている必要があり、ディスクベースである必要があります。C/ C ++ / Pythonを推奨します）
詳細：
各レコードに次のような非常に大きなデータベースを作成する必要があります。
- いくつかの主キーを含むいくつかの任意のメタデータ（いくつかのテキストフィールド）
- 1つのハッシュ（128ビットハッシュ、強力なMD5のような）
レコードの量は、私が非常に大きいと見なすものです：数百から数千億）。行間でハッシュの大幅な冗長性があります（レコードの40％以上でハッシュが少なくとも別のレコードと共有されており、一部のハッシュは100Kレコードに存在します）
主な使用法は、ハッシュで検索してからメタデータを取得することです。二次的な使用法は、主キーで検索してからメタデータを取得することです。
これは分析タイプのデータベースであるため、全体的な負荷は中程度で、ほとんどが読み取り、少数の書き込み、ほとんどがバッチ書き込みです。
現在のアプローチは、主キーにインデックスを付け、ハッシュ列にインデックスを付けて、Postgresを使用することです。テーブルは、ハッシュのインデックスをオフにしてバッチでロードされます。
すべてのインデックスはbtreeです。ハッシュ列のインデックスは、テーブル自体と同じかそれ以上に大きくなっています。120 GBのテーブルでは、インデックスを再作成するのに約1日かかります。ただし、クエリのパフォーマンスは非常に優れています。
問題は、ターゲットデータベースの予測サイズが4TBを超えることです。これは、ターゲット全体の約10％に相当する400GBの小さなデータセットを使用したテストに基づいています。Postgresに読み込まれると、残念ながら、ストレージの50％以上がハッシュ列のSQLインデックスによって使用されています。
これは大きすぎます。そして、ハッシュの冗長性は、より少ないストレージの機会であると感じています。
これは問題を説明していますが、作成する必要のあるこれらのテーブルがいくつかあることにも注意してください。