mozhenghua
- 浏览: 324422 次
- 性别:
- 来自: 杭州
-
最新评论
-
xiaowangge：
query.setDistrib(false); 之后只是获取 ...
Solr /export 海量数据导出实现 -
mozhenghua：
她的酒窝 写道你好，楼主，将数据库中的几张业务表打成宽表的方式 ...
集合聚合算法 -
pzw：
大牛的思想才是最好的东西
基于Solr的多表join查询加速方法 -
Not_Lost_Yesterday：
你的 demo 似乎写错了,我理解了你的意思 ，spring ...
spring bean id重复覆盖的问题解决 -
她的酒窝：
你好，楼主，将数据库中的几张业务表打成宽表的方式，这个打宽表的 ...
集合聚合算法
文章列表
合理设置Solr Schema防止出现OOM
- 博客分类：
- solr
背景：
晚上收到报警，说线上的一个solr的collection挂掉了，赶紧打开远程服务起查看服务器的状态，果然业务方查询全部超时，增量更新也宕机了，从异常信息上来看是集群中没有可用的节点可以使用，看到这样的问题，第一想到的是要重启一下服务器。悲剧的是重启完服务器，服务只正常了15秒钟，转而又全部宕机。
判断是VM的堆内存溢出了，看了一下虚拟机启动参数 -Xmx4400m -Xms4400m（服务器是8G内存）
，临时的解决方案是增加内存，设置为-Xmx6400m -Xms6400m，设置完成，迅速重启服务器之后，观察了一会，core节点果然是不会 ...
在使用过程中，在执行sql的过程中需要将partition按照一定的规则动态分区：
import org.apache.hadoop.hive.ql.exec.UDF;
public class SharedRouter extends UDF {
private static SolrCloudPainRouter cloudPainRouter;
public String evaluate(final String shardValue
, final String collection, final String runtime) {
return getR ...
Solr需要流式导出海量数据，导出数据是基于流式的，当服务端match到第一条数据之后就会向客户端flush出数据。
需要导出的列需要将schema中field元素的docvalue设置为true，并且在solrconfig.xml中配置
<requestHandler name="/export" class="solr.SearchHandler">
<lst name="invariants">
<str name="rq">{!xport} ...
问题背景
公司内部从2015年9月开始部署了Solr5.3 搜素引擎服务，到今年年初Solr的版本已经发展到了Solr6.x，无奈开源社区的发张的确很快，因为Solr6服务端整合了Facebook的prestodb数据库的Sql解析引擎（ http://prestodb-china.com/），可以让Solr6服务端支持简单的sql语句查询，一时间搜索引擎可以支持Sql语句查询，虽然目前只能支持很简单的单表查询语句和集中功能简单的聚合查询，总之Solr在nosql DB方面走出了坚实的一步。更加方便的是Solrj代码包中提供了一个实现了jdbc接口的API包，这样使得一 ...
我已经编写好了一个根据某列属性hash分区的一个函数，并且已经在日常环境中测试通过
用法：
hive 启动
hive --auxpath /root/standalone/commons-io-2.3.jar,/root/standalone/commons-logging-1.2.jar,/root/standalone/fastjson-1.1.41.jar,/root/standalone/global-diamond-config-1.0.3-SNAPSHOT.jar,/root/standalone/hive-exec-1.1.0.jar,/root/standalone/no ...
下午花了一点时间看了一下cobar的源代码（无奈cobar的文档写的台稀稀拉拉了，只能看源代码了）
在cobar服务端的schema中配置了两个datasource，一主一从，在执行SQL的时候可以通过cobar的Hint语法，在查询的时候指定是从丛库上读取数据（默认是走master库的）
详细执行逻辑请查看 com.alibaba.cobar.route.hint.CobarHint 这个类
/*!cobar: $partitionOperand=('entity_id'='00005758') , $table='orderdetail' , $r ...
背景
事情是这样的，由于业务中需要将几百个浮点数求和，因为以前都会将浮点数的值持久化在数据库中，求Sum这样的操作都是依赖数据库聚合函数Sum，从来都没有考虑过求和之后的值是否会精度损失的问题，也都是正 ...
最近做得一个项目，需要实现字段的拼音搜索功能，在schema配置了一个fieldtyp，如下：
<fieldType name="cn_pinyin" class="solr.TextField" positionIncrementGap="100"
autoGeneratePhraseQueries="true" omitNorms="true" omitPositions="false">
<analyzer ...
什么是docValues？
docValues是一种记录doc字段值的一种形式，在例如在结果排序和统计Facet查询时，需要通过docid取字段值的场景下是非常高效的。
为什么要使用docValues？
这种形式比老版本中利用fieldCache来实现正排查找更加高效，更加节省内存。倒排索引将字段内存切分成一个term列表，每个term都对应着一个docid列表，这样一种结构使得查询能够非常快速，因为term对应的docid是现成就有的。但是，利用它来做统计，排序，高亮操作的时候需要通过docid来找到，field的值却变得不那么高效了。之前lucene4.0之前会利用
linux添加环境变量的办法：
1. 编辑 vi ~/.bash_profile
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin
export JAVA_HOME="/usr/lib/jvm/java-1.7.0-openjdk.x86_64"
...
前言：
使用logback 来记录日志真是一个不错的选择，正像logback官网上介绍的那样：
写道
Logback is intended as a successor to the popular log4j project, picking up where log4j leaves off.
logback扩展了log4j很多功能，以前一直不明白 ...
需求是在按照某一个时间字段统计在一个时间区间中，以天为单位统计时间单位内的记录条数：
使用的Solr file type是：org.apache.solr.schema.TrieDateField
查询url是：
http://10.1.7.41:8983/solr/search4totalpay_shard1_replica1/select?
fl=op_time&q=entity_id%3A00000241
&rows=0&wt=json&indent=true&facet=true&a ...
使用maven进行WAR打包服务的时候需要将部分多余的项目工程的文件过滤掉可以使用一下办法：
<build>
<finalName>solr</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</versio ...
在单机版系统中需要实现一个简单的缓存功能（不使用分布式缓存系统），在内存中用一个map来实现就行了，通常的map可用 LinkedHashMap也可以用WeakHashMap 来实现，他们的区别在于淘汰机制上，前者是在构建时设置一个阀值（或者是可以在回收的时候决定那个对象优先被回收），当到了一个阀值之后就会决定老的对象是否要被淘汰。而后者WeakHashMap 是基于虚拟机的垃圾回机制来淘汰的，回收时，容器中哪个对象对回收完全是由GC来决定的。
这里通过一些代码来来说明WeakHashMap的特性,首先第一个代码，可以顺利执行完成：
public void tes ...
有这样一个需求，在做solr索引优化的设计方案中，业务方给出了一个业务场景，相关的业务表有n多张，需要出一个方案来解决数据库上复杂SQL查询导致的高延时问题，另外顺带通过Solr还需要对一些字段做拼音查询。
利用Solr的倒排索引对数据库的复杂查询是非常奏效的，另外，可以在Solr上事先将数据库中的几张业务表打成宽表的方式，进一步提高查询效率。打宽表是一种常用的优化手段，但是，子业务逻辑表不能太多，太多的话，会造成索引更新维护非常麻烦（如果索引不需要更新的话，那么聚合的子表再多也没有问题），按照笔者的经验，宽表的子表数不能超过5张为宜。
...