3

ポッドキャスト / オーディオ ファイルの 1 秒ごとの再生回数を保存する必要があります。これにより、x 軸が秒数、y 軸が再生数のシンプルなタイムライン グラフ (Google アナリティクスの「ヒット数」グラフのようなもの) になります。

ただし、これらのポッドキャストは最大 3 時間続く可能性があり、毎秒 100,000 回の再生は非現実的ではありません。これは、それぞれ最大 100,000 回の再生で 10,800 秒です。明らかに、再生された各秒を独自の行に格納することは非現実的です (10 億以上の行になることになります)。この生データを高速にフェッチできるようにしたいからです。

私の質問は、これらの膨大な量のタイムライン データを保存するにはどうすればよいでしょうか?

私が思いついたアイデアの 1 つは、テキスト/ブロブ列を使用して再生をコンマで区切ることでした。各コンマは (順番に) 新しい秒を表し、次にその秒が再生された回数を表します。したがって、1 秒目に 100,000 回の再生があり、2 秒目に 90,000 回の再生があり、3 秒目に 95,000 回の再生がある場合、text/blob 列に "100000,90000,95000,[...]" のように保存します。

これは、そのようなデータを保存するための実行可能な方法ですか? より良い方法はありますか？

ありがとう！

編集: データは別のソースに追跡されており、生のグラフ データを 15 分ごとに更新するだけで済みます。したがって、高速読み取りが主な関心事です。

注: このプロジェクトの性質上、再生された各秒を個別に追跡する必要があります (つまり、各再生の「開始」と「終了」を追跡することはできません)。

4

4 に答える 4

1

BLOB ストレージの問題は、すべての変更に対して BLOB 全体を更新する必要があることです。これは必ずしも悪いことではありません。フォーマットを使用すると、(100000, 90000,...), 7 * 3600 * 3 = ~75K バイトになります。しかし、これは、毎秒、再生ごとに 75K の BLOB を更新していることを意味します。

そしてもちろん、blob は SQL に対して不透明であるため、「どの曲のどの秒が最も多く再生されたか」は、SQL レベルでは不可能なクエリになります (これは基本的に、それを学習するためのすべてのデータのテーブル スキャンです)。

また、そのデータの入出力をマーシャリングするために、多くの解析オーバーヘッドが発生します。

一方で。Podcast ID (4 バイト)、秒のオフセット (符号なしの 2 バイトで最大 18 時間の Pod キャストが可能)、再生回数 (4 バイト) = 1 秒あたり 10 バイト。したがって、ブロッキング オーバーヘッドを差し引くと、3 時間の曲は 3600 * 3 * 10 = 1 曲あたり 108K バイトになります。

それを blob として保存した場合、テキスト (long のブロック) に対して、4 * 3600 * 3 = 43K になります。

したがって、2 番目/行の構造は、バイナリ BLOB のサイズの「わずか」2 倍です (完全な世界では、詳細については DB サーバーを参照してください)。これにより、クエリを実行できるという点で得られる追加の利点を考慮すると、おそらく実行する価値があります。

秒/行の唯一のマイナス面は、多くの更新 (1 つの曲に対して一度に数秒) が必要な場合です。これは、DB への大量の UPDATE トラフィックですが、blob メソッドでは、それはおそらく 1 回の更新です。

あなたのトラフィックパターンは、それ以上に影響を与えます。

于 2010-07-14T22:39:13.647 に答える
0

それは本当にデータを生成しているものに依存します..

私が理解しているように、キーが2番目のマークで、値が再生回数であるマップを実装する必要があります。

ロードしているイベント、作業単位、またはトランザクションのピースは何ですか？

ポッドキャスト名、開始時間、停止時間に沿ってプレイイベントがあり、分析とプレゼンテーションのためにマップにロードしたいとしますか？

その場合は、テーブルを持つことができます

  • podcastId
  • secondOffset
  • 再生回数

それぞれが開始位置と終了位置の間の行の更新を行います

t set playCount = playCount +1を更新します。ここで、podCastId = xであり、yとzの間のsecondOffsetです。

次に、テーブルにゼロをプリロードしない限り、開始と停止の間に存在しない行を追加するための挿入が続きます。再生回数は1です。

DBによっては、空の列が格納されていないスパーステーブルを設定できる場合があり、効率が向上します。

于 2010-07-14T22:16:39.347 に答える
0

私はそれをキーと値の問題と見なします。

for each second played

   Song[second] += 1

end

リレーショナル データベースとして -

song
----
name | second | plays

そして、ハック psuedo-sql で 2 番目を開始します。

insert into song(name, second, plays) values("xyz", "abc", 0)

もう1つは2番目を更新します

update song plays = plays + 1 where name = xyz and second = abc

3 時間のポッドキャストには 11,000 行あります。

于 2010-07-14T22:06:41.450 に答える
0

1 秒ごとに使用するのは問題になりますか? また、1 秒あたりの再生数はいくつですか? これは 10K 行を意味しますが、これは悪くありません。現在のデータで 1 秒ごとに行を INSERT する必要があります。

編集: TEXT 列でコンマ区切りの何かを行うよりもソリューションの方が優れていると言えます...特に、データの取得と操作(やりたいこと)は非常に面倒です。

于 2010-07-14T21:57:54.380 に答える