【建议】每小时更新DXYArea-TimeSeries文件方式优化

[biluochun]

• 每小时都有新数据更新，是否考虑新增数据用新增文件的方式；
• 目前这种更新单个文件的方式，浪费了旧数据可缓存的功能；
• 每小时新增的数据用固定的命名规则，以新增文件的方式有没可行性？
• 目前json 文件已经60M+了。

[BlankerL]

你好，感谢反馈。

• 如果使用新增文件的方式，对于有时间序列数据需求的人来说，又需要自己合并所有的文件才能获得完整的时间序列数据。如果使用新增文件的方式，仅DXYArea每天就会新增24个文件。

• 我不太确定我对你所说的旧数据可缓存的功能的理解是否正确。如果我的理解正确的话，你是希望回溯以前的DXYArea-TimeSeries文件。
  GitHub其实会保存所有的历史数据，如果对历史数据有需求，可以参考此处，截止e42efcd，已经有1583次数据更新，所有的历史状态都能在此处获取。或许是你对Git的使用不太了解，所以才希望通过新增文件来解决对历史数据的回溯问题。

• 每小时新增数据用固定命名规则，本质上来说和此处自动更新时的备注内容，诸如2020-04-09 14:25:31.711715 - Change detected!类似，完全有可行性，但是如果你的需求是我上面说的那种，个人认为或许没有这个必要。

• 中国大陆访问GitHub速度有限，所以下载json文件速度较慢，我完全可以理解。目前可以考虑以下几种解决方案：

  1. 如果你希望通过前端展示数据，尽量在你的后端缓存这份数据，并且自己做一个简单的数据处理，来减小json文件，比如做日频感染的可视化，则每天的数据只需要保留一条。如果有需要，可以参考清华大学计算机系数据库实验室团队的可视化项目，他们就是通过这个方法减少向前端传输的数据量；

  2. 如果只是希望将数据下载并且保存到本地，希望加速下载，网上有很多GitHub文件的CDN节点，比如GitCDN，在中国大陆的访问速度还不错；

  3. 可以通过修改GitHub的DNS解析IP（修改hosts文件）或者通过海外服务器加速下载。

如果我的理解有错误，可以在下方具体说一下你的需求。另外，每个人的需求都不完全一致，很难同时满足所有人的需求，我只能尽可能提供完整和开箱即用的数据，希望能够理解。

[biluochun]

• 首先很感谢这么认真的回答

• 我整理下我的思路：

  • 数据是增量式的，所以认为数据以增量的形式更为恰当
  • 我的建议是将现有的1个数组 分成 多个数组存储。
  • 修改数据存储方式，由单文件改为多文件，只是修改了数据源的获取方式，应该跟具体需求没关系（可能是我未接触过时间序列数据需求 ^_^）；
  • 若按小时存储，每日新增24个文件过多，可以修改为按其他维度（按天/月）；

• 我认为的好处是：

  • 节约流量：当天获取当天的文件即可，约1M左右。不需要每次获取近70M的文件（gzip后，目前是5M，也蛮大的）
  • 按需获取数据源，比如只需要分析3月份的数据，目前需要获取到全量数据，然后过滤无用数据。

当然这种存储方式的改变，会直接导致使用者更新使用逻辑，这是个弊端。可能是个大版本升级。
再次感谢，这么认真的答复；

[biluochun]

附上我的数据展示
增量的形式，更有优化空间 ^_^ （老了，老打错别字。。。）

[BlankerL]

感谢，随着爬虫持续运行，TimeSeries文件肯定会一直增大，而且未来会到多少也不好说。

如果有需要，我可以拆分成多个文件储存到数据仓库中，但如果是科研需求，应该对数据更新频率的要求很低，只需要下载一次json文件就足够他们所有的分析了。如果是用做前端展示，每个人对单个文件数据的更新频率的要求可能也不太相同。拆分成增量数据可能一定程度上可以减少每次下载数据的数据传输量（毕竟只有最后一天/月的数据在更新），我或许可以把历史数据放到release里供大家下载。

有一个比较尴尬的问题，就是历史数据可能有一小部分是有异常值的，目前也在 BlankerL/DXY-COVID-19-Crawler#34 收集异常值反馈，所以当异常值修正之后，又要重新发布release或者对过去的release文件进行修改，整体效率比单个TimeSeries文件低了不少。

我可以看看GitHub的API，关于自动发布release和修改历史release文件的部分，如果找到一个比较好的解决方案，会考虑按您的建议来处理的。

数据展示已经添加到了 BlankerL/DXY-COVID-19-Crawler 的README文件中。

[Dobby233Liu]

我或许可以把历史数据放到release里供大家下载。

But GitHub uses a S3 bucket to host the release assets, and the S3's download speed is very slow and breaks often in Mainland China (thanks to the MIIT's "great firewall"), unless you're on a proxy. Plus the TimeSeries JSON size is over 60MB as stated in the OP, so it's going to pain mainland researchers.

---

我可以看看GitHub的API，关于自动发布release和修改历史release文件的部分，如果找到一个比较好的解决方案，会考虑按您的建议来处理的。

but if you're still looking for the APIs, then I got some quick references:

• Pro Git -> Git Basics -> Tagging (zh: Git 基础 -> 打标签), git tag --help (publishing a release can add a tag to the repository)
• Releases API in GitHub REST API v3
• PyGitHub's releases API interface/object: GitRelease; GitReleaseAsset

[kmod-midori]

我个人认为完全可以只上传进行gzip后的时间序列数据，因为git本身是完整保存每个版本的，而不是保存diff，也就是说每次更新都需要上传/下载整个文件。
现在的文件大小已经超过GitHub可以正常diff的范围了。

[BlankerL]

我个人认为完全可以只上传进行gzip后的时间序列数据，因为git本身是完整保存每个版本的，而不是保存diff，也就是说每次更新都需要上传/下载整个文件。
现在的文件大小已经超过GitHub可以正常diff的范围了。

感谢建议，目前没有足够的时间来维护代码，git的数据也能正常更新，因此没有进行额外的操作。

由于我是GitHub的Pro账户，git仓库的容量应该有100GB，所以暂时没有达到瓶颈。如果需要clone，可以选择使用--depth 1参数防止将所有commit都下载下来。