当前位置:首页 » 操作系统 » solr从数据库导入数据

solr从数据库导入数据

发布时间: 2025-03-19 16:01:57

⑴ solr 有几种导入数据的方式

solr数据导入,经过这几天的查资料,我觉得solr数据导入可以有三种方式:
1、编写数据xml文件,通过post.jar导入;

2、通过DIH导入;

3、利用solrj导入数据;

现针对第三种方式进行研究,在第一步中写了一段小的测试代码,可以参考:http://wiki.apache.org/solr/Solrj#Streaming_documents_for_an_update

具体的代码解释如下:

String url = "http://localhost:8080/solr";
HttpSolrServer server = new HttpSolrServer(url);
//If you wish to delete all the data from the index, do this
//server.deleteByQuery( "*:*" );
//Construct a document
SolrInputDocument doc1 = new SolrInputDocument();
doc1.addField( "id", "id1_solrj" );
doc1.addField( "type", "doc1_solrj" );
doc1.addField( "name", "name1_solrj" );
//Construct another document
SolrInputDocument doc2 = new SolrInputDocument();
doc2.addField( "id", "id2" );
doc2.addField( "type", "doc2_solrj" );
doc2.addField( "name", "name2_solrj" );
//Create a collection of documents
Collection<SolrInputDocument> docs = new ArrayList<SolrInputDocument>();
docs.add(doc1);
docs.add(doc2);
//Do a commit
try {
server.add(docs);
server.commit();
} catch (SolrServerException e) {
System.out.println("server commit error, error code:");
e.printStackTrace();
} catch (IOException e) {
System.out.println("server commit error, error code:");
e.printStackTrace();
}
}

该端代码执行后报异常:expect mime type application/octet-stream but got text/html

没找到这个的解决办法,根据提示好像是说期望的类型和服务器反馈的类型不匹配

最后的解决办法是这样的:

之前在配置solr服务器的时候将solr解压路径\solr-4.8.1\example\solr下的solr.xml用\solr-4.8.1\example\multicore下的solr.xml文件进行了替换,目的是为了引入core0和core1,现在需要将这个动作进行回滚,并且修改collection1下的conf下的schema.xml文件,修改为对应的需要的列定义。然后执行以上的代码就不会产生问题。

原因我也不太明白,感觉应该是collection1的配置和core1、core0、乃至之前文章提到过的solrtest的配置应该不太一样。原因待查。不过现在已经可以通过客户端的方式将数据导入solr服务器,并在前端可以查询到相应的数据。

⑵ solr和elasticsearch对比,有啥差别吗

从两个方面对ElasticSearch和Solr进行对比,从关系型数据库中的导入速度和模糊查询的速度。

单机对比

1. Solr 发布了4.0-alpha,试了一下,发现需要自己修改schema,好处是它自带一个data importer。在自己的计算机上测试了一下,导入的性能大概是:14分钟导入 3092730 条记录,约合 3682条/秒。

2. 3百万条记录的情况下,模糊查询和排序基本都在1秒内返回

3. 刚才的测试,是每个field单独存储,现在修改了一下配置文件,增加了一个Field,所有的field都拷贝一份到text这个field里面去,导入的性能大概是:19分钟导入了3092730 条记录,约合 2713条/秒

4. 3百万条记录的情况下,针对text的模糊查询基本在1秒内返回,但是针对所有记录的排序,大概要2~3秒

5. 使用 elasticsearch 0.19.8,缺省配置,用单任务导入,导入性能是:20分钟导入了3092730 条记录,约合2577条/秒

6. 3百万条记录的情况下,查询基本上在1秒内返回,但是模糊查询比较慢,第一次要10秒,后来大概要1~3秒。加上排序大概需要5秒,整体排序基本100ms

查询及排序的指令:

{

"query": {

"query_string": {

"query": "*999*"

}

},

"sort": [

{

"TIME_UP": {

"order": "asc"

}

}

]

}

