ruby-on-rails - 如何使用 ruby​​ 加速大型 CSV 的处理

Question

对于一个项目，我需要解析一些非常大的 CSV 文件。一些条目的内容存储在 MySQL 数据库中。我正在尝试使用多线程来加快速度，但到目前为止，这只会减慢速度。

我解析了一个 CSV 文件(最大 10GB)，其中一些记录(20M+ 记录 CSV 中的大约 5M)需要插入到 MySQL 数据库中。为了确定需要插入的记录，我们使用 Redis 服务器和包含正确 ID/引用的集合。

由于我们在任何给定时间处理大约 30 个这样的文件，并且存在一些依赖关系，我们将每个文件存储在一个 Resque 队列中，并让多个服务器处理这些(优先级)队列。

简而言之:

class Worker
  def self.perform(file)
    CsvParser.each(file) do |line|
      next unless check_line_with_redis(line)
      a = ObjectA.find_or_initialize_by_reference(line[:reference])
      a.object_bs.destroy_all
      a.update_attributes(line)
    end
  end

这很有效，横向扩展很好(更多 CSV 文件 = 更多服务器)，但较大的 CSV 文件会带来问题。我们目前有一些文件需要超过 75 个小时才能以这种方式进行解析。我已经想到了一些优化:

一个是减少 MySQL 查询；我们实例化 AR 对象，而如果我们知道对象 ID，则使用纯 SQL 插入会快得多。通过这种方式，我们可能可以摆脱大部分 AR，甚至可以摆脱 Rails，从而消除开销。我们不能使用普通的 MySQL 加载数据，因为我们现在必须将 CSV 记录映射到可能具有不同 ID 的其他实体(我们将十几个遗留数据库组合到一个新数据库中)。

另一个正在尝试同时做更多事情。 Redis 和 MySQL 都有一些 IO 等待时间、网络等待时间，即使 MRI 使用绿色线程，这也可能允许我们在 IO 读取等的同时安排我们的 MySQL 查询。但是使用以下代码:

class Worker
  def self.perform(file)
    CsvParser.each(file) do |line|
      next unless check_line_with_redis(line)
      create_or_join_thread(line) do |myLine|
        a = ObjectA.find_or_initialize_by_reference(myLine[:reference])
        a.object_bs.destroy_all
        a.update_attributes(myLine)
      end
    end

    def self.create_or_join_thread(line)
      @thread.join if @thread.present?
      @thread = Thread.new(line) do |myLine|
        yield myLine
      end
    end
  end

这会慢慢减慢这个过程。当我 ps au 时，它以 100% CPU 开始，但随着时间的推移，它下降到只有 2-3%。在那一刻它根本没有插入新记录，它只是挂起。

我有 straced 这个过程，起初我看到 MySQL 查询通过，过了一会儿它似乎根本没有执行我的 ruby​​ 代码。可能是死锁(它在解析 CSV 的 last 行后挂起，但进程继续以 5% 的 CPU 运行并且没有退出)，或者我在这里读到的内容:http://timetobleed.com/ruby-threading-bugfix-small-fix-goes-a-long-way/

我在 Ubuntu 10.10 上使用 Rails 2.3.8、REE、1.8.7-2010.02。非常感谢任何关于如何处理大量线程(或者为什么不在这里使用线程)的见解!

Answer 1

你有这些表的索引吗？

您能否在批量插入期间暂时禁用这些索引？

在我们进行批量插入之前，我们禁用索引键:

ALTER TABLE foo DISABLE KEYS

完成后，我们启用索引键:

ALTER TABLE foo ENABLE KEYS

来自文档:

ALTER TABLE ... DISABLE KEYS tells MySQL to stop updating non-unique indexes. ALTER TABLE ... ENABLE KEYS then should be used to re-create missing indexes. MySQL does this with a special algorithm that is much faster than inserting keys one by one, so disabling keys before performing bulk insert operations should give a considerable speedup. Using ALTER TABLE ... DISABLE KEYS requires the INDEX privilege in addition to the privileges mentioned earlier. While the non-unique indexes are disabled, they are ignored for statements such as SELECT and EXPLAIN that otherwise would use them.