我的天

每次写统计分析肯定会让我想粮价这个事情。除此以外，我对这个东西一点都不关心，但每次要写的时候我都会很为这个发愁，应该去哪里找到这些粮价呢？这一次因为我玩得比较大，我需要的是2018年7月到2023年8月的粮价。横跨那么多年，想想都觉得应该很疯狂，真的要去找的时候感觉更疯狂。粮价这种事情以前我也有找过，每一次都是临急抱佛脚，但是抱完佛脚以后，我也是有坚持过一段时间持续去人肉爬虫，但是爬了一段时间以后没有继续下去。在我还可以人肉爬的时候，那些价格大概一周出一次。对我来说一周这个频率太长了，所以过上一段时间就会忘记，而且别人出价格的时间还不那么稳定，虽然说是一周一次，但是说不准就是哪一天，可能是周一可能是周三，也可能是后补回去。被这样拖来拖去，久而久之我也就不记得了。这一次因为要找的跨度很大，我要做图的话，就没有必要把数据找那么细，大概一个月一个价格就行了，至于如果一个月变动很大，那就人肉平均一下，毕竟5年的价格下来，即便以月为单位也是个不小的数目，我需要表达的是整体趋势。

如果粮价时间跨度不是很大，只需要一年或者半年的话，一个地方大概就能把东西找齐，但现在我发现在一个地方找，根本找不全，最根本的原因是有些之前我人爬价格的地方做到某一年就不再干下去了。有些有新价格，但是最早的那个是2022年。有些有2018年的价格，但是他们干到2021年就不干了。还有一些地方比较屌丝，在网页上他们要会员注册，然后给钱成为VIP，才能看到数据。在公众号上他们展示了一些试看文章。试看文章里有我需要的数据，但问题是那个是周报，这就意味着，如果我要拿到2018年的数据我起得起码得翻到2019年头，因为通常那个微信公众号的试看文章展示的图表是一年的玉米价格曲线。显然公众号就只是吊一下你的胃口，最终他们想做的是你去他们的PC版网站注册并交会员费，于是我也就只能用最常规的方式去刷取他们微信公众号上面的历史文章。历史文章这种东西理论上是无限的，但那是一个动态加载的过程。那个历史文章的页面比较屌丝，必须要在微信的浏览器上打开，一般的浏览器无法直接打开。这就意味着实际上在打开的过程中我个人的账号给绑定了，限制了我的刷新频率。在那个历史页面，你只要点击进去了，就会直接到达那个文章，当你返回的时候又回到了一开始的那个列表。我需要加载很久很久以前的历史文章，所以我就得不断滚动、不断加载。当我好不容易到点2020年初的文章的时候，一个不小心点错了，我应该在广东玉米，结果我却点了饲料的，文章打开了，但是却不是我想要的，再次进去重新刷鼠标，却发现无论如何都再也load不出我要的列表。不仅仅是电脑端无能，手机端也被限制了，所以估计可能好长一段时间我都不能再加载到这个公众号上面的历史文章列表。如果腾讯非常狠，可能这个公众号上的历史文章列表我永远都刷不开了。所以为什么会有这么屌丝的设定呢？明明文章是有的，但是你却看不到。我明明只想要以前的文章，但是你永远都是用倒序去排列，不允许我对时间进行任何筛选，这样的话你就强迫我不得不一次又一次动态加载你的列表，加载多了你又禁止我这个行为。如果你有记录过我这个加载的意图的话，就会发现我并不是要打开你们所有的文章。我也没有复制粘贴偷龙转凤之类。这样的防止爬虫方案直接把我这种本来用途很正路的用户给挡在门外。

数据库网站很多，各种类型都有，但是很多连试看的机会都没有，我怎么知道你们有的数据就是我想要的呢？现在的竞价交易在国家平台，所以国家肯定有所有竞价交易的数据。为什么国家就不能提供一个查询渠道让大众去了解行情呢？

每当遇到收费的数据库都会让我有很强的破解欲望，虽然我知道我根本做不到。

当我终于把功能做出来以后，我却嫌弃出结果太慢了，居然要好几分钟。明明最终我想要的是一个表的合并，为了更快，我不得不拆分为两个查询。第2个查询以第1个查询的结果为基础。其实这么操作，无非我是想利用第1个查询已经得到的缓存结果。那个结果已经被我用表格输出。之前我试过从零开始弄第2个查询，结果发现实在太慢了。如果没有那么多的分组，速度还会那么慢吗？如果只是一个求和，根本无需分组，但问题是，每个批次的东西必须分开计算，然后才可以出现分段的结果。说白了，让我纠结的是一个累计求和。

