一.Solr4.x新特性

　　1.近實時搜索

　　Solr的近實時搜索【Near Real-Time，NRT】功能實現了文檔添加到搜索的快速進行，以應對搜索快速變化的數據。

　　2.原子更新與樂觀并發

　　原子更新功能允許客戶端應用對已有文檔上進行添加、更新、刪除和對字段增值等操作，而且無需重新發送整個文檔。當存在兩個請求同時更改同一個文檔時，Solr使用樂觀機制防止不兼容的更新。簡單來說就是Solr使用特殊的_version_版本字段來確保文檔的安全更新語義。兩個請求中后提交更改的請求將會獲得一個過時的版本【這個版本是兩請求都未執行之前的版本，然后先提交的請求會執行并修改版本號】，所以會執行失敗【請求執行之前需要先確認版本，只有版本一致才可以執行請求】。

　　3.實時GET功能

　　無論文檔是否已經提交到索引，使用實時GET功能都可以使用唯一標識符檢索最新版本的索引【事務日志提供支撐】。這與使用行鍵【row key】檢索數據的Cassandra的鍵-值存儲方式類似。在Solr4之前，除非文檔提交到Lucene的索引，否則是檢索不出來的。且提交很花費時間，影響查詢性能。

　　4.使用事務日志實現寫持續性

　　當文檔發送到Solr進行索引時，會被寫到事務日志中，以防止服務器發生故障造成數據丟失。Solr的事務日志處在客戶端應用與Lucene索引之間，對實時GET功能提供必要的支持，使其可以不考慮文檔是否已經提交到Lucene，直接通過唯一標識符進行檢索文檔。Solr的事務日志解除了更新可見性與更新持久性之間的綁定。也就是說，文檔可以持久存儲，但不出現在搜索結果中。事務日志可以控制提交的文檔在搜索結果中出現的時機，避免在提交之前因服務器出現故障而導致數據丟失。

　　5.使用Zookeeper實現簡易分片和復制

　　在Solr4.x之前，需手動進行擴容。在Solr4.x之后，SolrCloud讓擴容變得簡單和自動化。在Solr中，Zookeeper負責指定分片代表與分片副本，并對服務請求可用的服務器機芯跟蹤。SolrCloud與Zookeeper是綁定的，因此SolrCloud的啟動無需做任何額外的配置和安裝。

　　6.在以前的版本中，Solr主目錄有配置文件solr.xml進行配置。從Solr4.4之后，內核可以被自動發現，不再需要在solr.xml中進行配置。

二.Solr5.x新特性

　　1.schema文件改名為managed-schema。

　　2.Solr4.x中的deprecated被去掉。

　　3.從Solr5開始，Solr不再以war的形式發布，Solr已然成為了一個獨立的Java服務端應用，已經包括了start和stop腳本，并支持Unix和Windows平臺。

　　4.solr.xml中的單位從cores變為solrcloud。

　　5.在Solr5.x中引入的Streaming表達式允許查詢Solr并將結果作為數據流進行排序和聚合。

三.Solr6.x新特性

　　1.對Solr5.x中引入的Streaming表達式增加幾種新的表達式類型：

　　>使用類似MapReduce的并行表達式來加快high-cardinality字段的吞吐量。

　　>守護程序表達式以支持持續推送或拉取流。

　　>高級并行關系代數，如分布式連接、交集、聯合和補充。

　　>發布/訂閱消息。

　　>用于從其他系統中提取數據并與Solr索引中的文檔連接的JDBC連接。

　　2.并行SQL接口

　　構建在Streaming表達式的基礎上，Solr6.x中的新增功能是一個并行SQL接口，可以將SQL查詢發送到Solr。SQL語句被即時編譯為Streaming表達式，提供可用于Streaming表達式請求的全部聚合。包含一個JDBC驅動程序，它允許使用SQL客戶端和數據庫可視化工具查詢Solr索引并將數據導入到其它系統中。

　　3.跨數據中心復制

　　使用主動-被動模型，SolrCloud集群可以被復制到另一個數據中心，并用一個新的API進行監控。

　　4.QueryParse圖

　　一個新的圖形查詢解釋器可以使Solr文檔建模的定向【循環】圖的遍歷查詢成為可能。

　　5.DocValues

　　在Solr示例配置集中的大多數非文本字段類型現在默認為使用DocValues。

　　6.需要使用Java8

　　Solr6.x【SolrJ客戶端】的Java最低支持的版本是Java8。

　　7.索引格式更改

　　Solr6.x不支持讀取Lucene/Solr4.x以及更早版本的索引。如果索引中仍存在舊的4.x格式的字段，必須運行Solr5.x附帶的Lucene IndexUpgrader。另外，使用Solr5.x充分優化索引，以確保只包含一個最新的索引段。

　　8.默認為托管模式

　　當solrconfig.xml沒有明確定義時，Solr的默認行為依賴于solrconfig.xml定義的luceneMatchVersion。當luceneMatchVersion<6.0時，ClassicIndexSchemaFactory將繼續用于向后兼容，否則將使用ManagedIndexSchemaFactory實例。這種變化最顯著的影響是現有的solrconfig.xml文件內容被修改為luceneMatchVersion>=6.0，但沒有明確配置ClassicIndexSchemaFactory，并將schema.xml文件自動升級為managed-schema文件。并且將默認啟動通過Schema API進行的模式修改。

　　9.默認的相似性改變

　　當Schema沒有明確地定義全局時，Solr的默認行為將依賴于solrconfig.xml中指定的luceneMatchVersion。當luceneMatchVersion<6.0時，將使用ClassicSimilarityFactory實例，否則將使用SchemaSimilarityFactory實例。可以在SchemaSimilarityFactory聲明中指定defaultSimFromFiledType init選項來更改此行為。.值得注意的是，這種改變意味著用戶可以利用每個字段類型的相似性聲明，并且需要明確聲明SchemaSimilaryFactory的全局用法。

