最新 | 最热门 | 最高评价

+0  如何写一篇同时面向人和搜索引擎的文章

Tag: 笔记本 | SEO | 搜索引擎
skk 发于 2020年06月15日 11:43 | 点击: 409 | 展开摘要
在站长或者黑帽 SEOer 眼中,搜索引擎优化(SEO)就是堆砌关键词和外链。这些黑帽 SEO 手法似乎行之有效,比如臭名昭著的「兰州养生网」。但是对于生产有效内容的创作者,如果经过简单的指导、在写作中有意识地规划主题和组织语句,一样有助于 SEO、改善搜索引擎收录和排名。
最近认识了 OI wiki 的发起人 Ir1dXD,为 OI wiki 做了一些微不足道的贡献。得知 Ir1dXD 正在头疼 OI wiki 的 SEO,应邀写下此文。是为序。
为什么要面向搜索引擎写作?

查看全文: http://www.udpwork.com/item/17957.html

+0  从未降级的搜索-主搜索分层优化

Tag: 性能优化 | 搜索引擎
栋宇 发于 2015年01月04日 11:33 | 点击: 2126 | 展开摘要
摘要

  多年以来,主搜索的集群架构和排序算法相对比较单一,一定程度上制约了搜索业务的发展。本文主要介绍主搜索最新采用的索引分层技术。这种分层技术把主搜索集群架构从二维扩展到了三维。基于这种三维的新架构,主搜索可以根据不同的应用场景,选择不同的检索和排序算法,从而更好的提升主搜索的检索性能与检索效果。实践表明,这种分层技术能提升主搜索120%的检索性能和6%的搜索GMV。

1. 背景

主搜索多年以来一直采用二维集群架构来提供淘宝网商品的检索服务,其结构如图 1所示。主要

查看全文: http://www.udpwork.com/item/13726.html

+0  从未降级的搜索技术-实时之刃

Tag: 其他 | 分布式技术 | 搜索引擎 | 实时流量调控 | 实时计算 | 搜索架构
桂南 发于 2014年12月09日 17:00 | 点击: 2589 | 展开摘要
流量是互联网变现的基石,而流量的资源是有限的,如何实现资源的最大化利用(买家-商品的最高效的匹配)是此次双11搜索技术深度切入的使命,也是第一次在双11通过实时把握资源流动的脉搏来控制资源的收和放。

一.  问题发现

天猫的业务团队同学,通过针对去年双11细致认真的数据分析,发现了去年双11暴露的一些问题。 预热期

小部分商品预热过度,预热期吸引的加购量远超出商品库存能支撑的量,大部分用户虽然加了购物车但当天也抢不到,购物车转化率低;而大部分商品预热不足,没有充分曝光;

查看全文: http://www.udpwork.com/item/13619.html

+0  从未降级的搜索技术-天猫SKU搜索

Tag: 搜索引擎
七伤 发于 2014年11月25日 10:29 | 点击: 3132 | 展开摘要
前些天,五福老大的文章《从未降级的搜索技术》介绍了搜索双11的5件新式武器,其中就包括天猫SKU搜索。本文就对此做一些更详细的介绍:

什么是SKU

SKU,Stock Keeping Unit,库存单元,是商品库存的最小单位。通俗的讲,一种商品可能有各种规格的货,每一种货就是一个SKU。比如,iphone6有白色16G、金色16G、白色64G、金色64G、等多种SKU;再比如商家售卖的某款T恤有白色S码、黑色S码、白色M码、黑色S码、等等SKU。

SKU的概念在tmal

查看全文: http://www.udpwork.com/item/13553.html

+0  从未降级的搜索技术

Tag: 搜索引擎
五福 发于 2014年11月21日 11:16 | 点击: 2030 | 展开摘要
在搜索我经历过全部的双11,12年和13年这2次大促,GN是开发总指挥,我是在礼台上看各种新武器实弹表演。过去6年里,我们的引擎体系每年做到100%的性能提升,以淘系搜索为例,从最初3000台机器翻倍到现在区区6000台,但搜索服务却从6千qps增长了40倍到现在的32万qps,同时还填补了算法欲壑(算法数据占用内存从最初的10%到了现在的50%),转化率持续攀升,目前大搜索GMV已经是全网的主体了。搜索工程师的双11历来是实弹各种新武器的大机遇,而常规的技术保障已经成为踩在

查看全文: http://www.udpwork.com/item/13543.html

+0  redis超时问题分析

