1

アプリケーションの通知を並べ替えられたセットまたは Redis のリストに保存したい (通知もあるリンク短縮機能です)。さまざまな種類の通知があるため、通常の文字列のように保存することはできません。たとえば、保存したい場合：

  • 通知テキスト
  • 通知の種類

私には2つのアプローチがあります。1 つは、Json をシリアル化してプレーンな文字列のように格納し、使用するときに逆シリアル化することです。または、キーをリストに保存し、Redis を別のデータ構造に再度ヒットして、リストに保存されたキーで通知ハッシュを取得する方法もあります。

通知システムのように、システムは常に読み取りと書き込みを行っています。

それで、数行のデシリアライゼーションとシリアライゼーション VS 分割されたデータと複数の DB ヒットでしょうか?

私はこの種の意思決定の経験があまりないので、誰かがこれに直面し、効率とスケーラビリティの観点から最善のアプローチを知っているか、少なくとも意思決定の方法を説明してくれるかもしれません。私/私のアプリの決定は、他の/他のアプリの決定ではありません。

ありがとうございました ：）

4

1 に答える 1

4

いくつかのテストを行った後、最高のスコアは Json のシリアル化されたデータのケースになります。シリアライゼーション構造にも依存すると思います。テスト ケースでは、2 つのフィールド構造のみをシリアル化します。

いくつかの結果 (秒単位の時間):

Users: 600
Notifications per user: 1200
--------------------
#### With Json in Set structure ####
Write time: 93.0
Read time: 6.65
dbsize (number of keys): 600
Memory: 150.60M
#### With set and hash data structures ####
Write time: 367.72
Read time: 40.2
dbsize (number of keys): 721200
Memory: 224.17M

測定のテストについて少し説明します (私は Python を使用しました)。

Jsonシリアライゼーションの場合、ソートされたセット（zset）（ユーザーごとの通知zset）を使用しました。そのスコアはUNIXタイムスタンプ（float）です。2 フィールド ハッシュ (Python dict) をシリアル化し、文字列を並べ替えられたセットに追加します。

検索のために、すべての zset 文字列を取得し、データを 1 つずつ逆シリアル化します。

ハッシュ アプローチでは、次の 3 つのデータ構造を使用しました。

  • 最も単純なものは、通知ごとの一意のキーの作成に使用される通知 zset ごとのカウンターです (UUID でもテストしたところ、結果は多かれ少なかれ同じだったので、大きな違いはありません)。
  • もう 1 つのデータ構造は zsets で、Json の場合と同じですが、Json データを保存する代わりに、通知ハッシュ キーを保存します。
  • 最後の 1 つは、すべてのデータ フィールドを含む通知ハッシュです。

データを取得します。json の場合とほぼ同じですが、各 zset からすべてのキーを取得し、すべての通知を 1 つずつ取得します。

通常、すべての通知を取得するわけではなく、テストにバグがあるか、この状況に対するより良いアプローチがある可能性があるため、このケースは私が直面しているケースではないことはわかっています。

とにかく、ここにいくつかの測定値とテストスクリプトがあります

于 2013-04-04T14:03:07.910 に答える