累计求和这种东西的思路在PQ里通常都意味着新增一列，参数设定匹配某行的某些东西，符合条件就把某列的数据求和。所以实际上这是一个筛选的过程。如果数据很多，筛选肯定会很慢，但除了这样，还能有什么方法吗？据说可以用索引的方法。据说索引的方法比筛选的方法快非常多。如果用python的思路去考虑，我觉得筛选是一个列表的操作，而另外一个是字典的操作。如果不用二分法。历遍列表是非常慢的，但如果要立片字典，历遍是轻而易举的事，而且字典的效率比二分法还要高。所以我应该如何建立索引呢？如果筛选的是多条件，索引大法还能继续管用吗？我觉得现在我遇到的问题那些经常接触数据库的人估计已经纠结过了。这不仅仅是Power Query的问题，这是如何运用数据进行弯曲折叠的问题。只要是数据库，无论是SQL还是其他形式，都会有这种烦恼。

昨天我终于经历了一个Excel要跑好几分钟甚至十几分钟才能出结果的东西，我感觉那没多少数据。我曾经试过把那些东西输出，结果发现输出速度非常慢，每秒钟只处理了不到100个。那些数据粗略计算了一下，可能有超过2万条。为什么加载2万条数据会这么慢呢？这是一个令我纠结的结果，如果把最后的分组都做了，输出的数据只有365条，但如果不做最后的分组，有超过2万条。不做分组的话，那个结果可以在软件里直接展示出来，顶多只需要几秒的运算时间，但是不做分组，把数据输出却有超过2万条，即便我不输出表格只输出数据透视表，依然在输出的时候速度非常慢。为什么对2万条数据进行分组会这么慢呢？除了分组，还有其他快速的方式可以对某条件进行求和吗？整个操作之所以这么慢，除了因为分组，还有排序，还有一些，null转化为0，或者把0转化为null的操作，最后，还有一条我自己都觉得应该会很作死的向下填充。那个结果我花了好几分钟才计算出来，如果让高手去解答，估计运行时间会会是毫秒级的，顶多不会超过三秒钟。

一方面，我很想知道如何提升运行速度，直接拿去问人显然是最显而易见的办法，但在这之前，我想自己先思考一下，毕竟走到这一步已经很不容易，我不想在最后一步认输。这让我想起了高中数学老师的某句经典语录，学习数学几个境界里的最后一句——全而不好（前几句是“不懂不会，会而不对，对而不全”）。

昨天我终于用python写出了把点点转化为WordPress的脚本。这个东西我确信是可行的，因为python的转换过程中没有出错，这就证明没有遇到奇怪的事情。用别人脚本的时候，把转换好的文件上传到WordPress，我总会担心不成功，但我自己写的脚本，我知道该注意些什么，哪些参数是现在的WordPress必须要求有的，所以只要python的转换不出错，我的WordPress导入就不会有问题。因为点点的文章有9000多篇，要从后台管理界面导入到WordPress，会非常耗时间。如果一篇文章需要两秒，完全导入就需要5个多小时，所以我没有做这种事。我挑选出22篇，各个类型都有的，试验导入，结果非常成功，网页的效果也很好，完全按照我的意思生成了。我觉得如果要快速解决问题，估计我得在数据库端导入。之前把文章导入到WordPress，因为要尝试不同的版本，我得不断地导入删除，但删除的文章太多的时候，速度很慢。后来我暴力地在数据库那里直接写删除语句，结果秒杀就完成了。现在我发现了一个更干净的方法。直接把关联WordPress的数据库里的内容全部删掉，这也是一个秒杀的过程，而且绝对不会留下任何的手尾，比如文章删除了，但是分类和标签仍然在那里。可能某些东西已经不存在了，但是计数还停留在一个很大数值，之所以这样，肯定是因为我删除文章的时候不够艺术。与其让里面留那么多乱七八糟的东西，还不如直接把数据库清空。因为我这是单机上的WordPress，我纯粹只是用来测试。这样的删除是最快捷的。大概我从上周，才突然领悟出可以这样。别人之所以要在数据库里写语句删除文章或者标签，是因为不能删掉一些不应该删掉的东西，但我没有这个顾虑。既然在数据库层面可以快速的删除，那么理论上也应该可以从数据库层面快速的导入。之所以有这个想法，是因为我发现WordPress的插件有些是针对数据库的，有些是针对WordPress自带函数的，数据库层面的查询要自带函数快非常多。现在我已经学会了转换适配后台界面导入的文件格式转换。下一步大概我得学习一下如何在数据库层面进行导入。这么高端的做法，貌似之前我还没有听说过。在网站迁移的时候，的确是把数据库打包，然后重新放到别的地方的，但那个数据库是本来就已经存在的。从一个地方挪到另外一个地方，原封不动地，但是我却要把大量的数据以快速的方式导入到数据库，并且还得按照WordPress的脾性建立各种关联，显然这貌是非常不简单，但理论上应该可以做到。

