我们有一个使用MySQL数据库作为数据存储的产品。数据存储包含大量数据。我们面临的问题是应用程序的响应时间非常慢。数据库查询是非常基本的,非常简单的连接(如果有的话)。根据一些高级员工的响应时间慢的根本原因是巨大的数据存储上的数据库操作。
我们公司的另一个团队过去曾参与过一个项目,他们使用Hadoop处理大型固定格式文件,并将这些文件的内容转储到数据库表中。借用这个项目,一些团队成员认为我们可以从使用MySQL数据库迁移到将保存数据的简单固定格式文件。将有一个文件对应于数据库中的每个表。然后,我们可以构建另一个数据交互层,该层提供用于对这些文件中的内容执行DML操作的接口。该层将使用Hadoop和MapReduce编程模型开发。
此时,我想到了几个问题。 1.问题陈述是否适合使用Hadoop解决的问题? 2.应用程序将如何要求数据交互层获取/更新/删除所需数据?据我所知,包含数据的文件将驻留在HDFS上。我们将生成一个Hadoop作业,它将处理所需的文件(类似于db中的表)并获取所需的数据。此数据将写入HDFS上的输出文件。我们将不得不解析此文件以获取所需的内容。 3.使用固定格式文件并使用Hadoop处理它们的方法是否能真正解决问题?
我已经设法建立了一个带有两台Ubuntu机器的简单节点集群,但在使用Hadoop一段时间之后,我觉得问题陈述不适合Hadoop。我可能完全错了,因此想知道Hadoop是否适合这种情况,还是只是浪费时间,因为问题陈述不符合Hadoop的意图?
答案 0 :(得分:1)
我建议直接去Hive(http://hive.apache.org/)。它是在Hadoop MR之上构建的SQL引擎/数据仓库。
简而言之 - 它获得了Hadoop可扩展性和hadoop高延迟。
我会考虑在那里存储大量数据,做所有需要的转换,只有汇总的数据移动到MySQL来提供查询。通常,将用户请求转换为配置单元查询并不是一个好主意 - 它们太慢,并行运行作业的能力并非易事。
答案 1 :(得分:0)
如果您计划更频繁地更新数据,那么直接在hadoop中存储可能不是一个好的选择。要更新hadoop中的文件,您可能必须重写该文件,然后删除旧文件并在hdfs中复制新文件。
但是,如果您只是搜索和加入数据,那么它是一个不错的选择。如果您使用hive,那么您可以进行一些查询,如sql。
在hadoop中,您的工作流程可能如下所述:
您将为您的查询运行一个hadoop作业。
你的hadoop程序会解析查询并执行一些工作来加入 并根据您的查询和输入参数读取文件。
您的输出将在hdfs中生成。
您将输出复制到本地文件系统。然后将输出显示给您的程序。