这是一个创建于 1969 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，最近业余开发了一个搜索引擎，面向程序员领域，收录了国内技术网站和国外 github，stackoverflow 等网站。解决国内不能访问 google 的痛点，以及某些搜索广告太多的问题。
纯粹手痒，做着玩玩看，目前蜘蛛的索引面还在不断增加中。在开发过程中优化了分词和 ranking 的算法，如果谁有好的 page ranking 算法建议，欢迎跟帖。
欢迎大伙多提改进意见（拍砖请绕行），也请帮忙判断一下，这个产品有没有留着的必要，如果没有保留必要，我玩一阵子就准备把网站关了。
谢谢大伙。ps：goobe.cn
第 1 条附言 · 2019-06-28 12:13:48 +08:00
应部分朋友要求，我简单写点开发步骤。今天先写抓取部分的开发实现：
1、实现一套分布式计算系统。（原理参照 Map-Reduce，和 hadoop 有点像）
业务逻辑简单解释如下：
1 ） Gird 服务器从数据库载入初始任务，即一堆 URL 清单。
2 ） Grid 服务器分析 URL，基于事先设定的模板 URL 兴趣规则，自动确定网页的分析模板 ID。
3 ） Grid 服务器将“任务 URL ”和“模板 ID ”添加到客户端待处理队列。
4 ） Grid 客户端通过 TCP 连接到 Grid 服务器，并维持心跳和状态检测。
5 ） Grid 客户端从服务器获取任务，即 URL 和模板 ID，如果发现本地没有对应的模板分析代码，则根据模板 ID，实时从服务器请求一份模板代码。
6 ） Grid 客户端从任务 URL 下载 HTML，并运行模板分析代码。模板分析代码会提取网页中有用的各个字段信息，并生成两类输出。第一类输出是 Pages，记录了一堆的子页面的 URL 和挖掘深度序号。第二类输出是 Document，是当前 URL 的结构化文档输出，譬如新闻页面，会输出标题、作者、来源、正文、缩略图、标签等字段。基于不同的模板输出 Document 字段不完全相同。
7 ） Grid 客户端将 Pages 和 Document 提交到服务器。服务器将 Pages 去重，并确定更新逻辑后，将需要抓取的 pages 放到 Task Pool 里面等待执行。将 Document 信息添加或者更新到数据库的抓取完成 Document 库中。
8 ） Grid 客户端重新获取新的任务进行执行。
以上是简单解释，实际上分布式运算系统里面还包括客户端分组、执行任务类型管理等等功能。
2、实现网页模板的快速开发功能。
写一些 html 分析的基础类，譬如提取正文、枚举 href 链接、枚举 img、提取标题、JS decoder 等等东西。可以自己写，也可以用第三方框架，譬如 htmlagility 之类的。
这部分工作主要要提高开发模板的效率，提高模板的兼容性，譬如抓下来的 html 不是严格的 xml 规范，用第三方的框架可能会解析失败，又比如第三方网站简单改版，模板是否能够自动适应。
这部分工作，我目前做了可视化的模板代码生成工具，原理就是自己做了个浏览器，用鼠标在浏览器上选择节点，自动生成页面结构化内容输出代码。
一直想做网站模板代码的自动生成器，但是一直没有时间。可以分享我的原理，就是分析网站的多个统计页面，发现 html 共性和差异，以此提取出网站页面的机构逻辑，实现模板自动生成、自适应等功能。以前在新闻页面抓取的时候，做过这方面东西，但是还不够通用。
网页模板要和上面说的 grid 分布式系统结合，网页模板代码自动定期更新 /下发到抓取客户端。否则每次更新模板，还要去更新多个客户端程序很麻烦。
先写这么多，下次写 lucene 和网站。
1、实现一套分布式计算系统。（原理参照 Map-Reduce，和 hadoop 有点像）
业务逻辑简单解释如下：
1 ） Gird 服务器从数据库载入初始任务，即一堆 URL 清单。
2 ） Grid 服务器分析 URL，基于事先设定的模板 URL 兴趣规则，自动确定网页的分析模板 ID。
3 ） Grid 服务器将“任务 URL ”和“模板 ID ”添加到客户端待处理队列。
4 ） Grid 客户端通过 TCP 连接到 Grid 服务器，并维持心跳和状态检测。
5 ） Grid 客户端从服务器获取任务，即 URL 和模板 ID，如果发现本地没有对应的模板分析代码，则根据模板 ID，实时从服务器请求一份模板代码。
6 ） Grid 客户端从任务 URL 下载 HTML，并运行模板分析代码。模板分析代码会提取网页中有用的各个字段信息，并生成两类输出。第一类输出是 Pages，记录了一堆的子页面的 URL 和挖掘深度序号。第二类输出是 Document，是当前 URL 的结构化文档输出，譬如新闻页面，会输出标题、作者、来源、正文、缩略图、标签等字段。基于不同的模板输出 Document 字段不完全相同。
7 ） Grid 客户端将 Pages 和 Document 提交到服务器。服务器将 Pages 去重，并确定更新逻辑后，将需要抓取的 pages 放到 Task Pool 里面等待执行。将 Document 信息添加或者更新到数据库的抓取完成 Document 库中。
8 ） Grid 客户端重新获取新的任务进行执行。
以上是简单解释，实际上分布式运算系统里面还包括客户端分组、执行任务类型管理等等功能。
2、实现网页模板的快速开发功能。
写一些 html 分析的基础类，譬如提取正文、枚举 href 链接、枚举 img、提取标题、JS decoder 等等东西。可以自己写，也可以用第三方框架，譬如 htmlagility 之类的。
这部分工作主要要提高开发模板的效率，提高模板的兼容性，譬如抓下来的 html 不是严格的 xml 规范，用第三方的框架可能会解析失败，又比如第三方网站简单改版，模板是否能够自动适应。
这部分工作，我目前做了可视化的模板代码生成工具，原理就是自己做了个浏览器，用鼠标在浏览器上选择节点，自动生成页面结构化内容输出代码。
一直想做网站模板代码的自动生成器，但是一直没有时间。可以分享我的原理，就是分析网站的多个统计页面，发现 html 共性和差异，以此提取出网站页面的机构逻辑，实现模板自动生成、自适应等功能。以前在新闻页面抓取的时候，做过这方面东西，但是还不够通用。
网页模板要和上面说的 grid 分布式系统结合，网页模板代码自动定期更新 /下发到抓取客户端。否则每次更新模板，还要去更新多个客户端程序很麻烦。
先写这么多，下次写 lucene 和网站。
第 2 条附言 · 2019-07-05 10:38:28 +08:00
补交欠着的作业，今天把 Lucene 和网站部分介绍一下。
基于之前的描述，假设我们已经完成了各个网站的文章抓取，那我们现在开始来做 Lucene 索引。
1、首先，我们将之前抓取后文档存储的数据库表 Documents 增加一个字段，叫“ LuceneIndexStatus ”，用来标记每一篇文章所需要等待操作。具体可以定义如下：0=不需要 Lucene 操作，1=等待添加，2=等待更新，3=等待删除。
2、写一个 Lucene 索引程序，可以是 Console 脚本，也可以是 exe 程序，都无所谓。程序通过搜索 Documents 表待操作的文档，将其添加 /更新 /删除到 Lucene 索引。我使用的 Lucene 版本没有更新功能，所以得先删除后添加。
3、词库和分词：lucene 索引和查询要使用同一个分词系统和词库。关于词库网上的也不一定全，需要自己补充词库 ，我把地域、学校、城市、街道、小区、名人名字等添加到词库，另外写一个新词发现系统，用来生成新词自动添加到词库。新词发现系统的逻辑，就是运算大量的正文，基于标点符号和停用词分段后，如果几个字的排列组合还大量出现，则认定为新词。
4、添加 Lucene Document 时候的 Trick：
a ）关于 Lucene.Net.Documents.Field.Store。为了前台检索性能考虑，将 Title、Description、URL 等关键字段设置成需要存储，这样当前台用户执行搜索时，执行了 Lucene 搜索后就能够直接获得这些信息，就不用再去数据库基于 ID 查匹配的 Title、Description 等信息了。这种做法，虽然 Lucene 索引做完后空间大了一点，但是查询性能会更好，毕竟减少了数据库 io。其他的一些辅助字段譬如 hostname （为了支持 insite 命令），就不需要存储了。
b ）建立 URL、Hostname 两个 Lucene 字段，而且设置成需要分词。URL 的目的是支持 inurl，hostname 的目的是支持 insite。在查询的时候可以查询 url 和 hostname，并给以一定的权重，譬如搜索 hadoop 的时候，hostname 为 hadoop.org 的文章会获得更高的权重。
c) 在文章入 Lucene 库前，可以计算并设置一下文档的 boost 值，LuceneDocument.SetBoost(BoostValue)。计算文章 Boost 值可以基于：文章内容和标题的质量、详尽程度、网站权重、文章类型（博客、教程、还是新闻）等方法。建议在计算 boost 值时可以考虑使用 math.log10 函数，以较好的控制极大极小值，让 boost 值落在自己需要的区间。
5、Lucene 索引完成后一定要 optimize，个人感觉最好 optimize 三次才有比较好的性能。
6、要把 Lucene 操作 Index 的库和前台搜索的库分开，每次后台完成 Lucene 库 index 更新和 optimize 后，自动 copy 到前台的查询库，然后通知前台网站更换查询的 lucene 库。
7、Lucene 库一旦 optimize 完成后，前台搜索不要更改这个库，否则产生碎片会影响查询性能。正确做法是，前台搜索指向两个或者多个 lucene 库。一个大库是定期更新的，可能有几百 G，由索引程序生成。还有若干个小库，是前台实时添加文档到索引，以支持查询使用的。前台 lucene 搜索时，搜索的是几个库的并集。
基于之前的描述，假设我们已经完成了各个网站的文章抓取，那我们现在开始来做 Lucene 索引。
1、首先，我们将之前抓取后文档存储的数据库表 Documents 增加一个字段，叫“ LuceneIndexStatus ”，用来标记每一篇文章所需要等待操作。具体可以定义如下：0=不需要 Lucene 操作，1=等待添加，2=等待更新，3=等待删除。
2、写一个 Lucene 索引程序，可以是 Console 脚本，也可以是 exe 程序，都无所谓。程序通过搜索 Documents 表待操作的文档，将其添加 /更新 /删除到 Lucene 索引。我使用的 Lucene 版本没有更新功能，所以得先删除后添加。
3、词库和分词：lucene 索引和查询要使用同一个分词系统和词库。关于词库网上的也不一定全，需要自己补充词库 ，我把地域、学校、城市、街道、小区、名人名字等添加到词库，另外写一个新词发现系统，用来生成新词自动添加到词库。新词发现系统的逻辑，就是运算大量的正文，基于标点符号和停用词分段后，如果几个字的排列组合还大量出现，则认定为新词。
4、添加 Lucene Document 时候的 Trick：
a ）关于 Lucene.Net.Documents.Field.Store。为了前台检索性能考虑，将 Title、Description、URL 等关键字段设置成需要存储，这样当前台用户执行搜索时，执行了 Lucene 搜索后就能够直接获得这些信息，就不用再去数据库基于 ID 查匹配的 Title、Description 等信息了。这种做法，虽然 Lucene 索引做完后空间大了一点，但是查询性能会更好，毕竟减少了数据库 io。其他的一些辅助字段譬如 hostname （为了支持 insite 命令），就不需要存储了。
b ）建立 URL、Hostname 两个 Lucene 字段，而且设置成需要分词。URL 的目的是支持 inurl，hostname 的目的是支持 insite。在查询的时候可以查询 url 和 hostname，并给以一定的权重，譬如搜索 hadoop 的时候，hostname 为 hadoop.org 的文章会获得更高的权重。
c) 在文章入 Lucene 库前，可以计算并设置一下文档的 boost 值，LuceneDocument.SetBoost(BoostValue)。计算文章 Boost 值可以基于：文章内容和标题的质量、详尽程度、网站权重、文章类型（博客、教程、还是新闻）等方法。建议在计算 boost 值时可以考虑使用 math.log10 函数，以较好的控制极大极小值，让 boost 值落在自己需要的区间。
5、Lucene 索引完成后一定要 optimize，个人感觉最好 optimize 三次才有比较好的性能。
6、要把 Lucene 操作 Index 的库和前台搜索的库分开，每次后台完成 Lucene 库 index 更新和 optimize 后，自动 copy 到前台的查询库，然后通知前台网站更换查询的 lucene 库。
7、Lucene 库一旦 optimize 完成后，前台搜索不要更改这个库，否则产生碎片会影响查询性能。正确做法是，前台搜索指向两个或者多个 lucene 库。一个大库是定期更新的，可能有几百 G，由索引程序生成。还有若干个小库，是前台实时添加文档到索引，以支持查询使用的。前台 lucene 搜索时，搜索的是几个库的并集。
第 3 条附言 · 2019-07-05 10:38:39 +08:00
再来说说前台网站：
这部分比较简单，就是从多个 lucene 库中查询文档并展示到前台。我就说说我自己的一些 trick 吧。
1、IndexSearcher 访问 Lucene 大库，加上 readonly 标志，防止修改。为了性能，大库前台不动，新增临时文档由前台操作小库来完成。小库不一般可以全部放在内存。
2、搜索建议使用 Lucene.Net.Search.ParallelMultiSearcher，有并较好的并行度，提升搜索性能。
3、修改 Lucene 源码，来符合自己的查询、文章权重和排序需求，主要是这些文件：
/Search/：TermScorer，TermQuery，IndexSearcher，BooleanQuery
4、自己重载 Lucene.Net.Search.Similarity，修改文档算分。这个貌似起到的作用不是很大，没有上面修改源码来的效果好。
5、为了提升性能，lucene 索引库至少要放在 ssd 上。为了提升性能，搜索缓存很重要，一个是调整 lucene 自己的缓存机制，另一个方面自己的前台程序可以缓存搜索结果集。缓存搜索结果集的时候，不要只缓存当前页的搜索结果，否则翻页还是慢。建议每 10 页一缓存，这样在搜索分页间跳转的时候就会很快。
暂时就这些，最近其他杂事太多，在忙着处理，有些细节记得不是特别清楚了，所以只能写个大概，大家见谅。
这部分比较简单，就是从多个 lucene 库中查询文档并展示到前台。我就说说我自己的一些 trick 吧。
1、IndexSearcher 访问 Lucene 大库，加上 readonly 标志，防止修改。为了性能，大库前台不动，新增临时文档由前台操作小库来完成。小库不一般可以全部放在内存。
2、搜索建议使用 Lucene.Net.Search.ParallelMultiSearcher，有并较好的并行度，提升搜索性能。
3、修改 Lucene 源码，来符合自己的查询、文章权重和排序需求，主要是这些文件：
/Search/：TermScorer，TermQuery，IndexSearcher，BooleanQuery
4、自己重载 Lucene.Net.Search.Similarity，修改文档算分。这个貌似起到的作用不是很大，没有上面修改源码来的效果好。
5、为了提升性能，lucene 索引库至少要放在 ssd 上。为了提升性能，搜索缓存很重要，一个是调整 lucene 自己的缓存机制，另一个方面自己的前台程序可以缓存搜索结果集。缓存搜索结果集的时候，不要只缓存当前页的搜索结果，否则翻页还是慢。建议每 10 页一缓存，这样在搜索分页间跳转的时候就会很快。
暂时就这些，最近其他杂事太多，在忙着处理，有些细节记得不是特别清楚了，所以只能写个大概，大家见谅。
 |
