SolrLucene 默认的只要磁盘、内存足够大，单节点是可以构建300G的索引，但是很明显，后面索引构建的速度慢下来了。下面结合具体业务场景分享几个思路。
总结描述
300G索引，首先想到的是分片。 300G索引，既然分片了，自然是希望在单节点上，这样merge代价降低 300G索引，分片后，在较好的物理机上，自然是分盘，分担IO
解决方案参考
A： 实时写比例远大于实时读
首先将索引，按照某种策略执行分片，在solr既可以是core层次分，也可以是core内部分多子目录 实时写，从配置上对增量的路径执行多盘配置，然后写入索引，可以完全随机或者一定策略分布写盘 实时查询，根据策略执行磁盘的主索引和对于增量索引的merge
按core层分片优势，可以执行lazy加载core，这对于日子类型的，只写不改的，可以充分发挥磁盘和内存利用率。
B：实时读写比较相当，二者量都非常大的时候
首先也是索引的按某种策略分片，在solr即可core层次分，也可以core内部分多子目录（我们是自己改写了） 全量的索引，离线集群构建。 实时写，建议不采取物理机，而是虚拟机，管理多台虚拟机比少量物理机可能效果更好。 这个时候，物理机多磁盘、多核交由 虚拟化 来管理了。 如果仍然存在多盘的 虚拟机，那么针对实时的commitlog，参照A的场景配置多盘符路径， 使得多个磁盘均分IO
（3）场景用例简要说明
A：日志搜索
每天新增50G以上的新数据构建索引，数据内容就是系统日志。保留最近7天的内容。响应时间3s以内！
解决方案：
分14core，每天2个core分担增量数据，其他core按照查询 天来执行query。 每天定时切换一组（2个）core。
B：key-value搜索
每天新增1000w，每天全量，响应时间50ms，大翻页支持 解决方案
分N多个core，N多个子组，每个core管理多个子组
全量离线并行构建（去掉锁、不落地、调整merge策略是关键），增量写入对应core、对应的子组