7. Es0.19.8,用两个任务导入,导入性能是:13分钟导入了3092730 条记录,约合3965条/秒

8. Solr全部建好索引后,占用磁盘空间是1.2G,es占用磁盘空间是4G

单机对比2

在一台Intel i7,32G内存的机器上,重新跑这两个的对比。不过有个重大的区别在于,Solr是在这台性能很好的机器上跑,而es的导入进程则是在一台Intel 四核 2.5G,4G内存的机器上跑的,也许会有性能的差异。ES版本0.19.8,Solr版本4.0-ALPHA。

1. Solr的导入性能:3400万条记录,用时62分钟,平均9140条/秒,占用空间12.75G

2. 使用 *999* 这样的模糊查询,3秒以内返回,稍长一点的查询条件 *00100014*,也是2~3秒返回

3. Es的导入性能(设置Xmx为10G):3400万条记录,用时40分钟,平均14167条/秒,占用空间33.26G,客户端采用4个并发。

4. 使用 *999* 这样的模糊查询,9秒返回,稍长一点的查询条件 *00100014*,11.8秒返回

5. 如果不是针对所有字段查询,而是针对某个特定字段,比如 SAM_CODE: *00100014*,那么也是1秒以内返回。

6. 结论:es的查询效率也可以很高,只是我们还不会用。

7. 结论2:es有个设置是把所有字段放一块的那个,缺省是放一起,但是不知道为什么没起到应有的作用。

备注:

1. Solr第一次的那个内存使用的是缺省设置,这次改为10G,结果导入性能反而变差了,400万条记录,用了8分钟,平均8333条/秒,不知道为什么。

2. 改回缺省的内存配置,导入速度仍然慢。

3. 重启Linux,用10G的内存配置,再导入,5030万条记录,用时92分,约9112条/秒,说明导入速度和内存配置没有大差别

4. 在10G配置的情况下,检索速度也差别不大。

5. 为了搞清楚lucene4.0和solr4.0的进步有多大,下载了solr3.6.1,所幸的是4.0的配置文件在3.6.1上也可以用,所以很快就搭起来进行测试,导入性能为:3400万条记录,用时55分钟,约10303条/秒,占用空间13.85G。查询性能:*999*第一次11.6s,*00100014* 27.3s,相比4.0ALPHA的结果(5000万结果当中,*999*第一次2.6s,*00100014*第一次2.5s)来说,慢了很多,与es的性能差不多,因此,也许lucene4.0真的对性能有大幅提升?

集群对比:

采用4台同样配置(Intel i7,32G内存)的Centos 6.3组成的集群,进行对比。

1. 首先是es,很方便的就组成了一个Cluster,等上一个3400万条的Index全部均衡负载之后进行测试,导入到另外一个Index当中。

2. 导入性能:8500万条记录,用时72分钟,约为19676条/秒。在前5千万条记录导入时的速度在2万/条以上,初始的速度在2.2万/条。占用空间78.6G(由于有冗余,实际占用空间为157.2G)

3. 查询性能:

*999*第一次13.5秒,第二次19.5秒,第三次7.4秒,第四次7.1秒,第五次7.1秒

*00100014*第一次17.2秒,第二次16.6秒,第三次17.9秒,第四次16.7秒,第五次17.1秒

SAM_CODE:*999*,0.8s,1.3s,0.02s,0.02s,0.02s

SAM_CODE: *00100014*,0.1s,0.1s,0.02s,0.03s,0.05s

4. Solr4.0-ALPHA,SolrCloud的配置还算简单,启动一个ZooKeeper,然后其他三台机器访问这个地址,就可以组成一个Cloud:

机器1: nohup java -Xms10G -Xmx10G -Xss256k -Djetty.port=8983 -Dsolr.solr.home="./example-DIH/solr/" -Dbootstrap_confdir=./example-DIH/solr/db/conf/ -Dcollection.configName=xabconf3 -DzkRun -DnumShards=4 -jar start.jar &

