标签：mysql database search search-engine inverted-index

搜索引擎(或类似的Web服务)使用平面文件和nosql数据库.倒置索引的结构比多对多关系简单,但使用后者处理它应该更有效.几十亿个网页和数百万个关键字应该有两个表格.我已经测试了一张5000万行的表格; mysql的速度可以与BerkeleyDB的速度相媲美.

我认为处理大型mysql数据库的问题出现在处理ALTER TABLE之类的东西时(这里不是这种情况).这种性能是读取密集型的,其中mysql非常好.当我通过SELECT读取一行时,我没有发现几行或几百万行的表之间存在显着差异;拥有数十亿行时会有所不同吗？

注意：我不是指Google或Bing(或全文搜索等高级功能),我正在讨论这个概念.

解决方法:

AFAIK,nosql提供了其他常规关系数据库引擎所没有的灵活性.我不知道哪个搜索引擎使用哪个数据库引擎,但我可以想到使用nosql的几个好处(不是平面文件.不知道为什么会将它们用于复杂的应用程序).

现在,如果您只是匹配条件并在没有特定订单的情况下发布结果 – 您可以使用任何关系数据库.但是,一旦您想提供最相关的结果,就需要考虑很多标准.你可以：

>优先考虑与用户先前选择的结果具有相似内容的结果.
>根据位置,语言和其他已知事实列举与人更相关的结果.
>首先列举更受欢迎的结果(同样,在特定地区/年龄组/职业组中最受欢迎,或基于关于用户的已知事实的其他组).

这些只是基本的排序标准,是我想到的标准.当人们开始开发和维护时,会想到数百个其他标准,并且有可能实施.现在想想每个人将如何实施.可能有数千个字段表征每个资源,每个新功能都需要额外的数据.

您可以使用关系数据库中的EAV模式来实现这一点,这将为您提供一些灵活性,或者您可以使用NoSQL,它是为此目的而构建的.

同样,这只是使用NoSQL的一个原因.我知道使用RDBMS的更多理由.

标签：mysql,database,search,search-engine,inverted-index
来源： https://codeday.me/bug/20190704/1379037.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。