1
line 2019-06-17 08:11:43 +08:00 via Android  1
不错，速度很快，用的什么技术？
|
 |
3
wangshuaikeyima 2019-06-17 09:06:28 +08:00 via Android
速度很快
|
 |
4
JR1024 2019-06-17 09:10:02 +08:00 1
|
 |
5
nyfok OP @wangshuaikeyima 多谢多谢
|
 |
7
hhzc 2019-06-17 11:44:54 +08:00
没有广告看起来清爽多了，速度还很快，赞！
|
 |
8
vifird 2019-06-17 14:45:26 +08:00
赞，太厉害了
|
 |
12
996icu 2019-06-18 15:29:11 +08:00
很简约的感觉,考虑开源吗
|
|
13
nyfok OP @996icu 多谢夸奖！都是框架的东西，lucene，本来就开源的，只是调整了打分 boost，simility 算法，你要我可以给你。剩下的那个网页就一搜索页和首页，你那儿浏览器另存为就可以套用给别的项目。关于网站源码和蜘蛛源码，因为我还应用到了很多别的商用项目，考虑到安全性，里面有各种我的类库和加密算法，如果要拆分 就要比较多的调整，就暂时不开源了。
|
 |
14
WeaPoon 2019-06-20 19:01:28 +08:00
.NET 程序员前来支持!
小小小小建议：很多人对 CSDN 反感，也可以支持参数或者选项过滤 CSDN 的内容.  |
|
15
nyfok OP @WeaPoon 好，csdn 最难受的就是上来不能直接阅读全文，还得点一下展开全文才行。多谢老兄建议 :)
|
 |
17
A388 2019-06-21 09:43:33 +08:00
你都发了好几遍了，全是这个。。。，给 csdn 做广告嘛
|
 |
19
ibreaker 2019-06-21 19:17:59 +08:00
404 了？
|
|
20
nyfok OP 那时刚好切换服务器，赶上了，不好意思啊。多谢朋友提醒！
|
|
21
nyfok OP 根据 v 友的建议，goobe 的搜索分词和排序已经进行重新调整，后续还有什么问题或者建议，可以在这儿跟帖。谢谢。
|
 |
22
fish420 2019-06-22 19:36:00 +08:00 via iPhone
这么实用的东西当然有必要留着
|
|
23
fish420 2019-06-22 19:36:11 +08:00 via iPhone 1
兄弟，这么实用的东西当然有必要留着
|
|
24
nyfok OP 多谢老兄鼓励，就冲着老兄，我也先保留着，至少保留半年，这半年里继续完善技术和产品体验。谢谢支持，开心！
|
 |
25
lxmwq 2019-06-22 21:12:10 +08:00 via iPhone 1
好东西，实用性很强，赞赞赞
|
|
26
nyfok OP 多谢多谢，这个周末太高兴了。干着也开心，谢谢你！
|
|
27
lxmwq 2019-06-22 21:36:49 +08:00 via iPhone 1
应该是感谢作者大大，提供一个这么好用的东西。
|
 |
29
gudong 2019-06-24 13:09:34 +08:00 1
体验不错，好评！
|
|
31
nyfok OP 随着索引的文章规模越来越大，现在查询也越来越慢，今晚开始调整 maxdoc 到 10000，明后天拆大小库，把质量好的文章单独放小库，搜索时文章质量好的小库优先，以此来提高搜索速度。
|
|
32
nyfok OP 速度问题已经升级，可以放心使用了
|
|
33
nyfok OP 昨晚已经运用分片缓存技术，搜索和翻页会更快了，尤其是翻页基本 0 等待。另外，各位朋友期望 goobe 索引哪些国外技术网站，欢迎下面跟帖回复。切记，是“国外技术网站”，国内的暂时排期往后靠。
|
|
34
ibreaker 2019-06-26 19:08:58 +08:00
这个是自己写爬虫爬数据吗？工作量应该很大吧
|
|
35
nyfok OP 是，自己写的爬虫，反正有时间就写点，也不刻意。工作量还是有点的。
|
 |
36
skyrem 2019-06-27 13:41:33 +08:00 1
赞一个
https://hotexamples.com/ 这个站考虑收录一下吗 |
 |
37
abc1763613206 2019-06-27 14:14:20 +08:00 via Android 1
|
|
38
abc1763613206 2019-06-27 14:21:19 +08:00 via Android
另外可以把大项目的文档加进去，例如 php manual
|
 |
