最近几年，所谓的“社工库”一词在网上被炒的火热，这主要得益于几大网站数据库的流出，依稀记得最初是CSDN的那一批，从那以后，所谓的社工库就被拿到台面上来了，在那之前，确实有个别人用到处收集来的数据库自建查询，但规模远远不够，而且基本没有对外开放。自从那次之后，网上出现了很多对外开放的“社工库”网站，比如当初最典型的365。不过，一直到目前为止，所有网上的，所谓的“社工库”所包含的内容，无非就是用户名和密码信息，或许还有个邮箱。这些东西可能对于我们来说远远不够，这只是收录了大量的用户名和密码，然而却忽略的大量的更重要的信息，比如生日，比如学历，喜好，身份证号码，曾（现）就读的学校，长相，社会背景，家庭关系等等等等，太多的东西。
author：adwin
from：Silic http://silic.org
所以习科的某位大神（你猜是谁？）就提出要建立一个信息检索系统，不光包含密码，要包含我们上边说到的社会背景家庭关系等所有能找到的个人信息。所以第一个问题就来了：数据从哪来？这是最根本也是最重要的问题，同时也是最难探讨的问题，这事说深了不行，说浅了没用，所以干脆就不说了吧。
即使我们把数据从哪来这个问题跳过去，那么很快又可以发现第二个问题，就是数据如何存储的问题。网上所谓的社工库其实很简单，因为包含的信息量很小，只有用户名密码和邮箱，所以只要按照这样的格式放入数据库就好了，由数据库来进行检索，这个实现起来很简单，检索起来也比较容易，就算数据量稍大一些的话，通过对数据库的一些优化也就完全可以解决检索速度的问题。但是我们所讨论的这个理想中的系统可能就不太一样了（显然我们还没给这套系统起一个名字，要不就暂时先叫做身份信息检索系统？），我们的系统包括了社会背景以及家庭信息在内的大量信息，如果你有仔细想过刚才的第一个问题的话，显然这里你会发现，我们不是政府部门，没有权利查户籍系统，所以数据的来源不言而喻，你知我知，只是，这海量的数据是都拼西凑起来的，数据的格式肯定大相径庭，可能其中有些数据包含了社会背景，而有些数据包含了家庭信息，如果要把这样的完全不规则的数据放入数据库中，首先对于数据的格式化这一个问题来说，就是基本不可能实现的——无论从时间成本或者是空间成本考虑。这样既然不能使用数据库，当然也就失去了数据库的最大优势——快速检索，个人认为，数据库的快速检索显然是建立在格式化的数据基础之上，也就是说，对于我们现在如此不规则的数据，数据库已经完全失去了他的优势。
说到这里，我想不得不应该提一下NoSQL，因为刚刚说到几乎不可能完成的一件事——数据的结构化，其实关于NoSQL我并不是很了解，所以不敢妄下结论，不过NoSQL也不可能直接游走在不同结构的csv、txt、sql、xls等等不同格式的文件之间吧！
除了xls，其他的文件格式如csv、txt、sql等，基本大多数文件格式都是基于文本的，而且这些原始的数据文件包含的信息并不止里面的那些数据，还有一些其他的隐含信息，一旦对原数据文件进行结构化处理，那么这些隐含信息必然会丢失。所以可能目前来看最合适的方式就是基于文本来进行检索了。失去了数据库的结构化，基于文本的检索速率必然要下降不止一个档次，从而也就出现了第三个问题，就是检索速度的问题。那么什么样的时间成本是我们所能接受的呢？这不是一个定数，具体要看应用场景，如果这个系统只有我一个人用的话，可能十天半个月都用不上一次，写个程序叫他自己去跑就可以了，时间上完全可以接受。但如果想要基于WEB开放，那就麻烦了，任何一个人对网页加载时间的耐心都是有限的，更何况你还很可能会受到脚本超时时间的限制。那么最简单的解决这个问题的方法就是使硬盘的读写性能增强，如何增强？上SSD吧！SSD的读取速度按平均500M/S粗略计算，读取1G的数据大概需要2s，那么读取1T的数据就大概需要2000s，2T的数据就要一个多小时（虽然我们不一定有那么多数据，但这只是说明这个速度还是不太能接受）！如此一来，看来只能是将数据拓展到多块硬盘了（这意味着金钱成本增加，而且你还需要不是太逊色的CPU）。
目前为止，我们已经探讨了几个可能遇到的难题，按照我个人的观点来看，最终，最主要的问题，还是集中的I/O性能上，在我看来这里可能是一个瓶颈，要想突破这个瓶颈，大概有两个方向，第一就是对文本数据建立良好的索引，尽量减少I/O；第二就简单了，烧钱就行。
以上是关于习科那位大神提出的想法，我个人的一点见解，如果哪位大神有独到的见解或者想法，欢迎提出。