Tag: 性能优化 | 搜索引擎
德言 发于 2014年02月26日 22:11 | 点击: 1701 | 展开摘要
Redis在分布式应用中占据着越来越重要的地位,短短的几万行代码,实现了一个高性能的数据存储服务。最近dump中心的cm8集群出现过几次redis超时的情况,但是查看redis机器的相关内存都没有发现内存不够,或者内存发生交换的情况,查看redis源码之后,发现在某些情况下redis会出现超时的状况,相关细节如下。

1. 网络。Redis的处理与网络息息相关,如果网络出现闪断则容易发生redis超时的状况。如果出现这种状况首先应查看redis机器网络带宽信息,判断是否有闪断

查看全文: http://www.udpwork.com/item/11773.html

+0  Unique索引优化实践

Tag: 性能优化 | 搜索引擎
一浪 发于 2013年08月15日 18:01 | 点击: 1629 | 展开摘要
Unique索引,有时也称Primary Key索引,顾名思义就是对于这个索引字段每个doc的值都是唯一的,如各种id字段:product id,customer id, campaign id和bidword id等。这种类型的索引一般用来进行高效的查询,最典型的应用场景就是进行附表join查询,即对主表中查到的每一个doc,都在附表中查询其对应的附表doc信息。所以,对这种类型的索引进行优化会对整体查询性能有很好的提升,特别是在主表查询的结果很多的情况下。本文主要总结一下

查看全文: http://www.udpwork.com/item/10387.html

+0  解决进程间共享内存,由于某个进程异常退出导致死锁问题

Tag: 搜索引擎 | Linux | nginx | PHP
tiechou 发于 2013年07月12日 18:09 | 点击: 3177 | 展开摘要
发现问题

继这篇Blog 解决Nginx和Fpm-Php等内部多进程之间共享数据问题 发完后,进程间共享内存又遇到了新的问题

昨天晚上QP同学上线后,早上看超时报表发现有一台前端机器访问QP超时,比其他前端机器高出了几个数量级,前端的机器都是同构的

难道是这台机器系统不正常?查看系统状态也没有任何异常,统计了一下超时日志,发现超时都发生在早上QP服务重启的过程中,正常情况下服务重启时,ClusterMap 会保证流量的正常分配

难道是ClusterMap有问题?去Cl

查看全文: http://www.udpwork.com/item/10187.html

+0  玩转robots协议

Tag: 搜索引擎 | robots.txt | robots协议 | sitemap | 网络爬虫
桂南 发于 2013年07月09日 16:32 | 点击: 2385 | 展开摘要
玩转robots协议

2013年2月8日北京市第一中级人民法院正式受理了百度诉奇虎360违反“Robots协议”抓取、复制其网站内容的不正当竞争行为一案,索赔金额高达一亿元,这可以看做2012年下半年“3B大战”的继续。在此次索赔案件中,百度称自己的Robots文本中已设定不允许360爬虫进入,而360的爬虫依然对“百度知道”、“百度百科”等百度网站内容进行抓取。

其实早在2012年11月初,针对双方摩擦加剧的情况,在中国互联网协会的牵头下,包括百度、新浪、奇虎360在内

查看全文: http://www.udpwork.com/item/10170.html

+0  不同SSD盘组合搜索引擎单机性能测试

Tag: 性能优化 | 搜索引擎 | SSD | 引擎性能 | 软RAID
钓雪 发于 2013年06月09日 09:39 | 点击: 2219 | 展开摘要
一、测试机器

Linux huawei_C5.co3 2.6.32-220.23.2.ali927.el5.x86_64 #1 SMP Mon Jan 28 14:57:06 CST 2013 x86_64 x86_64 x86_64 GNU/Linux

MemTotal:       49520300kB

Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz  * 24

注:测试相关机型:

A7机型:CPU 6核 * 4,主频1.9GH

查看全文: http://www.udpwork.com/item/9990.html

+0  玩转mmap

Tag: 性能优化 | 搜索引擎 | Linux | mmap
恨少 发于 2013年06月07日 15:26 | 点击: 3658 | 展开摘要

+0  静态cache之log共现词分析

Tag: 性能优化 | 搜索引擎 | 静态cache 共现词分析 引擎性能优化
钓雪 发于 2013年06月04日 23:33 | 点击: 1653 | 展开摘要
一、背景

搜索引擎的log数据可以用于query理解、user理解、doc理解和ranking。我们运行共现词分析,挖掘出引擎的query log里面共现的词,离线建静态cache,用于提升引擎的性能。

二、共现词分析

分析query log里query的平均的term数,值为5。我们对query log依次进行一至四元共现词分析,高于四元的我们推荐用fullcache解决,而且高元的离线计算成本也太高。

做法如下:

首先抽取query里分词后的term,因为ter

查看全文: http://www.udpwork.com/item/9991.html
|<<<1234>>>| 一共4页, 39条记录