39
darcy900 2019-06-27 16:09:15 +08:00 1
nb
|
|
40
nyfok OP @skyrem 这个网站看了一下流量还不错，api 文档也还比较清晰，就是页面广告有点多和乱。后期会收录，但排期会靠后。多谢！
|
|
41
nyfok OP abc1763。。 大文档的确要加，准备把各大语言的官网 api，manual，论坛都要加进来。stackexchange 的确可以多加几个，我回头挑挑，看哪些是 IT 的都加进来，不局限于编程领域，只要是 IT 就行。多谢！
|
 |
42
zskyliang 2019-06-27 17:36:18 +08:00 1
楼主大大凶残啊 很实用的网站
要是有相关开发教程让有兴趣的人学习下那就更舒服了 |
|
43
nyfok OP @zskyliang 感谢朋友褒奖！你讲的开发教程是指开发搜索引擎的教程，还是别的教程网站需要我索引供大家搜索？如果是关于如何开发这个搜索引擎的内容，我抽空可以跟帖把做的过程回帖告诉你。如果是需要索引教程网站，请告知具体网址。谢谢！
|
 |
45
verylucky 2019-06-28 09:54:01 +08:00
想了解一下，楼主这个网站服务器是什么配置，索引的文章规模有多少 G。想有空的自己也弄一个玩玩，练练手。
|
 |
