Question

我正在构建一个移动应用程序，该应用程序可以跟踪和游戏化用户花费在收听应用程序音频内容上的时间。

我对选择合适的数据库体系结构来管理内容使用情况跟踪有疑问。

要求

准确跟踪音频播放时间到第二秒
根据每日阈值（例如每天15分钟的总收听时间）衡量收听时间，并记录每天花费的总时间
面向用户的本地时区-在任何一天，跟踪本地时区内的使用时间
适应时区的更改。如果用户在格林尼治标准时间（GMT）时区每天有10天的“连贯”聆听X分钟，但他们前往美国太平洋标准时间（PST）时区，更改有效的“午夜”时间可能意味着过去的某些PST天不再有X分钟的记录。一世不想这种情况消失或消失

我正在尝试以一种强大而有效的方式来实现这一目标。

初始解决方案

我最初的想法是在客户内部详细跟踪使用情况。每[10]分钟，客户端1）查看其音频播放事件的内部日志，2）识别服务器上未确认内部存储器中的哪些使用事件，3）向服务器查询服务器中用户的任何已记录使用情况未确认事件的时间范围； 4）识别哪些时间段是新的播放时间；如果有任何新的时间段，则5）将这些时间上传到服务器表raw_usage。

然后在每小时的顶部，服务器从每个用户的上一个会话中拉出时区，确定一天是否已完成，如果是，则拉出该用户在过去24小时内的所有使用情况事件并将其写入historical-usage表。

该方法一点都不优雅，但是我不确定如何更好地处理更改时区以及用户在一天内跨多个设备运行应用程序的可能性。是否有既定的解决方案可以更有效地满足上述要求？

表原始用途

+-----+---------+------------+------------+----------+
| 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   |
|     ... | ...       |      ... | ...      |
+---------+-----------+----------+----------+

数据架构-跟踪移动应用上播放的音频的使用情况

0 个答案: