Хранение огромного количества (простых) данных графика временной шкалы в БД

Question

Мне нужно сохранить количество воспроизведений на каждую секунду подкаста/аудиофайла. Это приведет к простому графику временной шкалы (например, графу «хиты» в Google Analytics) с секундами по оси х и воспроизведет по оси Y.

Однако эти подкасты могут продолжаться до 3 часов, а 100 000 пьес за каждую секунду нереальны. Это 10 800 секунд до 100 000 игр каждый. Очевидно, что сохранение каждого второго в своей строке нереалистично (это приведет к 1 миллиарду строк), поскольку я хочу иметь возможность быстро извлекать эти необработанные данные.

Итак, мой вопрос: как мне лучше всего хранить эти огромные объемы данных временной шкалы?

Одна из моих идей заключалась в том, чтобы использовать столбец text/blob, а затем запятую - разделить пьесы, каждая запятая представляющая новую секунду (последовательно), а затем число для количества раз, которое было воспроизведено. Так что если во второй секунде 100 000 пьес во втором 1 и 90 000 играх во втором 2 и 95 000 играх, я бы сохранил их так: «100000,90000,95000, [...]» в столбце text/blob.

Является ли это возможным способом хранения таких данных? Есть ли способ лучше?

Спасибо!

Редактировать: данные отслеживаются другим источником, и мне нужно обновлять необработанные данные графика каждые 15 минут или около того. Следовательно, быстрое чтение является основной задачей.

Примечание: из-за природы этого проекта, каждый из которых играет второй, нужно будет отследить индивидуально (другими словами, я не могу просто отслеживать «начало» и «конец» каждого воспроизведения).

Answer 1

Проблема с хранилищем blob заключается в том, что вам необходимо обновить весь блокнот для всех изменений. Это не обязательно плохо. Используя ваш формат: (100000, 90000, ...), 7 * 3600 * 3 = ~ 75 Кбайт. Но это означает, что вы обновляете этот кадр размером 75 КБ для каждой игры каждую секунду.

И, конечно, blob непрозрачен для SQL, поэтому «какая вторая из того, какая песня имеет наибольшее количество игр», будет невозможным запросом на уровне SQL (это в основном сканирование таблицы всех данных, чтобы узнать, что).

И есть много разборки накладных расходов, которые собирают данные в и из них.

С другой стороны. Идентификатор подкаста (4 байта), второе смещение (2 байта без знака допускают подкачки до 18 часов), счетчик воспроизведения (4 байт) = 10 байт в секунду. Таким образом, минус любые блокирующие накладные расходы, третья песня составляет 3600 * 3 * 10 = 108 Кбайт на песню.

Если вы сохранили его как blob, vs text (block of longs), 4 * 3600 * 3 = 43K.

Итак, структура второй/строки «только» в два раза больше (в идеальном мире, обратитесь к вашему серверу БД для получения подробной информации) бинарного блоба. Учитывая дополнительные преимущества, которые дает вам возможность получать информацию о вещах, это, вероятно, стоит того.

Только нижняя сторона секунды/на строку, если вам нужно много обновлений (несколько секунд одновременно для одной песни), это много трафика UPDATE для БД, тогда как с помощью метода blob это, скорее всего, одно обновление.

Ваши шаблоны трафика повлияют на это больше всего.

Answer 2

Было бы проблематично использовать каждую секунду, и сколько игр было в секунду? Это означает 10K строк, что неплохо, и вам просто нужно ВСТАВИТЬ строку каждую секунду с текущими данными.

EDIT: Я бы сказал, что эти решения лучше, чем разделение запятыми что-то в столбце TEXT ... тем более, что получение и манипулирование данными (которые, как вы говорите, вы хотите сделать) были бы очень грязными.

Answer 3

Я бы рассмотрел его как проблему с ключом.

for each second played 

    Song[second] += 1 

end 

В реляционной базе данных -

song 
---- 
name | second | plays 

И хак псевдо-SQL, чтобы начать второй:

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

и другой для обновления второго

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

3-часовой подкаст будет иметь 11K строк.

Answer 4

Это действительно зависит от того, что генерируют данные ..

Как я понимаю, вы хотите реализовать карту с ключом является вторым знаком и значение представляет собой число игр.

Каковы части мероприятия, единицу работы или транзакцию, которую вы загружаете?

Могу ли я предположить, что у вас есть событие воспроизведения по имени подкаста, время начала и остановки И вы хотите загрузить на карту для анализа и презентации?

Если это так, вы можете иметь таблицу

• podcastId
• secondOffset
• прослушиваний

каждый бы даже сделать обновление строки между начальной и конечной позиции

обновление t set playCount = playCount +1 где podCastId = х и secondOffset между у и г

, а затем следуют вставки для добавления этих строк между началом и остановки, которые не существуют, с прослушиваний 1, если вы предварительно загрузить таблицу с нулями ,

В зависимости от БД у вас может быть возможность настроить разреженную таблицу, где пустые столбцы не хранятся, что делает их более эффективными.