　　10.副本和碎片刪除命令更改

　　DELETESHARD和DELETEREPLICA修改為默認刪除任何復制副本的實例目錄、數據目錄和索引目錄。

　　11.刪除facet.date.*參數

　　Solr3.x中被廢棄的facet.date參數【以及相關facet.date.*參數】已被完全刪除。

四.Solr7.x新特性

　　1.復制模式

　　直到Solr7.x，SolrCloud模型允許任何復制副本在領導者丟失時成為領導者。這對大多數用戶來說非常有效，在集群出現問題的情況下提供可靠的故障切換。但是，由于所有副本必須在任何時候都保持同步，因此在大型集群中需要付出代價【副本本身就需要保持同步】。為了提供更多的靈活性，已經添加兩種新類型的副本，TLOG&PULL。這些新類型提供了一些選項，以便僅通過從前導項復制索引段與引線同步副本。TLOG類型還有一個額外的好處，就是其維護一個事務日志【名字叫tlog】，如果需要的話，它可以恢復并成為領導者。PULL類型不維護事務日志，因此不能成為領導者。作為這種改變的一部分，傳統的副本現在被命名為NRT。如果沒有明確定義TLOG或PULL副本，則Solr默認創建NRT副本。

　　2.自動縮放

　　Solr自動縮放是Solr中的一個新功能套件，用于管理SolrCloud集群更加簡單和自動化。Solr自動縮放的核心是為用戶提供一個規則語法來定義在集群中分發節點和碎片的首選項和策略，目的是在集群中保持平衡。從Solr7.x開始，Solr將在確定創建或移動各種Collection API命令的新碎片或副本放置到何處時考慮策略和首選項規則。

　　3.新的默認配置集

　　data_driven_configset與basic_configset已被刪除，取而代之的是_defaultconfigset。sample_techproducts_configset還被保留了下來，專門與example/exampledocs目錄中的Solr附帶的示例文檔一起使用。當創建一個新的collection時，如果不指定configSet，默認_default將被使用。如果使用SolrCloud，_defaultconfigSet會自動上傳到zookeeper。如果使用單獨模式，instanceDir將會自動創建，使用_defaultconfigSet作為基礎。

Solr7.x之前的版本【以6.6版本為例】：

Solr7.x版本：

4.無模式的改進

　　默認情況下，傳入的字段將被索引為text_general【可以修改】。該字段的名稱將與文檔中定義的字段名稱相同。復制字段規則將被插入到模式中，以將新的text_general字段復制到具有名稱的新字段。這個字段的類型是一個strings字段【允許多值】。默認文本字段的前256【可以修改】個字符將被插入到新的字符串字段中。

由于復制字段規則會降低索引的速度并增加索引大小，所以建議只在需要時使用復制字段。如果不需要對字段進行排序或分面，則應該刪除自動生成的復制字段規則。可以禁用update.autoCreateFields屬性禁用自動字段創建。使用命令修改配置：curl http://host:8983/solr/mycollection/config -d '{"set-user-property":{"update.autoCreateFields":"false"}}'。

　　5.對默認行為的更改

　　>JSON現在是默認的響應格式。如果依賴XML響應，現在必須在請求中定義：wt=xml。另外，行縮進是默認啟用的【indent=on】。

　　>sow參數【Split on Whitespace】現在默認為false，允許支持多字同義詞。該參數與eDismax和standard/lucene查詢解析器一起使用。如果此參數沒有明確指定為true，查詢文本將不會在空白上拆分。

　　>legacyCloud參數現在默認為false。如果副本的項不存在state.json，則該副本將不會被注冊。這可能會影響到復制副本的用戶，并自動將其注冊為分片的一部分。通過使用一下命令在集群屬性中設置屬性legacyCloud=true，可以退回到舊的行為。命令如下：./sever/scripts/cloud-scripts/zkcli.sh -zkhost 127.0.0.1:2181 -cmd clusterprop -name legacyCloud -val true。

　　>如果solrconfig中的luceneMatchVersion是7.0.0或以上版本則eDismax查詢分析器參數lowercaseOperator默認為false。luceneMatchVersion低于7.0.0的行為是不變的【true】。這意味著客戶端必須以大寫的方式發送布爾運算符【AND/OR/NOT】才能被識別，或者必須明確設置該參數為true。

　　>如果luceneMatchVersion是7.0.0或以上版本，則solrconfig中的handleSelect參數默認為false。這會導致Solr忽略qt參數，如果它存在于請求中，請求處理程序沒有前導'/'，則可以設置handleSelect="true"或者考慮遷移配置。該qt參數仍用作指定要使用的請求處理程序的Solr特殊參數。

　　>lucenePlusSort查詢解析器【舊的lucene查詢解析器】已被棄用，不再隱式定義。若想繼續使用這個解析器直到Solr8【該版本將刪除這個解析器】，必須將它注冊到solrconfig.xml中。如下：。

　　>TemplateUpdateRequestProcessorFactory名稱從Template更改為template，AtomicUpdateProcessorFactory的名稱從Atomic改為atomic，此外，TemplateUpdateRequestProcessorFactory現在使用{}而不是${}作為模板。

五.備注

　　1.對于Solr升級，將數據重新編入索引被認為是最佳做法。如果重新索引不可行，請注意，Solr一次只能升級一個大版本【例如從6.x升級到7.x】。因此，Solr6.x索引與Solr7.x兼容，但Solr5.x索引則不會與Solr7.x兼容。

總結

以上是生活随笔為你收集整理的solr cloud 更新 solrconfig 配置_Solr各版本新特性「4.x,5.x,6.x,7.x」的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。