當前位置:首頁 » 操作系統 » 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:10:32 瀏覽:37
腳本和秒搶 發布:2025-03-20 05:06:29 瀏覽:590
b35鎖如何設置密碼 發布:2025-03-20 05:06:27 瀏覽:903
淘寶如何租雲伺服器 發布:2025-03-20 05:05:12 瀏覽:210
編程忌諱 發布:2025-03-20 04:58:35 瀏覽:425
國家知識產權專利資料庫 發布:2025-03-20 04:54:29 瀏覽:414
win7怎麼給文件夾設密碼 發布:2025-03-20 04:52:38 瀏覽:723
安卓手機電影怎麼投屏到ipad上 發布:2025-03-20 04:27:23 瀏覽:677
蘋果安卓基於什麼開發 發布:2025-03-20 04:20:52 瀏覽:520
演算法化是 發布:2025-03-20 03:48:20 瀏覽:771