1
我有一個可用的Solr索引，但我需要幫助重新設計它，使其更小，更快，資源更少。需要幫助重新設計和優化大型索引索引
電流：
- 一個指數適用於過去10年的數據。
- 每日，5k新文本文件索引
- 索引大小約爲。每年40GB，10年合計400GB。
要求：
- 能力每晚更新索引中使用新的文件
- 能夠從SRC文件重建索引 - 希望加快步伐。
- 能夠保持當前大量的方面字段（30左右）。
- 能夠保持「突出顯示」 - 因此可以顯示來自提取的文檔的文本。
問題：
在重建從頭索引，哪些權衡（建造時間，內存要求，處理要求），以及何時頒發的「承諾」和「優化」？ ：
- 建立一個單人10年指數（很難在編譯時間分佈）
- 建設每年1個指數 - 和ñ將它們合併
- 每要麼一個月，一週或一天1個指數，然後將它們合併在一起
如何合併（什麼是權衡）：
- 使用CMD線Lucene索引合併工具或solr的Web實例或JAVA API？
- 合併時間需要多少更多的臨時磁盤空間（除了源索引+最終索引大小）
- 合併時是否有任何內存要求？
- 將兩個合併在一起還是同時合併是更好？
- 有什麼辦法讓lucene cmd行索引合併工具輸出進度？
如何運行指標：
- 一大指標
- 碎片化指數 - 多核 - 每年在自己的核心。
如何申請每日更新：
- 適用於主要指數
- 創建新的每日核心的新片段，而不是合併。
- 創建新的每日核心和合並每天核心與完整的索引
什麼內存，磁盤和CPU方面的考慮？您認爲單機需求會是什麼（對於開發/原型環境，而不是互聯網規模生產）？
- 我需要不斷突出顯示。有沒有辦法不存儲文本字段，或收縮？ doc在某種程度上可以減少最終索引的大小而不會在搜索結果中突出顯示？
謝謝。我需要在單機上運行。雖然我意識到這一點，但我不知道如何通過分片分割相同數量的內存/ CPU需求。我可能會嘗試使用一次構建的索引和每日更新一次的索引進行多核分片。 – skynss