我不知道我的python到底学成怎样了，但起码我可以用那个东西实现我自己的愿望。相比于书本的习题，我觉得实现自己的愿望更有成就感，虽然其中有很多问题完全只能靠自己，没有参考答案。虽然总的来说，脚本不是我一个人写的，我是站在巨人的肩膀上修改而成，但BlogBus和点点的结构还是有差异的。最幸运的是某些我不知道该用什么手段实现的东西前人已经给我指明了方向。昨天我只是把脚本写出来了，接下来我要把脚本优化，一些老是翻来覆去说的句子完全可以把那作为自定义函数。到底什么东西应该泛化，应该泛化到什么程度，这个我还没有想好。昨天之所以可以这么迅速地完成任务，大概是因为在我开始之前先做了个思维导图，明确了我到底要做些什么。基础数据有哪些，应该在哪里取数，需要判断的参数有哪些，各自的参数有什么特性，能不能合并同类项。之前我就写过类似的东西，但是跟思维导图比起来，之前我写的那个真的很水。有思维导图、有专业的思维导图软件，人的思路可以非常快地展开。整体定下来，下面的事情就只剩下一步一步地实现。我做梦也没想到，自己这次居然这么高效。某些我没有把握能快速解决好的问题，昨天不知道为什么很多都迎刃而解了。转换一个30多MB的XML文件，我用了16秒。转换出来的文件大小为22MB。我觉得应该可以更快，但怎么才能更快呢？文件里的数据结构是我没有考虑过的，我是不是应该从那里入手？一些相同的判断，大概我应该做一些合并。

追求更好是没有尽头的。

连题目都看不懂到底要做什么，解答那道题当然是无从说起，但是我还是硬着头皮去做了。用我理解的那个方式去做。本来我没有打算看参考答案，我是去看另一道题的参考答案的，参考答案没看懂，顺便把上一题的参考答案下载回来，结果发现，那个我看不懂的单词的确是个人家觉得你应该知道，但实际上我毫不知情的东西。shelf中文翻译很好理解，就是柜子嘛，但是柜子是干嘛的呢？这到底纯粹是某个单词，某个函数，某个字典，还是什么东西呢？当我看到参考答案的文件的命名后，我有点明白了，那个估计是一个数据库。我直接拿着那个单词去问我的网友，他也没反应过来，这到底是什么东西？他没学过python，他学过其他编程语言。这就证明了，其它编程语言里是没有这个东西的。写Think Python这本书的人默认我们都知道shelf是什么。在那个单词出现之前，那一章书里没有出现过那个东西，我看的那章书是第14章，前面13章也半个字没有提及这个单词到底意味着什么。情况就好像，你在没有学过python的人面前说元组，人家完全不知道你在说什么。之前的习题，如果遇到这种情况，写书的会在题目后面提醒那是个什么东西，读者可以自己从某个链接那里了解这个玩意，但这道题他们半个字都没有提醒，所以我真的很怀疑翻译Think Python这本书的中国人到底有没有看懂这个单词。如果他们看懂了，至少他们应该提醒一下读者，这实际上是要他们把字典里的映射放到数据库里面，而那个数据库又不是真的传统意义上的数据库。要解释这种东西，的确用三言两语无法说清。即便我已经看过中文版Python手册里面介绍shelf的部分，但我觉得自己还是没搞懂到底那是什么。

