建设公众号官方网站,wordpress ftp wp-config.php,成都哪里好玩适合小孩,百度教育会员一、搜索优化#xff1a; 在工程领域#xff0c;越是看起来“简单、确定”的问题#xff0c;越是难以解决。近实时搜索引擎需要解决的问题只有一个#xff1a;性能#xff01;它包含快速索引#xff0c;快速搜索#xff0c;以及索引到搜索的快速生效。 以下为百万条数据…一、搜索优化 在工程领域越是看起来“简单、确定”的问题越是难以解决。近实时搜索引擎需要解决的问题只有一个性能它包含快速索引快速搜索以及索引到搜索的快速生效。 以下为百万条数据级适用于千万级快速滚动数据近实时搜索引擎实践经验总结 1. 针对技术优化 1.1 数值搜索优化 将数值的范围缩小能用 int值 的不要用 long值能用 float值 的不用要 double值能用string 替换的就不要用范围查询(特别是大范围查询)这些都基于Lucene搜索引擎对数值建索引和范围查询的原理和特点所决定; 1.2 搜索语法的简化和高级搜索的支持取得一个平衡点 谨慎用*,?(Wildcard搜索)禁止出现 *AA的查询如果必须支持这样的查询则需要培训用户了解*可能引起的性能问题。 2. 针对业务优化 2.1 特别强调范围查询必须优化。避免大范围数值查询数值范围查询不可避免的情况下尽量使用小范围这是由业务性质决定的比如说 A 0的查询需要优化为某个更有意义的查询: [A : 0-100]。 2.2 能使用短字符串特别是不做分词的字符串搜索的来替代一定不要用数值搜索。数值搜索的特定虽然快但对范围查询它有一定的代价如果使用不合适代价会很大。 二、索引优化 优秀的搜索引擎是快速创建索引和快速搜索的一个平衡体。特别对近实时搜索引擎而言这个平衡点更为难以达到。 通过一系列测试和验证Lucene在【搜索】【索引】以及【优化】之间要达到平衡其实很不容易。在频繁的搜索和索引下在线的优化难以真正起效果。可以理解为优先级有这样的特性搜索 索引 优化。搜索的时间相对最短优化的时间最长。在前二者频繁操作下优化没有机会强行优化只能导致搜索和索引停顿对近实时系统来说不可接受。因而必须设置好相应的参数主要包括缓存大小索引内存大小索引单次提交数量上限(等同Merge因子Lucene不一定严格执行)搜索最大并发数等。 大部分的索引优化是基于搜索业务的如上述一所描述的用字符串字段替代数值范围查询。而索引本身的创建方式又直接影响到搜索对Lucene来说Merge因子的配置是个关键内存足够大的情况下。简单的说Merge因子小索引慢但对大批量建索引性能影响却不大索引内存足够大为前提但同时它会使得索引段落数被限制在合理范围值直接影响索引段数——搜索性能。相反如果Merge因子小搜索会很快段数也大如果不及时做索引优化对搜索性能的影响是致命的。 三、分布式平衡 一台Lucene服务器要想达到近实时搜索基本是不可能的除非搜索量非常小。单台搜索量5个/s以上一台基于Lucene的实时搜索基本上会吃不消原因不在于搜索本身而在于索引的同时保证搜索实时性。而建索引的过程如果产生的碎片段过多会直接影响搜索。总结下来给予建索引的服务器一定的空闲时间是必须的也就是说在建索引的时间段搜索不能太过频繁。因而分布式分摊搜索压力是很有必要的。 总结 1. 目前3台基于Lucene的PC服务器高峰并发数量在15个/s左右 2. 数据量为百万条级别不到200万单条数据80个字段每条大概为200字符中文、英文、数字 3. 搜索条件基本在7-20关键字平均搜索速度为98ms 4. 最慢的搜索为350ms毫秒。
