4

Redis 上の MySQL に 4 列 8000 万行のデータをロードして、フェッチの遅延を減らしたいと考えています。

しかし、すべてのデータをロードしようとすると、5 倍の大きさになります。

元のデータは 3GB (csv 形式にエクスポートした場合) でしたが、Redis にロードすると 15GB かかります... システムには大きすぎます。

さまざまなデータ型も試しました-

1) 'table_name:row_number:column_name' -> 文字列 2) 'table_name:row_number' -> ハッシュ

しかし、それらはすべて多すぎます。

私は何かを逃していますか?

追加した)

私のデータには4つの列があります-(ユーザーID(pk)、カウント、作成時間、および日付)

4

2 に答える 2

8

最もメモリ効率の良い方法は、値を json 配列として保存し、ziplist でエンコードされたハッシュを使用して保存できるようにキーを分割することです。

  1. たとえばjson配列を使用してデータをエンコードすると、のようなキー=値のペアになりuser:1234567 -> [21,'25-05-2012','14-06-2010']ます。
  2. 2 番目の部分に約 100 の可能性があるように、キーを 2 つの部分に分割します。たとえばuser:1234567
  3. この結合されたキーを次のようなハッシュに保存しますhset user:12345 67 <json>
  4. ユーザー ID 9876523 のユーザー詳細を取得するには、単純hget user:98765 23に json 配列を実行して解析します
  5. hash-max-ziplist-entries と hash-max-ziplist-valueの設定を必ず調整してください

Instagram は、この手法を説明する素晴らしいブログ投稿を書いているので、なぜこれがメモリ効率に優れているのかについては説明を省略します。

代わりに、この手法の欠点をお伝えします。

  1. ユーザーの単一の属性にアクセスしたり更新したりすることはできません。レコード全体を書き直す必要があります。
  2. 一部のフィールドのみを気にする場合でも、常に json オブジェクト全体をフェッチする必要があります。
  3. 最後に、キーを分割する際にこのロジックを記述する必要がありますが、これはメンテナンスが追加されます。

いつものように、これはトレードオフです。アクセス パターンを特定し、そのような構造が適切かどうかを確認します。そうでない場合は、追加のメモリを購入する必要があります。

于 2012-05-25T02:36:53.817 に答える