在一次技术群中,中听到一位sina的架构师,他们是采用基于lucene做的搜索服务,索引在20多G数据量,差不多是在亿的级别上,PV量在500万 /天左右,高峰时期500个并发量/s,采用的是增量索引 ,读写索引都在同一台机上。他们并没有采用分布式,而是采用单机提供服务,主要是在配置上内存提高 到32-64G,再加cpu:32个core.
到底他们在架构上采取了什么样的优化,并不得而知。但从中可以得知,采取大内存的处理比使用硬盘的快1000倍左右。所以我们也测试 了一下采用大内存的设计。使用的机器配置是32G,4个core CPU。
使用的搜索服务是用solr搭建的,主要修改它的索引目录位置,将索引目录设置为内存(在linux中,可以将内存映射为硬盘),然后关掉了其它8 台大索引的服务,即是将主要的搜索服务都分给新配置的机器。测试了几天,它的性能果真是好很多。平均响应时间是30ms。在取文档的时间上几乎为0ms, 主要消耗的时间在计算跟排序上,由于排序时用了六个索引字段,动态计算bf分数,这里才是费了最多时间的。而这里其实也可以优化的,即在建索引的时候,就 先计算好每个文档的bf分数(有时间再做优化)。相信可以提高到10ms左右的响应时间 。
solr的本身设计也是多线程,高峰的时候有几十条线程并发,负载到了4左右,现在单机的瓶颈在CPU上,如果cpu再高些,基本上就可以安稳地顶起高峰时期,或者再多台同样配置的机器负载。
现在的索引只有8G,如果到了20G(一亿左右的数据量)的话,不知道会怎么样,请拭目以待。
原文:http://blog.csdn.net/duck_genuine/article/details/6103088
相关推荐
- 创建一个`data`目录,放入待索引的数据文件 - 使用Solr提供的命令行工具(如`post.jar`)或者通过HTTP API将数据导入Solr核心 9. **查询与优化** - 通过Solr的管理界面或HTTP API进行查询测试,验证数据是否...
6. 部署 ikanalyzer,将相应的 JAR 文件放入 Solr 的 `lib` 目录下,或者在 `solrconfig.xml` 中指定类路径。 7. 配置 `schema.xml` 文件,定义字段类型和字段,使用 ikanalyzer 作为中文字段的分词器。 8. 导入数据...
5. **配置Tomcat**:将提取的jar包放入Tomcat的`lib`目录,使Tomcat能够识别和加载这些库。 6. **部署Solr WAR文件**:Solr 4.10.2可能提供了一个名为`solr.war`的WAR文件,这是Solr的Web应用程序。将其复制到...
在Tomcat6中部署Solr,首先需要下载Solr的WAR文件,并将其放入Tomcat的webapps目录下。启动Tomcat后,Solr会自动解压并创建一个应用实例。接下来,我们需要配置Solr的`schema.xml`文件,这个文件定义了索引的字段...
4. **Solr7安装与配置**:首先下载Solr7的压缩包,解压后放入Tomcat的webapps目录下,通常命名为`solr`。启动Tomcat后,Solr的服务可以通过`http://localhost:8080/solr/`访问。配置Solr可能涉及到修改`solr.xml`、`...
在Windows上,你需要将这些DLL文件放入PHP的"ext"目录,然后在php.ini文件中启用它们,例如,添加"extension=php_mongo.dll"。 MongoDB是一个流行的NoSQL数据库,特别适合处理大量非结构化数据。在PHP 4.3中,安装...
3. 接收器(Sink)从通道中移除事件,并将其放入外部存储库,如HDFS,或将其转发到流中的下一个Flume代理。 Flume的组件包括: - Agent:是一个JVM进程,将数据以事件的形式从源头传送到目的地。主要由Source、...
首先将前k个元素放入堆中,然后对于剩余的每个元素,如果比堆顶元素小,则替换堆顶元素并调整堆。最后堆中剩下的就是最小的k个数。 **示例代码**: ```java import java.util.PriorityQueue; public class ...