Я создаю мобильное приложение, которое отслеживает и воспроизводит количество времени, которое пользователи проводят за прослушиванием аудиоконтента приложения.
У меня есть вопрос о выборе правильной архитектуры базы данных для управления отслеживанием использования контента.
Требования
- Точное отслеживание времени воспроизведения звука с точностью до секунды
- Измерение времени прослушивания по сравнению с ежедневными пороговыми значениями (например, 15 минут общего прослушиваниявремя в день) и записывайте общее время, проведенное каждый день
- Ориентация на местный часовой пояс пользователя - В любой данный день отслеживайте время использования в местном часовом поясе
- Учитывайте изменения часового пояса.Если у пользователя есть 10-дневная «полоса» прослушивания X мин в день во временном поясе GMT, но он путешествует в часовой пояс PST США, сдвиг в эффективном «полуночном» времени может означать, что некоторые дни PST в прошлом больше не имеютХ мин записи.Я не хочу, чтобы полоса была потеряна или аннулирована, когда это произойдет
Я пытаюсь сделать это надежным и эффективным способом.
Первоначальное решение
Сначала я хотел отследить использование на детальном уровне внутри клиента.Каждые [10] минут клиент 1) просматривает свой внутренний журнал событий воспроизведения аудио, 2) идентифицирует, какие события использования во внутренней памяти не подтверждены на сервере, 3) запрашивает у сервера любые зарегистрированные события использования для пользователя в пределахтаймфрейм неподтвержденных событий, 4) определяет, какие фрагменты времени воспроизведения являются новыми, и, если есть какие-либо новые фрагменты, 5) загружает их в таблицу серверов raw_usage.
Затем в верхней части каждого часа сервер извлекает часовой пояс из последнего сеанса каждого пользователя, определяет, завершился ли день, и, если это так, извлекает все события использования для пользователя за последние 24 часа изаписывает их в таблицу historical-usage.
Подход совсем не выглядит элегантно , но я не уверен, как лучше справиться с возможностью изменения часовых поясов и пользователей, работающихприложение на нескольких устройствах в один день.Существует ли устоявшееся решение, которое более эффективно выполняет вышеуказанные требования?
Таблица raw-use
+-----+---------+------------+------------+----------+
| id | user_id | start_time | stop_time | duration |
+-----+---------+------------+------------+----------+
| 1 | 100364 | 1537811494 | 1537815163 | 3710 |
| 2 | 101721 | 1537798878 | 1537799854 | 976 |
| ... | ... | ... | ... | ... |
+-----+---------+------------+------------+----------+
Таблица исторического использования
+---------+-----------+----------+----------+
| user_id | date | duration | timezone |
+---------+-----------+----------+----------+
| 100457 | 2018-9-23 | 3701 | UTC−08 |
| 101892 | 2018-9-23 | 975 | UTC−05 |
| ... | ... | ... | ... |
+---------+-----------+----------+----------+