46
zdnyp 2019-06-28 10:02:31 +08:00
不允许拍砖 /溜了
|
|
47
nyfok OP verylu...，8 vcpu，4g mem，目前索引在 100G 左右。
zskyli..，我直接写这儿吧，长篇的博客太花时间了，我在这篇文章里尽量一点点写，今天先写抓取部分吧。 |
 |
48
vsitebon 2019-06-28 14:58:47 +08:00
太棒了，大佬请务必把技术大概写完
|
 |
49
lbunderway 2019-06-28 16:42:15 +08:00
点赞 支持楼主
|
|
50
nyfok OP 谢谢楼上朋友 vsite.., lbunder...支持
|
 |
51
tonywangcn 2019-06-28 23:14:41 +08:00
|
|
52
nyfok OP |
 |
53
14c0r3y 2019-06-29 16:27:19 +08:00 via iPhone 1
哇塞 好棒！用来当默认引擎了～
|
 |
55
kayv 2019-06-30 13:49:39 +08:00 1
很棒的项目
|
 |
57
ZeroW 2019-07-01 17:38:46 +08:00 via Android
楼主考虑加一下相同网站聚合呗
|
|
58
nyfok OP @ZeroW 谢谢建议！后期抽空会做“相同内容”聚合，“相同网站聚合”可能会在搜索第一页有聚合，列出来同一网站符合结果的文章。另外，后期也在考虑支持 insite 命令，方便大家筛选。
|
 |
59
Cyen 2019-07-02 14:30:43 +08:00 1
很棒的项目，期待开源
|
 |
60
kios 2019-07-03 08:04:38 +08:00 1
点赞！ 很厉害
|
|
61
nyfok OP 多谢 cyen，kios 的支持，谢谢！
|
|
62
nyfok OP 补充一下，现在网站还不支持 insite，inurl 命令，这几天在调整索引大库，调整完后就支持了，届时再通知。
|
 |
63
dirkl 2019-07-06 09:41:04 +08:00 1
感谢楼主，用了一下很不错，设成默认搜索了，国内搜索真不灵
|
 |
64
ziiber 2019-07-06 18:09:21 +08:00 1
楼主牛批（破音） 收藏了。
|
|
65
nyfok OP 多谢 dirk，ziib.. 两位朋友支持，周末愉快
|
 |
66
scriptB0y 2019-07-07 11:55:32 +08:00
赞楼主，问几个问题：
1. 分类是怎么做的呢？实现定义好不同站点的内容属于不同的分类吗？ 2. 现在是抓固定的站点吗？ 3. 不知道 Google 如何对待其他搜索引擎站... 感觉有些搜索引擎站展示的内容也被 Google 收录了进去。。。 |
|
67
nyfok OP @scriptB0y 谢谢支持，回复如下：
1、分类是基于 URL 正则规则来写的。譬如：默认为普通文档，如果符合(/topic/)|(/BBS/)为论坛，(Blog)为博客。 2、现在是抓固定站点。全网发散抓取技术准备好了，但是准备先集中优势把几个固定站点抓完，再上全网抓取。 3、具体我不知道，如果我做的话，会这么做。第一、写一个算法能够自动分类：是列表页，还是详情页。因为列表页的 href/正文比例，和详情页不一样，而且列表页通常会多内容 topic。 第二、计算如果一个站点的列表页的百分比超过一定比例的话，列表页就不收录了，只收录详情页。 |
|
68
nyfok OP @scriptB0y 另外，还需要计算一个网站详情页的正文内容的原创度和首发度。以确定这个网站的内容的原创性和优质性，以此来决定是否收录，以及查询时排序的先后顺序。因为，一般二道搜索引擎，或者文章转载系统的内容，普遍缺乏原创性，发布的速度肯定滞后于首发平台。
|
 |
69
zy5a59 2019-07-07 15:52:46 +08:00 1
很清爽，赞楼主
|
 |
