前一段发过一个类似的，可能描述不清楚。最近一直在想这个问题，并做了一个调研，希望各位能给一些好的建议。
目前有三张表其中两张是表是业务表（数据量为三个月一归档，每个月大约1K万数据量），分别描述了一个业务，两张表的相关字段为50%，其余50%为个性字段。第三表为索引表（存储了两张表的50%相同字段），主要承担了，对于其它两张业务表的ID的统一分配，但是更多的是承载了前台对于两个业务的同时的列表和搜索功能。
随着需求的不断增加，对于搜索的需求日益加强，变成了需要同时搜索两张业务表中的各自的个性字段的合集，并且有向所有表的全字段搜索的趋势。
基于需求，目前总结出三种方案，三种方案各有优缺点：
1、直接搜索三张表，然后对于数据进行合集。这样子是不动现有架构，可以直接使用，缺点是需要将搜出的结果再进行合集，因数据量大，所以会产生等待时间长。
2、维护一张两张表的全字段表，即将两张表的所有字段全部融合成一张表，这样子的结果是数据表字段过多，不方便扩展业务。
3、增加搜索引擎：目前考虑的有两个，Sphinx和Lucene，但是这两个对于大数据量的实时更新处理有问题，会吃大量的内存。
目前来说，我只想到了以上的几种解决方案。各位有什么好的想法或已经使用的解决方案不?
多谢！
目前有三张表其中两张是表是业务表（数据量为三个月一归档，每个月大约1K万数据量），分别描述了一个业务，两张表的相关字段为50%，其余50%为个性字段。第三表为索引表（存储了两张表的50%相同字段），主要承担了，对于其它两张业务表的ID的统一分配，但是更多的是承载了前台对于两个业务的同时的列表和搜索功能。
随着需求的不断增加，对于搜索的需求日益加强，变成了需要同时搜索两张业务表中的各自的个性字段的合集，并且有向所有表的全字段搜索的趋势。
基于需求，目前总结出三种方案，三种方案各有优缺点：
1、直接搜索三张表，然后对于数据进行合集。这样子是不动现有架构，可以直接使用，缺点是需要将搜出的结果再进行合集，因数据量大，所以会产生等待时间长。
2、维护一张两张表的全字段表，即将两张表的所有字段全部融合成一张表，这样子的结果是数据表字段过多，不方便扩展业务。
3、增加搜索引擎：目前考虑的有两个，Sphinx和Lucene，但是这两个对于大数据量的实时更新处理有问题，会吃大量的内存。
目前来说，我只想到了以上的几种解决方案。各位有什么好的想法或已经使用的解决方案不?
多谢！
Select Language