1

世界中のすべての人に、幸福度を 1 から 10 までのスケールで尋ねなければならないと想像してください。誰もが答えます。最大 80 億人いるので、キーに bigint を使用する必要があり (別の DB に ID が既にあり、キーのみが必要であると仮定します)、実際には約 80 億の一意のレコードがあります。次に、レコードごとに 1 から 10 の値を格納する必要があります。ほとんどの DB では、バイト データ型にマップされます (これは単なる仮定であり、0 から 255 のスケールでも幸福度を測定できます)。

80 億人 * (8 バイトのキー + 1 バイトの値) = 64 Gb のキー値 + 8 Gb の値 = 72 Gb の合計サイズ。

SQL Server や MySql などの主流データベースで、同じタスクのストレージ サイズを大幅に削減することは可能ですか?

私はそのような投票を行うつもりはなく、それほど多くのユーザーもいません。大きなキーは、他のいくつかの int キーのデカルト積の結果であり、長期的には、それぞれに単純な数値を持つ何十億ものレコードを持つことができますより小さい ID の組み合わせ。

4

2 に答える 2

1

キーを使用できるようにするためにキーを保存する必要はありません。応答の配列が必要なだけです。したがって、80 億人は 80 億バイトになります。それで8GBです。

16 の可能な回答のみが必要な場合は、1 バイトに 2 つの回答を詰め込むことができ、4 GB まで削減できます。

これを本当に小さくて高速にしたい場合は、フラットファイルの方が良いとは言えませんが、同じくらい良いかもしれません。これは、使用の種類によって異なります。

ただし、本当にテーブルに入れたいが、それでも小さくしておく場合は、各レコードのキーを取り除く必要があります。たとえば、次のようにレコード間でキーを共有することでこれを行うことができます。

Key      n0 n1 n2 n3 n4 n5 n6 n7 n8 n9
00000000  7  1  2 13  7  8  9 11  2  9
00000010  3  7  8  9 11  2  6  7  9 12

回答00000000-00000009は記録00000000にまとめられ、回答00000010-00000019は記録にまとめられます00000010

于 2013-05-05T19:58:03.337 に答える
0

キーがまばらに分散されている場合、応答とキーを明示的にペアにする必要があります。このポーリングを、既にキー列がある別のテーブルに保存することで、労力を節約できます。

キーが連続している場合は、Ebbe のアプローチが最適です。テーブル構造を使用する必要がある場合は、このデータをたとえば 1024 個のシャードに分割し、キー ルックアップを実行するときにテーブルの ID によって暗示されるキーの最初の 10 ビットを使用できます。

キーの末尾からストレージを節約することもできます。たとえば、キーの最後の 10 ビットを保存したくありません。次に、キーを 10 ビットで切り捨て、そこに blob を格納します。これは 1024 応答のフラットな配列になります。

回答ごとに 10 個のテーブルを作成し、投票の回答に応じてそれぞれにキーを挿入することで、投票データ (1 バイト値) を保存できます (これは上記のいくつかと組み合わせて機能しません。回答範囲が広い）。

于 2013-05-05T20:07:53.413 に答える