我已經做了2次性能測試，以測量索引速度與235280個文檔的集合：有和沒有Solrcloud
第一次測試：1的Solr實例沒有 SolrCloud：索引速度= 6191 DOC /秒
第二測試：4的solr實例（4個碎片）連接的與 SolrCloud：索引速度= 4506 DOC/s的
我使用8的CPU。
所以，我對這些結果的一些問題：
Q1：通常情況下，是否提高或降低索引速度的Solr實例的數量？
Q2： SolrCloud會降低索引速度嗎？
Q3：當我使用SolrCloud時，爲什麼會降低性能？我錯過了什麼（設置？）？
編輯：
我使用CSV更新處理索引我的收藏。
基於我進行的性能測試，Solr雲基礎架構中的多個節點之間的共享提高了我的索引性能。出於顯而易見的原因，複製多個節點中的分片以處理故障轉移確實減慢了索引性能。還可以考慮批量索引來執行單個更新。
您可以閱讀http://wiki.apache.org/lucene-java/ImproveIndexingSpeed瞭解更多信息。
Solr中有很多設置以及可能影響索引性能的硬件規格。除了拋出更多機器的明顯解決方案之外，Solr更像是一門藝術而不是科學。這是我的經驗，所以拿一粒鹽。通常你應該看到每秒6K到8K的索引性能。
硬件規格：4×40核（超線程）的RAM 256GB的SSD
我也使用updateCSV API用於導入的文件。
我的基線矩陣是使用其中一臺機器（1個碎片）測量的。 我SolrCloud矩陣與它們的所有4（4個碎片與每收集1個副本）進行測定。
對於大型集合（82GB），我看到了3.68倍的吞吐量。
對於介質集合（7GB），2.17x。
對於小集合（1.29GB），1.17x。
因此，要回答你的問題：
Q1：一般來說，一個Solr的節點上，您每收集增加索引速度有。它可能在某個時候達到穩定水平，但當然，索引性能不應該降低。也許你的收藏太小，無法證明SolrCloud橫向擴展的開銷？
Q2：不，SolrCloud不應降低索引速度。
問題3：這取決於你如何設置它。我只看到默認設置的性能增益。但這裏是我跨獲得的性能提升就顯得更加的事情：
commit=true在updateCSV API調用。solr.hdfs.blockcache.slab.count應該在可用系統內存的10％到20％之間。autoCommit一般應該是15秒。
你有多少片碎片？你如何索引（Tika，數據導入，自定義）？ – lexk
在第一個測試中，我不使用SolrCloud（1個分片）。而在第二個測試中，我有4個碎片（1個碎片）。我使用CSV更新處理程序爲我的收藏索引。 – Corentin
你有多少臺服務器並行發送你的查詢？如果它是一個單一的 - 將消息轉發給右分片領導是需要開銷的。無論如何，我不認爲這可能會導致這種退化。你是否在同一臺機器上使用4個不同的實例？4個核心？還是不同的機器？ – lexk