解决方案:百度竞价开户价格5万，百度还是把搜索引擎设计好？

　　解决方案:百度竞价开户价格5万，百度还是把搜索引擎设计好？

　　文章自动采集到数据库里面，然后每天都加一遍新的商品词，旧的词。存放在db里面。这样其实实现成本非常低了，如果量大的话，每个商品最多要3m一般，普通人就能满足需求。百度竞价开户现在价格5万左右，10个商品不过分，外部地址也可以加价，商品重复的算重复消费，一个商品10元。所以问题不在你，在百度。还是把搜索引擎设计好吧。

　　首先你要搞清楚是否是回复商品链接而建立一个ip计数器，应该比较好的解决方法只有用技术手段模拟手机端操作人工回复了，但目前来看效果有限（对服务器资源的要求不低）。如果是商品推荐还有很多办法能实现，比如传统的通过邮件、关键词自动投放技术等，

　　针对这个问题，我的简单理解是现在一般的推荐系统还在模拟搜索引擎来做，商品推荐类似。即新增一个或多个推荐关键词，根据关键词与商品的匹配度给予商品个数的奖励。下面我通过自己在推荐系统相关工作的一些理解和实践，对题主的疑问提出一点个人看法：1.规模是否需要这么大？这要看是否是问题定义中提到的新增商品的推荐，如果是这类问题，那么这就是一个aggregation(聚合)的系统，单个用户(新建的关键词)需要新增一个推荐或聚合的系统，比如说用户会用到很多来自淘宝、拼多多的用户的商品链接。

　　其实推荐系统最主要的不是规模，而是正负反馈的设计问题，即如何模拟搜索引擎的推荐或其他推荐系统的机制。2.怎么降低内存消耗和并发量。其实这个问题涉及到的领域一般跟推荐系统有关，所以从这个角度想问题应该是一个更大的问题。按理说，并发规模太大的话，用户是用得上，系统是不用，但在实际工作中，并发规模都比较大，建议从规模这个层面上理解问题，以便对具体方案调优。

　　有些问题是用户数量确定的，有些是由系统架构决定的。所以要知道实际的问题是一个什么样的问题，而且看用户使用场景和系统容量进行定位。3.百度为什么不用es来做这种推荐系统？原因很简单，es不成熟。我在百度es的工作经验来看，es是在推荐系统的应用开发中比较多的东西，原因之一是es包含parser部分，直接借用parser实现新增词和新的规则，原因之二是es是nosql数据库（索引管理），es有天然的查询优势，且支持多种索引存储方式。

　　在百度，百度推荐系统是用天文数字来做推荐引擎的，所以nosql是开发人员引擎化的自然选择。（个人认为，像头条类型的产品还是有必要用es来做，关键字匹配要强大，查询次数要多）。