【发布时间】：2014-04-02 01:35:39
【问题描述】：
我有一个可用的 Solr 索引，但我需要帮助重新构建它以使其更小、更快、更少的资源密集型。
当前：
- 一个索引保存过去 10 年的数据。
- 每天有 5k 个新文本文件被编入索引
- 索引大小约为。每年 40 GB，因此 10 年总计 400 GB。
要求：
- 能够使用新文件每晚更新索引
- 能够从 src 文件重建索引 - 希望能加快速度。
- 能够保持当前大量的分面字段（30 个左右）。
- 能够保持“突出显示” - 因此可以显示提取文档中的文本。
问题：
-
从头开始重建索引时，有哪些权衡（构建时间、内存要求、处理要求）以及何时发出“提交”和“优化”？：
- 构建一个单一的 10 年索引（在构建期间难以分发）
- 每年建立 1 个索引 - 然后合并它们
- 每月、每周或每天构建 1 个索引，然后将它们合并在一起
-
如何合并（有哪些取舍）：
- 使用命令行lucene索引合并工具，还是solr的web实例，还是JAVA API？
- 合并时间还需要多少临时磁盘空间（源索引 + 最终索引大小除外）
- 合并是否有内存要求？
- 是一次合并两个更好还是同时合并所有更好？
- 有没有办法让lucene命令行索引合并工具输出进度？
-
如何运行索引：
- 一个大索引
- 分片索引 - 多核 - 每年都有自己的核心。
-
如何应用每日更新：
- 应用于主索引
- 将新的每日核心创建为新的分片而不是合并。
- 创建新的每日核心并将每日核心与完整索引合并
内存、磁盘和 CPU 有哪些注意事项？你猜一台机器的需求是什么（对于开发/原型环境，而不是互联网规模生产）？
- 我需要继续突出显示。有没有办法不存储文本字段，或者缩小？ doc 以减少最终索引的大小而不删除在搜索结果中突出显示的功能？
【问题讨论】：