2010-12-02 56 views
6

我正在为使用C#的数据仓库开发ETL过程,该过程同时支持SQL Server和Oracle。在开发过程中,我一直在编写将数据从一个数据库同步到另一个数据库的存储过程。存储过程代码相当丑陋,因为它涉及动态SQL。由于我们有动态数据库名称,所以需要构建SQL字符串。ETL处理设计和性能

我的团队负责人希望使用C#代码来执行ETL。我们有代码生成功能,可以在数据库定义更改时自动生成新类。这也是我决定不使用Rhino ETL的原因。

这里有利弊:

存储过程:

优点:

  • 快速加载过程中,一切都被数据库
  • 易于部署处理,则需要

    没有编译

缺点

  • 可读性差,由于动态SQL
  • 需要保持两个T-SQL和PL/SQL脚本时,数据库定义编写动态SQL

C#代码时改变

  • 发展缓慢,因为没有智能感知:

    优点:

    • 更容易开发的ETL过程,因为我们从产生
    • 类获得智能更容易,因为生成的类的维护
    • 更好的日志记录和错误处理

    缺点:

    • 缓慢性能比较与存储过程

    我宁愿使用应用程序代码来执行ETL过程,但perf与存储过程相比,性能是可怕的。在一次测试中,当我尝试更新10,000行时。存储过程只需要1秒,而我的ETL代码花费了70秒。即使我以某种方式设法减少开销,70%的20%纯粹是从应用程序代码调用更新声明。

    有人能提供一些关于如何使用应用程序代码加速ETL过程的建议或评论吗?

    我的下一个想法是尝试通过打开多个数据库连接并执行更新和插入来执行并行ETL过程。

    感谢

  • 回答

    2

    你说你有代码生成自动生成新的类 - 你为什么不有代码生成自动生成新的存储过程?

    这应该给你最好的两个世界的;将其封装成几个很好的类,可以检查数据库并根据需要更新内容,而且不会增加可读性,但可以隐藏它(不需要手动更新SP)

    此外,差异不应该如此巨大,听起来好像你没有做正确的事情(重用连接,将数据从服务器移动到应用程序或以较小的批次处理数据 - 逐行?)。

    此外,对于更好的日志记录 - 注意详细说说吗?您也可以登录数据库层,也可以设计SP,以便应用程序层仍然可以执行日志记录。

    +0

    我们其实已经考虑过了。不幸的是,时间限制,我们决定暂时放弃这个想法。理想情况下,我们希望创建一个存储过程模板,并让代码生成代码填充列名称和连接语句,因为这些列定义经常发生更改。 – dsum 2010-12-02 16:24:17

    +0

    好吧,根据你想要的奇特性,你可以使用KISS原则,例如花费15分钟,编写该模板,连接到数据库模式,并使用SQL从中选择表格和列,使用该列表填写某个表列和表格,标记您实际需要的表格并遍历这些表格以填充模板并创建将创建SP的脚本。对模式进行备份,然后运行脚本。如果你有超过100个表,并且如果你不知道如何查询模式,我确实认为这需要将近两个小时。当事情改变重复。 – Unreason 2010-12-02 16:36:40

    0

    你可能会考虑调整你的应用程序。

    我的一些技巧:

    • 不要使用connection.Open()和conenction.Close()太多。
    • 林某些情况下,LINQ会慢下来
    • 使用的程序,并通过多个参数加载,以减少呼叫的数量时,例如,proc_load_to_table(p1 text)改变proc_load_to_table(p1 text, p2 text, p3 text, p4 tex, p5 text)
    2

    如果你的C#代码已经慢有10,000行,我无法想象它在真正的环境中......

    大多数ETL都是在数据库(stored procedures,包,甚至在数据库内编译(PL/SQL,Java for Oracle))内完成的。他们可以处理数百万行。

    或者一些专业的工具,可以用来(Informatica的,或其他),但它仍然会高于存储过程较慢,但更易于管理。

    所以我的结论是:如果你要来望其项背存储过程的表演,你将不得不代码作为市场上的专业一样优秀的应用程序,经过多年的发展和成熟...你想你可以吗?

    此外,如果您必须处理不同的数据库类型(SQL Server,Oracle),则无法制作通用应用程序并同时对其进行优化,这是一种选择。因为Oracle不能以与SQL  服务器相同的方式工作。

    为了给您一个想法,在Oracle的ETL中,使用了提示(如并行执行提示),并且还可以暂时丢弃或完全禁用某些索引以优化ETL。

    没有办法,我知道的SQL中的完全一样的事情 服务器(他们可能有类似的选项,但不同的语法)。因此,“一个ETL适用于所有数据库”在不损失效率和速度的情况下难以实现。

    因此,我认为你的优点和缺点都非常准确;你必须在速度和开发难度之间进行选择,但不能同时选择两者。