淺談Solr和ElasticSearch建索引性能優(yōu)化策略
由于Solr和ElasticSearch都是基于Lucene構(gòu)建的，所以他們之間有很大程度的相似性，故而他們的一些優(yōu)化策略基本也是通用的，面對(duì)越來越多的海量數(shù)據(jù)，如何優(yōu)化全量索引的寫入性能呢？ 散仙簡(jiǎn)單總結(jié)了下面幾個(gè)方向的優(yōu)化策略，如有疑問，歡迎拍磚。
（一）硬件優(yōu)化： （1）CPU加大，有利于并發(fā)寫入 （2）內(nèi)存提升，加大寫入緩沖 （3）磁盤IO，使用SSD或者IO讀寫更快的磁盤 （4）網(wǎng)絡(luò)IO，保證客戶端與服務(wù)端的通信帶寬充足 （二）服務(wù)端框架優(yōu)化： （1）加大shard的數(shù)目，理論上shard越多，寫入速度越快 （2）設(shè)置較大的索引flush觸發(fā)條件，ramBufferSizeMB 或者 maxBufferedDocs （3）寫索引時(shí)，關(guān)閉副本，因?yàn)橥剿饕龝?huì)大大降低寫入速度 （4）監(jiān)控GC，調(diào)整JVM參數(shù) 如果Full GC頻繁，加大JVM堆內(nèi)存， 如果Yong GC頻繁，加大新生代的比例，如果使用的是CMS垃圾收集器，必要時(shí)，可以關(guān)閉survive區(qū)，避免survive區(qū)和Eden區(qū)來回拷貝 （5）盡量使用穩(wěn)定的新版本如JDK和框架本身 （6）內(nèi)存大的，可以嘗試G1垃圾收集器 （三） 客戶端優(yōu)化 （1）如果公司有大數(shù)據(jù)部門，可以使用Hadoop或者Spark分布式集群構(gòu)建索引 （2）如果公司沒有大數(shù)據(jù)產(chǎn)品，可以使用多線程或者多進(jìn)程并行構(gòu)建索引 （3）使用批量提交 （4）減少commit次數(shù)，讓服務(wù)端控制flush索引，索引完成之后，可手動(dòng)commit一次。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容