第445章 最初，他们只是不信他是秦始皇

第445章 最初，他们只是不信他是秦始皇

看到这个数据大家的第一个想法就是————

这特么是bug了吧。

看到这个数字，几乎所有的程式设计师们，dna都动了。

小学生们最敏感的数字可能是100，因为这是他们能够达到的上限。

而2147483647可能就是码农们最敏感的数字，至少是之一。

一般出现这个数字的时候，並不代表著就真的是这个数字，而是结果超纲了，只能显示这个数字。

当然了，更敏感的数据可能是—32768之类的，那就是溢出了，这个结果会更糟糕————

现在並不代表事情不糟糕，只是网站做了防溢出处理，看起来没那么糟糕而已。

毕竟，什么样的技术，能够直接把整个测试体系干穿？

这是不可能的。

可是，这个是平子大佬的比赛结果啊。

万一平子大佬真的把比赛干穿了呢？

等等，正因为是平子大佬，所以才更加不可能吧？

毕竟，世界上有两个真理：

一、世界上没有绝对的真理。

二、平子大佬不懂算法。

所以，到底是不是出了问题？

大家其实也不知道自己的內心到底期待著什么，但还是决定把这件事情的判定交给比赛的主办方。

於是，网站的后台，此时已经收到了雪一般的网友提供的错误报告，告诉他们网站出错了，让他们赶快处理一下。

说实话，作为一个主打搞笑和抽象的编程大赛的主办方，这个主要由l站的高级会员组成的主席团，都是业余时间在做这件事情。

他们都是激进的技术主义者，並不怎么害怕出现什么问题，反而更注重效率。

这种思路和官方的比赛是完全相反的。

所以，这个这个天榜晋升系统其实也是自动的，只要积分够了之后，就会自动晋升，而不需要任何一个关键决策者的允许之类的。

反正，对这种搞笑和抽象的比赛来说，就算是出现问题，也只是乐子中的插曲，只要及时纠正就好了，相比之下，即时反应变化才是更重要的。

这也是这个竞赛系统被开发出来的初衷。

换句话说，在参赛者们拼尽全力叠代自己的资料库查询方案的时候，其实这个主办方的网站，也在一刻不停的叠代和维护，以应对越来越多的访问者以及越来越多的代码量，不断优化测试方式和时间，不断减少资源压力，以及不断以更快的速度反映变化，让大家能够第一时间感知到自己努力的结果。

至於结果会不会出错，只要不是大问题就无所谓，毕竟也不会有人来追责他们，对吧。

陈雁行就是主办方的主要成员之一，作为l站的联合创始人和技术顾问之一，他也是这次比赛的最大技术支持与伺服器赞助商。

因为这场比赛涉及到了唐一平，而自己作为【0t1p】大佬唐师傅的同辈人以及亲密战友，或者说作为一个“长辈”，参与进去终归是不好。

毕竟这是在代写作业—一不管这事儿演变成了什么，最初也是为了代写作业。

这种动机，就是不好的，自己作为长辈，不能鼓励这种事情。

至少陈雁行是这么觉得的。

他骨子里还是一个比较传统的男人来著。

所以他只是在背后暗戳戳的推动了这场比赛的大型化和规模化，以及贡献了这个网站的大部分代码而已。

什么坏事儿也没做。

就是————看乐子。

乐子人怎么能算是坏人呢？是吧。

所以，在看到了雪一般的报错的时候，作为可能是最强的独立网安专家之一的陈雁行，看到报错的第一个想法就是不可能。

因为网站的代码是他写的，测试程序和方案也是他出的，就连测试集都是他弄来的真实测试集—一他不可能出这么大的差错。

他又不是一个初出茅庐的菜鸟，他可能会犯错误，但是绝对不会在这种简单的问题上犯错误。

但如果自己不可能出错，那他就要面对第二个不可能。

这个测试结果是对的？

这更不可能吧！

毕竟那可是平子大佬，不会算法的平子大佬！

平子大佬写出来fork—cane这种项目一点也不奇怪，毕竟平子大佬本身就是工程暴力美学的奇蹟代言人。

但是算法？

我寧愿相信门口摆摊卖饭的大叔是秦始皇。

这么想著，陈雁行打开了网站后台的日誌，调出了平子大佬的测试日誌。

作为网安专家，陈雁行的“看日誌”是一门绝活。

速度快到夸张。

只是扫了一眼，他就发现，没问题。

至少是日誌绝对显现不出来的问题。

没办法了，他只能再自己手动跑一遍测试了。

调出唐一平提交的代码，导入了由他提供的那个数据量为50万的学生档案测试集。

这是一个巨大的csv文档，整体大小大概500m。

陈雁行自己估算过，如果把这些文本文档，转成资料库的格式，理论数据量应该是50m左右。

这是其有效熵值转换成的比特数，也就是这个测试集本身蕴含的信息的比特数。

但是这种单纯的数据是不能使用和检索的，所以才会有“资料库”这种东西，把信息编码索引，安排好位置。

换言之，单纯的信息就像是无数的人，资料库就是盖上一栋大楼，把他们放进各自的房间。

这就要在本身的数据基础上，加上b—tree或者其他tree的索引、哈希表等等，就像是楼梯楼层和门牌號。

通常来说，这些数据转换成资料库格式之后，整体数据量大概在200m—300m。

这大概就是地榜排名前几的水平，其实能做到这个数量级就已经很强了。

但但如果是天榜的话，目前已经强到离谱了。

譬如现在焦灼在天榜前列的两个id：“递归之梦”和“等待戈多”，已经把这个数据压缩到了130m左右。

在这个数据集上，已经可以和商用资料库相媲美，甚至在某些方面犹有过之了，当然，也不同程度的呈现出了过擬合，算是针对性优化。

陈雁行把自己的数据集导入了唐一平的项目里。

导入的速度很快，而且cpu占用率很高，几乎是瞬间拉满，然后导入完成。

陈雁行再次跑了一遍测试流程。

测试结果一行行的输出，和陈雁行在日誌里面看到的一模一样，片刻之后，一模一样的分数出现。

2147483647。

这不对啊，这不可能。

莫非他真的是秦始皇？

作为一个网络安全的大佬，其实陈雁行首先就是个测试方面的专家，他设计的测试用例和测试程序非常完善。

还是那句话。

可能出错，但不可能出现这种低级错误。

陈雁行拉出来了测试细分项，就看到了测试的平均响应时间。

0ms（毫秒）？

果然出错了吧。

正常来说，这种体量的资料库的简单查询应该在几十毫秒。

等等，莫非是查询速度快到了四捨五入之后都是0？

直接低了一到两个数量级。

这会儿，陈雁行其实遇到了和奎哥一样的问题。

位数不够，显示不全的问题。

可是，谁特么的资料库测试响应时间，需要用到比毫秒还小的单位啊！

陈雁行一边吐槽著，一边打开了自己的测试程序，修改了一下代码，把统计单位变成了us（微秒）。

然后又跑了一遍测试。

这次结果终於显示正常了。

不，陈雁行觉得这次更不正常了。

因为测试最终的结果显示为23us。

合著，不是零点几毫秒，是零点零二毫秒！

特么的，这可不是四捨五入到0了吗？

自己之前的测试集能够显示出来才怪！

再特么的，系统的测试噪声都快要10us了好吗！

读数据的延迟都要10us了好吗？

你咋不飞呢？

这怎么可能？

这个查询结果有问题吧。

真的有问题吧。