71
hst001 2019-07-07 18:18:05 +08:00
楼主你这个服务器一个月花了多少钱？放香港是为了解约成本？
|
|
72
nyfok OP 一个月小伍佰，放那儿不需要 bei_an，就是个人练手项目，不想太折腾。
|
 |
73
ccc825 2019-07-08 09:57:47 +08:00 1
感觉速度稍微有点慢，搜 Stack Overflow 谷歌大概 0.9 秒，但是楼主的网站需要 3.9 秒。F12 看了一下谷歌好像是页面先出来然后剩下好多 png 什么零碎的用了一秒多加载。页面很清爽但是下方留白较多，搜索框可以适当往中间移一点。希望自己也能达到楼主这种水平。
|
|
74
nyfok OP @ccc825 多谢朋友建议和支持！可否告知你搜索的关键字，我查查看搜索慢的原因，看是服务器端搜索速度问题，还是页面加载速度问题。目前页面上加载的图片除了 logo 图是 goobe 自己本站的，其他的网页 logo 图都是指向源网站的，如果源网站慢，可能图片加载就有点慢。另外，UI 不是我的擅长，以后期待能找一个厉害的 UI 朋友帮忙 refine 一版网站。
|
|
75
ccc825 2019-07-08 11:12:54 +08:00
@nyfok 关键词是 Stack Overflow，指的是点击搜索按钮到页面出现文字的时间。我用的是 chrome，我看谷歌是出现页面之后标签加载动画还在继续转圈应该是在加载剩下的，而 goobe 是出现文字同时结束加载，我猜应该是这里出现的时间差
|
|
76
nyfok OP @ccc825 收到，我理解你的意思了。的确，服务器端搜索 Stack Overflow，花费的时间是毫秒级的。如果速度慢，一个可能是服务器到用户电脑之间的速度慢，还有一个可能是页面图片的加载逻辑和网页 html 一起同时加载了。我后期会把图片加载顺序学习 google，在页面 html 加载后再加载图片，懒加载。多谢你的建议，非常好，感谢！
|
 |
77
jackFenng 2019-07-08 16:45:59 +08:00 1
优秀优秀..同.net 程序员
|
|
78
nyfok OP |
 |
79
mqqjqr5566 2019-07-09 08:34:55 +08:00
原理就是自己做了个浏览器，用鼠标在浏览器上选择节点.
请问:这是用什么实现的啊. 这个工具能开源不. |
 |
80
qw30716 2019-07-09 17:14:12 +08:00
试了一下，准确率不行
|
|
81
nyfok OP 你好，实现原理如下：
1、自己使用微软的 webbrowser 封装一个浏览器，并自定义鼠标右键事件。 2、当点击鼠标右键的时候，可以将右键事件对应的网页节点元素取出，包括节点的完整 html，以及节点的前一节点、后一节点、及父节点信息。 3、基于第 2 步骤获得的节点信息，再 htmlagility 的 document 寻找到对应节点，并获得 xpath。为什么要这么做，因为以后抓取的时候都是用 htmlagility 来解析 html document 和 xpath，这样性能才有保障。如果都 webbrowser 来加载页面，再解析，性能会很低。另外，webbrowser 的 html 都是经过处理过的 html，所以 xpath 和源网页可能会有差异，所以要将 webbrowser 的 node 信息转换为 htmlagility 的 node 信息。 4、日后抓取中，使用第 3 步的 xpath 信息即可取出对应的节点。 备注： 1、xpath 解析和寻找节点，不一定适用 htmlagility，因为这个对 document 的 xml 结构化要求比较高，可以自己尝试动手写一个。 2、建议对 xpath 进行一些扩展，包含上如 node id，node classname 等一些信息，这样会提高节点定位准确性。诸如：/html/body/div[id="MainContent" class="Main"]/span[id="PostTime"] 3、建议对 xpath 进行一些扩展，包含节点序号。譬如某个 span 节点，是父节点下第 2 个节点，可以书写如下：/html/body/div[id="MainContent" class="Main"]/span[2]. 4、xpath 如果只用 full path，即从根节点 html 到节点的完整路径，有时候不能够很好的对抗对方网页的改版。所以可以将代码优化，支持相对路径的 xpath，而不是完整 xpath。譬如：//div[id="MainContent" class="Main"]/span[id="PostTime"] 这个工具现在还不能开源，因为该工具也被应用到了别的商业项目中，要拆分出来还得需要花比较多的时间，暂时还没时间来弄这件事情。以上的信息，你可以借鉴来开发。 |
 |
