1

ペアごとの比較を含む辞書の辞書があるとします。

 dict_of_dict = {"apple":{"apple":1, "orange":.5, "banana":.7}, "orange":{"orange":1, "apple": .3, "banana":.8}, "banana":{"banana":1, "apple":.7, "orange":.8}}

各埋め込みディクショナリには、最大 20 万のエントリを含めることができます。

これを MySQL に格納する 1 つの (ひどい) 方法は、2 つのテーブルフルーツとフルーツ マッピングを作成することです。フルーツは各フルーツの ID を格納し、フルーツ マッピングは各ペアワイズ スコアを格納します。

果物は、ID と果物を持つ 2 列のテーブルです。

 fruit_id fruit
 0        apple
 1        orange
 2        banana

fruit mappingsは、ペアごとの比較ごとに、fruitの ID をスコアにマップします。

    fruit_id_A   fruit_id_B    score

       0               0         1        
       0               1        .5
       0               2        .7

...fruit_ids 1 と 2 についても同様です。~200k エントリを処理する場合、明らかな問題が見られます。実際のアプリケーションでは、果物のサブセットのみが比較されるため、最大 200k**2 行にはなりませんが、50,000 個の果物が 10,000,000,000 行になるスコアを受け取ると仮定しても. 誰かがより良いアプローチを持っていますか?

4

1 に答える 1

2

これを MySQL に格納する 1 つの (ひどい) 方法は、2 つのテーブル フルーツとフルーツ マッピングを作成することです。フルーツは各フルーツの ID を格納し、フルーツ マッピングは各ペアワイズ スコアを格納します。

これはひどいアプローチではありませんが、リレーショナル データベースの賢明なアプローチです。

果物のセットが変更されない場合に限り、果物とそのすべてのスコアを保持する float 上の配列を識別する 1 つのテーブルのみを使用できます。ただし、配列のどのインデックスが他のどの果物にマップされるかを知る必要があります。

私は明らかなリレーショナルアプローチを採用します。2 億行あることの何が悪いのかというと、アクセスする必要のある列にインデックスを付ければ、パフォーマンスの問題も発生しません。

于 2013-01-22T19:51:39.387 に答える