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

Question

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

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

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

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

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

Спасибо!

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

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

Answer 1

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

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

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

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

Если вы сохранили ее как блоб, против текста (блок длинных), 4 *3600* 3 =43K.

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

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

Ваши шаблоны трафика будут влиять на это больше, чем что-либо.

Answer 2

Я бы рассматривал это как проблему значения ключа.

for each second played

   Song[second] += 1

end

В качестве реляционной базы данных -

song
----
name | second | plays

И взломать psuedo-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 3

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

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

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

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

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

• podcastId
• secondOffset
• playCount

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

update t set playCount = playCount +1, где podCastId = x и secondOffset между y и z

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

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

Answer 4

Было бы проблематично использовать каждую секунду, и сколько пьес в секунду? Это означает 10K строк, что неплохо, и вам просто нужно вставлять строку каждую секунду с текущими данными.

РЕДАКТИРОВАТЬ: Я бы сказал, что решения лучше, чем делать что-то через запятую в столбце TEXT ... особенно потому, что получение и манипулирование данными (что вы говорите, вы хотите сделать) было бы очень грязно.