3

ブール値を持つ多くの（10〜40）変数があるPostgresqlデータベースを作成しています。適度な数の更新と多数の複数列検索を考慮して、このデータを保存するための最良の方法を理解したいと思います。

30ほどのブール列を作成し、必要に応じて複数列のインデックスを作成するのは非常に簡単なようです。あるいは、誰かがすべてのブール値を組み合わせたビット文字列を作成することを提案しました。2番目のオプションの方が速いはずですが、他の人がオンラインで出した答えは矛盾しているようです（以下を参照）。

どんな提案や説明も役に立ちます。データは数千万行ですが、それより大きくはありません。selectはデータの1 / 100〜1/4のどこかに戻ると思います。

https://stackoverflow.com/questions/14067969/optimized-sql-using-bitwise-operator

postgresqlのビットマップインデックスの代替

アップデート：

変数が数個より多く（別々の列を使用する必要がある場合）、33個より少ない場合（ビット文字列に切り替える場合）にintまたはbigintを使用することを提案するリソースが1つ見つかりました。これは、検索のしやすさよりもストレージのサイズに動機付けられているようです。

https://dba.stackexchange.com/questions/25073/should-i-use-the-postgresql-bit-string

4

1 に答える 1

1

データベース管理者サイトで関連する議論を見つけました。

まず、あなたのコンテキストで何が「最善」であるかを定義/分析します。速さだけを求めていますか？あなたの検索パターンは何ですか？データ/ディスク ボリュームは問題ですか?

どのような代替手段がありますか? ビット文字列のほかに、通常のテキスト文字列、整数配列、および個別の列を使用できます。データをすばやく取得するには、索引付けについて考える必要があります。複数列のインデックスについて言及しました。同じビット変数を複数のインデックスに格納/インデックス付けすることは理にかなっていますか?

重複レコードが多すぎない 40 ビットは、最大 2^20 = 1.1E12 レコードを意味します。これにより、テーブル全体のスキャンに時間がかかります。一方、重複キーが多数ある場合、インデックス作成はあまり役に立ちません。

約 25% の結果セットが期待される場合は、データベースとアプリケーションの間で 2.7E11 (部分) レコードを転送する必要があります。10,000 レコード/秒と仮定すると、これには 7,736 時間または 10 か月かかります。

私の結論は、データを大きな BLOB に格納することを検討する必要があるということです(1.1E12 x 40 ビットはちょうど 40 GB です)。データを分割し、興味深い部分をメモリに読み込んで、そこで検索を行うことができます。これは、多かれ少なかれ BigData または Datawarehouse システムが行っていることです。

于 2013-01-05T00:47:10.223 に答える