按照参考答案的写法，我在自己的程序里先加入了一个建立数据库的语句，然后再增加shelf的处理。我不知道到底是怎么回事，因为终端里光标就一直停在那个地方，好像卡机一样，当我关掉软件以后，脚本的文件夹里面多了一些数据库文件。我不知道那到底是什么，但显然里面有很多东西。其中一个dir文件，有100多KB，而另外一个数据库的缓存文件，接近30MB，我不知道哪来那么多的内容。大概我应该把后缀改一改，然后用Access打开看一下里面到底有些什么神奇的玩意。因为这个数据库很大，所以我在终端里就看到光标卡在那里。为什么python里的字典秒杀就能显示完毕的东西建立数据库居然这么庞大呢？可想而知，在字典里可以秒杀完成的搜索，如果放在数据库里反应时间估计是万倍的区别。这让我想起Excel的VBA里，如果读写的是单元格，那么脚本将非常耗时，但如果把读写的内容先存在数组里面，完成以后一并输出，效率会高非常多，随便高个几百倍算很少了。

高中的时候，我学过Access，但只是老师说什么我就做什么，我只知道一些非常皮毛的东西。Access的精髓是数据库，数据库的灵魂是查询语句，但那时的学习我们只停留在可视化表格操作。

无论精通了哪一门编程语言，所有事情都能用那个方法搞定。有些人学习是为了赚更多的钱，而我努力学习只是因为我想知道、我想实现。

昨天blog终于恢复了。在域名那里重新绑定服务器以后，一切终于恢复正常。从6月3号起发现上不了，到6月13号终于恢复整整10天时间，我落下了非常多的东西。虽然中间的那些东西我都有记录，所以只要耐心一点，我都可以补上，但显然一次性补17篇东西也是非常痛苦的一件事。经历过这一次以后，我有了自己在电脑上也保留一份存档的念头。是否有什么软件可以充当简单的数据库，实现blog的效果呢？对我来说，我并不需要界面漂亮，最重要的是记录下文字本身，需要的时候能足够快到达。需要记录的关键信息无非是文章标题、文章正文、记录的时间，文章的分类，以及关键词。

我可以通过标题、时间、正文或者关键词进行搜索，而文章的分类列表允许我把所有那个目录上的文章以某种排序方式展示出来。理论上说，WordPress的数据库结构大概也就这个样子。对我自己个人来说，界面不重要，所以等于无需进行前台版面的设计。要用什么东西实现这个功能呢？在正文里，我需要进行一些格式的设置，通常来说纯文本就足够了，但是某些词句如果能用到加粗和加入超连接会更好。这个东西也必须得默认可以插入图片和视频，图片是内部引用，视频其实就是一个超链接，但是可以在正文展示播放。

我不知道我的这个构想是不是实际上就是一个WordPress的后台结构。这其中没有非常严密的逻辑关系，用不到计算。Office的Wordd能实现格式的功能，而且我觉得格式个功能过于丰富了。Office有他们的数据库软件Access可以实现任何我想到想不到的数据存储及查询，但问题是即便我把数据存储进去，我查询正文出来的东西可能只是代码本身，而不能把某些代码转化为可见的格式。

在我WordPres的后台管理界面，有数据导出功能，但到现在为止，在这个我用了9年多的系统里，我还没试过做数据导出。这让人有点心惊肉跳，因为从2004年高考结束以后，加上在BlogBus的数据，我已经有15年的东西了。我已经不记得从BlogBus搬出来的时候我带着多少数据走人，也不知道在过去投奔WordPress的这几年我又积累了多少。可以预知的是即便全部都是脚本和文字，也一定内容相当丰富。如果导出的只是文字，而且又经过压缩，我估计数据的大小应该不会超过100MB。我不知道，如果我用导出功能会有什么后果。因为理论上，数据库的某个存储单元是有大小限制的，比如我的blog，附件大小最多2MB，所以如果那个导出的数据是一个超过50MB的东西，导出的时候会有什么后果呢？

前几年当Dropbox还能在中国不爬梯子使用的时候，我的网友每天都会把数据库备份，然后自动同步到我的Dropbox账号，但不知道从什么时候开始，已经不这么干了。我的房东是一个IT人士，所以他肯定知道数据备份的重要性，即便他不把那个同步到我的Dropbox，肯定他自己也会同步到某个地方。我不担心在他的管理下，我的东西会有什么问题，而且即便某天真的出状况了，其实每天blog的正文我都是有保存的，缺失的只是每天我发布上去时才写的分类、关键词以及网友的评论。

我总觉得应该有软件又或者有几个软件的联合体能实现我想要的功能。如果真的没有，或许以后某天我会自己整一个。