其他机器:nohup java -Xms10G -Xmx10G -Dsolr.solr.home="./example-DIH/solr/" -DzkHost=192.168.2.11:9983 -jar start.jar &

但是在执行 data import 的时候,频繁出现 OutOfMemoryError: unable to create new native thread。查了很多资料,把Linux的ulimit当中的nproc改成10240,把Xss改成256K,都解决不了问题。暂时没有办法进行。

结论

1. 导入性能,es更强

2. 查询性能,solr 4.0最好,es与solr 3.6持平,可以乐观的认为,等es采用了lucene4之后,性能会有质的提升

3. Es采用SAM_CODE这样的查询性能很好,但是用_all性能就很差,而且差别非常大,因此,个人认为在目前的es情况下,仍然有性能提升的空间,只是现在还没找到方法。

⑶ 【Canal】数据同步的终极解决方案,阿里巴巴开源的Canal框架当之无愧!!

在分布式、微服务开发环境中,为了提高搜索效率和精准度,Redis、Memcached等NoSQL数据库与Solr、Elasticsearch等全文检索服务被广泛应用。然而,数据库与这些服务之间的实时数据同步成为了一个关键问题。本文将探讨数据同步的解决方案。

常见问题在于如何实时将数据库中的数据同步到Redis/Memcached或Solr/Elasticsearch中。例如,数据库中的数据实时变化,而应用程序可能需要从不同服务中读取数据。这时,数据的实时同步问题变得尤为重要。

解决方案包括:
1. 业务代码同步:在数据操作后执行同步操作,实现简便,但业务耦合度高,执行效率降低。
2. 定时任务同步:数据库操作后,通过定时任务将数据同步至目标服务,解耦业务代码,但数据实时性不高。
3. MQ同步:通过消息队列实现数据同步,解耦业务代码,并支持准实时同步。
4. Canal同步:通过解析数据库日志,实时更新目标服务,实现业务代码与服务的完全解耦。

Canal是阿里巴巴开源的数据库日志增量订阅与消费组件,基于MySQL binlog技术,支持增量数据订阅与消费。

Canal工作原理包括:
- 主从复制实现:MySQL主从复制主要通过三步完成。
- 内部原理:Canal解析MySQL binlog,检测表结构和数据变化,更新目标服务。
- 内部结构:包括数据库连接、日志解析、事件处理等关键组件。
- 实现步骤:
- MySQL配置:开启binlog写入功能,设置binlog格式为ROW。
- MySQL权限设置:为Canal创建同步账户,赋予相关权限。
- Canal部署与配置:下载、解压Canal,配置服务器相关参数。
- 启动与测试:启动Canal,导入源码进行测试。

通过Canal实现数据库数据实时同步至Solr索引库,主要步骤包括:
- 创建工程、添加依赖、配置日志、实现实体类与工具类。
- 编写同步程序,监听Canal Server,解析数据库日志变更,实时更新Solr库。

总之,Canal作为数据同步的终极解决方案,为分布式环境下的数据实时同步提供了稳定、高效的方法,值得在实际项目中应用。

热点内容
制作自解压安装 发布:2025-03-20 05:41:49 浏览:302
华为连接电视密码是多少 发布:2025-03-20 05:31:11 浏览:492
算法第五版 发布:2025-03-20 05:17:57 浏览:730
湖南台访问 发布:2025-03-20 05:10:32 浏览:38
脚本和秒抢 发布:2025-03-20 05:06:29 浏览:591
b35锁如何设置密码 发布:2025-03-20 05:06:27 浏览:905
淘宝如何租云服务器 发布:2025-03-20 05:05:12 浏览:213
编程忌讳 发布:2025-03-20 04:58:35 浏览:427
国家知识产权专利数据库 发布:2025-03-20 04:54:29 浏览:416
win7怎么给文件夹设密码 发布:2025-03-20 04:52:38 浏览:725