这是一个创建于 4704 天前的主题，其中的信息可能已经有所发展或是发生改变。
密码泄漏搜索工具，用于在5个已泄漏的数据库里综合搜索数据。
目前已经支持的5个数据库：CSDN, 7k7k, 人人, 嘟嘟牛, 多玩。虽然网上能下到猫扑的数据，但是实际压缩包是损坏的，所以在这里就先不支持了。
关键字长度要超过6位，同时只接受字母，数字以及点(.)，下划线(_)，AT(@)。
此工具仅提供7天，7天后关闭提交。如果还有未完成的搜索则等待搜索完成后彻底关闭。
http://vsean.net/blog/post/98
目前已经支持的5个数据库：CSDN, 7k7k, 人人, 嘟嘟牛, 多玩。虽然网上能下到猫扑的数据，但是实际压缩包是损坏的，所以在这里就先不支持了。
关键字长度要超过6位，同时只接受字母，数字以及点(.)，下划线(_)，AT(@)。
此工具仅提供7天，7天后关闭提交。如果还有未完成的搜索则等待搜索完成后彻底关闭。
http://vsean.net/blog/post/98
 |
1
evlos 2011-12-23 02:59:05 +08:00
。。。关键字要6位 。。。。我账号才5位。。。。
|
 |
3
vibbow OP 补充说明：不知道由于什么原因，我自己测试往QQ邮箱发信收不到，因此大家尽量用国外的邮箱收信吧。
|
|
4
vibbow OP 我了个去，发现一个严峻的问题：现在性能瓶颈居然不是硬盘，而是CPU...
|
|
5
vibbow OP 因为修改代码时失误，导致给8位用户（应该都是v2ex的吧）发送了一封垃圾邮件，在此表示抱歉。
|
 |
6
carry 2011-12-23 10:16:16 +08:00
大恩不言谢 创意主很精通搜索吗
|
|
7
vibbow OP @carry 完全不精通搜索，服务端都是用PHP写的，先全部转小写然后用strstr比较... 要不然效率也不至于这么低了...
|
|
8
vibbow OP 哈，用Process Explorer看了下服务器的运行状况，硬盘今天爽high了～
|
|
9
vibbow OP |
 |
10
delectate 2011-12-23 18:43:38 +08:00
win的服务器？这么大的数据库，还是grep等给力，既支持正则，速度又快。
|
|
12
vibbow OP 擦...服务器开始自动备份了...速度瞬间降低...
|
|
13
vibbow OP 怎么优化都是4分钟，应该是到strstr函数的极限了...
|
|
14
delectate 2011-12-23 19:47:31 +08:00
瓶颈。想想顺序读取1g的数据还要很久时间呢。
|
|
16
delectate 2011-12-23 20:09:19 +08:00
只是那很轻松的，问题是还要匹配。正则的引擎差一点就慢很多。反正不大，都放内存里速度能加倍；或者优化一下数据库，别简单的 cat *> database就拿去用……
|
|
17
vibbow OP 因为国内的服务器在搜索完成后回调国外的服务器失败（这个时段，你懂的…），所以之前给一些用户发送了可能错误的“搜索结果为空”email。因为我也不确定具体什么时间开始失败的，所以我按照缓存的记录，给之前所有搜索结果为空的用户重新搜索并且发送了邮件。
在此对再次收到我“垃圾邮件”的用户表示抱歉。 |
|
18
vibbow OP 继续优化了代码，全文搜索时间从4分多钟降到了2分钟，同时添加上了mop的库（虽然感觉这个库很奇怪，很假...）
|
 |
19
liruqi 2011-12-24 08:54:56 +08:00 via Android
直接导入到 mongodb 或者 mysql 加索引啊。为啥要自己写查询呢。
|
 |
22
laiwei 2011-12-24 15:40:59 +08:00
你不想搞mysql的话，你搞个sqlite存起来，建个索引，比你这样strstr快多了。
|
|
23
vibbow OP @laiwei sqlite索引不行啊，如果关键字是从中间开始查那么一点效果都没有啊。目前在缓慢的用mysql给csdn库加全文索引中...
|
|
25
vibbow OP 可是建完全文索引后貌似不能同时查多个关键字了...
不可以用 SELECT * FROM password WHERE keyword LIKE IN ('%keyword1%', '%keyword2%); 或者有其他sql语句可以用？ |
|
26
vibbow OP 好吧，貌似这样来速度也可以：
SELECT * FROM password WHERE keyword LIKE '%keyword1%' OR keyword LIKE '%keyword2%'; |
|
27
liruqi 2011-12-24 16:38:17 +08:00
其实一般自己的id 都能准确记住的，没有必要用 like 做匹配。反而是恶意查询才有这种需求吧。
建议直接用id 做精确匹配。 |
|
28
vibbow OP @liruqi 就我这服务器速度，再加上还限制了并发数量，想批量恶意查询还不如自己把数据库下下来快...
一般查询，随他们去了。 |
|
29
vibbow OP 蛋疼了。加上17173的数据，总共有8千多万条数据，我觉得没个两三天是建立不完索引的了...
算了，还是继续文本搜索吧... |
|
30
delectate 2011-12-24 21:25:07 +08:00
用sed或者awk剔除重复的啊
|
Select Language