1

大きな（30Kの非圧縮）JSON文字列をデータベースに保存する必要があります。文字列を圧縮するためにgzipを使用しているため、MySQLのBLOBデータ型を使用して文字列を格納しています。ただし、すべてのリクエストの5％のみに一意のデータが含まれており、データベースに保存する必要があるのは一意のデータのみです。

私のアプローチは次のとおりです。

  1. array_multisortデータ（配列[a, b, c]は実質的にと同じ[a, c, b]です）。
  2. json_encodeデータ（json_encodeより高速ですserialize。ステップ3には文字列配列表現が必要です）。
  3. sha1md5データ（衝突の可能性は低いですが、より遅い）。
  4. ハッシュがデータベースに存在するかどうかを確認します。
    • 存在する：データを挿入しないでください。
    • 新規：データをgzipで圧縮し、ハッシュに沿って保存します。

これについて（そもそもJSONデータをデータベースに保存することを除いて）怪しげに聞こえるか、別の方法で行う必要があるものはありますか？

データベースには、毎月約1kkの一意のレコードが作成されています。

4

1 に答える 1

0

あなたがしていることは、ある種の L2/永続/分散キャッシュのように思えます。

全体的なプロセスはまったく問題ありませんが、環境に最適なパフォーマンスを持つハッシュ アルゴリズムの使用を検討する必要があります。

MD5 は 128 ビットですが、SHA-1 は 160 ビットです。違いは非常に大きいです。MD5 には 2^128 (~3.4x10^38) があるかもしれませんが、SHA-1 には 2^160 (~1.4x10^48) があるかもしれません。MD5 を使用すると衝突が発生すると思いますか?

最良のシナリオでは、1 か月あたり 100 万件の一意のレコード (10^6) を想定すると、競合が発生するのに約 3.4x10^32 か月かかることになります。もちろん、MD5 が 2^128 を超えて均等に分布していなくても、これらは理論上の値です。

また、古い値を (LRU アルゴリズムのように) 破棄する必要があると考える場合は、格納する必要がなくなったため、より単純で高速なハッシュ アルゴリズムを使用することもできます。

いずれにせよ、パフォーマンスやストレージ容量が問題にならない場合は、衝突の可能性がはるかに低く、持続時間がはるかに長い SHA-1 を使用してください。

乾杯！

于 2012-08-27T22:18:36.877 に答える