83
linxiaojialin 2019-07-11 09:29:07 +08:00 1
赞一个，多谢楼主
|
|
84
mqqjqr5566 2019-07-11 14:02:48 +08:00 1
多谢,楼主厉害,已关注..
|
|
85
nyfok OP @linxiaojialin 感谢支持，祝好！
|
|
86
nyfok OP @mqqjqr5566 感谢支持，祝好！
|
 |
87
Hopetree 2019-07-13 17:24:38 +08:00 1
首先，我觉得敢于写搜索引擎的都是大佬，希望大佬坚持下去吧，毕竟搜索引擎这种项目要维护感觉需要的资源挺大的。
个人觉得博客园的文章比较靠谱，我一般搜索都是点击博客园的，CSDN 现在的确有点恶心 |
|
88
nyfok OP @Hopetree 感谢朋友支持！博客园现在收录的已经差不多了，这几天在切割服务器，切割完成后就可以看到了。另外，接下来准备也收录些简书、知乎，貌似那些站点也有一些。
祝好~！ |
 |
89
brucewuio 2019-07-15 11:18:21 +08:00 1
牛逼啊
|
 |
90
wmhx 2019-07-15 17:15:53 +08:00 1
牛逼 .
|
|
91
nyfok OP 感谢 brucewuio, wmhx 支持！晚上下班回家看到你们的表扬，那个高兴啊，哈哈，谢谢！
ps，最近用户涨了不少，全是大伙的功劳，谢谢大家~ |
 |
92
yinqi025 2019-07-16 09:07:08 +08:00 1
这个用起来确实还不错，点个赞~~~
|
 |
93
ziyue002 2019-07-16 09:29:18 +08:00 1
响应很快的，服务器啥配置~
|
|
95
nyfok OP @ziyue002 阿里云，限制形实例（ cpu 最高 15%），4 个 vcpu，4g 内存，200g ssd。cpu 太弱，要是 cpu 没有限制的那种，性能会好很多，可惜价格又多出不少，暂时还没舍得。
|
 |
96
myforgame 2019-07-17 13:18:03 +08:00 1
还缺掘金和简书
|
 |
98
orangeChu 2019-07-17 21:38:44 +08:00 1
赞楼主！用了一下，第一反应就是快！小白想请教些问题。
对数据的检索是怎么做到响应这么快的？如果是已有的数据能够按照这个检索方式来实现快速搜索吗？ |
|
99
nyfok OP 1
感谢支持！要做到快，主要有以下几点要注意：
1、lucene 索引写完成后，一定要 optimize 一下。 2、lucene 索引不要边写，边查，碎片率高，检索性能会下降。定期将更新的索引 optimize 后，复制到网站用来搜索的 lucene 索引目录下，定期更新索引。 3、最好将 lucene 索引放在 ssd 上，提高查询速度。 4、查询速度慢的时候，关注服务器 cpu，如果 cpu 高，得提高 cpu 核数或者主频。 5、lucene 查询的原理是，先分词，再对各个分词的结果进行交集运算，所以当查询里面有多个常用词（譬如：的 | 你 | 我 | 我们）时，通常会涉及大的 set 集合并，比较影响性能。所以可以根据情况，在 lucene 查询前，自己先分词一下，滤掉一些不必要查询的关键词。具体可以参照停用词逻辑，只不过这儿的停用词不是用来在索引的时候，而是在搜索关键词过滤的时候。 6、lucene 查询适当缩小 maxdoc，目前我写的是 10010，以前设定 100000，有点慢。 7、关注服务器内存，lucene 索引可以用内存做缓存，越大的内存能够确保检索速度。 8、实时对网站和 lucene 预热，可以自己写一个循环 http get url 的程序，枚举各个搜索关键字搜索自己的网站来预热。 如果你的数据量不大，建议用 sql server 的全文索引，比较简单。如果数据量超过 100 万，那就 lucene 或者 elasticsearch 吧。 |
Select Language