如果您希望搜索应用程序得到真正的实时（大约200毫秒）响应，无论是第一次搜索查询响应还是进一步建议的搜索响应，hadoop都不是一个好的选择，甚至连hive、hbase，甚至impala（或者apache drill，类似google dremel的系统）都不是。
hadoop是一个批处理系统，适用于一次写入、多次读取的用例。它的优势在于可扩展性和i/o吞吐量。我看到的趋势是，许多组织正在使用它作为离线数据挖掘和bi分析的数据仓库，以替代基于关系数据库的数据仓库。
hive和hbase都在hadoop之上提供了额外的特性，但是对于一般复杂的查询工作负载来说，它们都不可能达到200ms的实时性。
在apachedrill主页上查看每个可能的解决方案如何真正实现“实时”的高级视图。cloudera impala或apache drill借鉴了google dremel的思想，打算在hadoop之上通过查询优化、基于列的存储、大规模并行i/o来提高查询速度。我相信这两个仍然处于早期阶段，以实现他们声称的目标。我发现了一些关于 Impala 的初步性能基准测试结果。
如果您决定使用hadoop或相关的解决方案堆栈，可以使用sqoop或其他利用hadoop分布式文件系统api的定制数据加载应用程序将数据从mysql加载到hadoop。但是，如果您将有新的数据时不时地进入mysql，那么您需要安排一个定期运行的作业来执行从mysql到hadoop的增量加载。
另一方面，构建hadoop集群和寻找或构建合适的数据加载工具（从mysql到hadoop）的工作量可能很大。此外，您还需要为运行时数据访问找到一个合适的额外层，并围绕该层构建代码，无论是impala还是其他东西。为了解决您自己的问题，最好构建您自己的定制解决方案，比如使用内存缓存来存储数据库中元数据的热记录，以及一些索引机制来快速定位建议搜索计算所需的数据。如果一台机器上的内存不能保存足够的记录，那么内存缓存网格或集群组件就很方便了，比如memcached或reddis、ehcache等。

我知道，hadoop本身无法解决您的问题。首先，hadoop（确切地说是hdfs）是一个fs，它不提供可以在其中查询特定字段的列存储。hdfs中的数据存储为平面文件，您必须遍历数据才能到达感兴趣的数据所在的点。
话虽如此，还是有一些解决办法，比如利用Hive。hive是hadoop家族的另一个成员，它在现有hadoop集群的基础上提供仓库功能。它允许我们将hdfs文件Map为可以方便地查询的配置单元表。此外，它还提供了一个类似sql的接口来查询这些表。但是，如果你有实时需要的话，Hive不是一个好的选择。
我觉得像imapala这样的东西对你来说会更有用，它允许你查询我们的大数据，同时考虑到实时性。
我上面提到的原因是，您的用例需要的不仅仅是hadoop提供的可伸缩性。除了能够分配负载之外，您的解决方案还应该能够满足上面指定的需求。它不仅仅是在一组机器上分发数据并在上面运行原始查询。您的用户需要实时响应以及您在问题中提到的智能建议功能。
实际上，您需要一个比hadoop集群更智能的系统。一定要看一看Apachemahout。它是一个非常棒的工具，提供了推荐挖掘的特性，可以很容易地与hadoop结合使用。你可以在它的主页上找到更多信息。我一定会帮你在你的系统中添加智能建议功能。
您可能想看看hadoop家族的另一个工具hbase，它是一个分布式、可扩展的大数据存储。它的行为类似于数据库，但它不是关系数据库。它还运行在现有的hadoop集群上，并提供实时随机读/写功能。读一读，看看它是否适合某个地方。
最后但并非最不重要的一点，这完全取决于你的需要。只有尝试不同的事物并进行比较研究，才能做出准确的决定。我们可以根据我们的经验向您提出建议，但只有在测试了一些工具并找到最适合您需求的工具之后，才能做出公平的决定：）